2026-09-30-preparation-meeting-3/TIDA 30 September 26 RAAAI final version

Thank You
Security Level: ITU-T FG TIDA Remote Attestation for Agenti c AI RA-AAI WG Roadmap v1.0  Henk Birkholz and Houda Labiod  Date : 2026.09.30
Mission & Core Problem  Mission Core Problem  Define open, interoperable, and privacy-preserving standards for verifiable remote attestation of autonomous AI Agents, including their model, code, tools (MCP), data, policies, and execution environments. Create an open standard for Verifiable Agentic Trust Goal: Any user can verify any agent from any environment with one call In Agentic AI, you don't just ask "what is this model?" but rather "what is this agent actually doing, with what tools, what constraints, and in what TEE, right now?" The current attestation proves the infrastructure. We need to prove the agent. AI Agents expand the surface of trust for which remote attestation was designed. The platform, the runtime environment, the model, the tools, the policy, the identity, and the behavior must all be attested, not just the hardware state at boot. Today we can prove where code runs [Confidential Computing]. We cannot prove what an AI Agent is, what tools it can use, and what policies constrain it. Gap  Three main questions: WHAT to attest? HOW to attest ? When to attest ?
Problem Statement: Why now ? Agentic AI breaks traditional attestation Key Question : how to know agent exfiltrate ?  We must answer : As a user, how can I know that the agent to whom I give my credit card will not exfiltrate my data or ignore my policy? Traditional Attestation Agentic attestation  Static binary hash	 Dynamic, stateful agent with memory, tools, prompts Single model	 Composite model: Model_hash + Code_hash + Tools [MCP] + Policy + Data Host-centric trust	 Delegation-centric trust: Agent A must verify Agent B before delegating Infrastructure-only	 Behavior + Constraints must be provable One-time at boot Continuous attestation during lifecycle
Scope : what we WILL and WILL NOT do ?  The Agent Manifest: A standard signed artifact [EAT (JWT/CWT)]. Ex. To represent a manifest is via a Bill of Material(BOM) 2.  The Attestation Evidence Profile: How to bind Infra Attestation [TDX/SEV-SNP/H100 Quote] to the Manifest. 3. The Verification Protocol: How a Verifier [user, enterprise, or another agent] validates evidence and establishes a secure channel. 4. Privacy-Preserving Disclosure. 5. Integration into Agentic protocols Training attestation / Data provenance [we consume it, we don't define it] Benchmarking / security evaluation New TEE hardware design In Scope Out of   Scope
RA-AAI Organization Structure  Structure Work Item 0 Work Item 1  Work Item 2  How to Attest ?  Foundation & Charter What to Attest ? Work Item 3 When to Attest ?  Work Item 4 Liaison with SDOs IETF,TCG,ITU-T,  CCC,Global  Platform,W3C Governance proposal Rough consensus. Co-chairs. Editors empowered. Bi-weekly plenary.
Proposed Approach  Reuse existing IETF RATS building blocks (EAT, CMW,  CoRIM  → EAR) Extend them with an Agent profile Resolve three integration questions specific to agentic protocols:  what to attest (trust vector)? how evidence is discovered and conveyed inside A2A/MCP? and when to attest (risk-keyed freshness tied to protocol events like tool calls and delegation)?
Main Deliverables : a preliminary proposal  D1:  Charter Document & Problem Statement +State-of-the-art survey of RA standardization (IETF RATS/WIMSE/ Oauth , TCG,  GlobalPlatform ) D2: Agent Attestation  Specification Agent  Manifest Attestation Evidence Profile Verification D3: Privacy-Preserving Disclosure D4: Integration into Agentic protocols WI 0-1-2-3 White papers White paper on RA challenges for AI Agents Etc  …. Reminder from  TIDA Chairs:  Focus Group TIDA is built as a platform for pre-standardization. The goal is precisely what this group aims to achieve: establishing consensus and drawing attention to technical topics that could later lead to a standards proposal within the most suitable standardization body (SDO) for the subject (IETF, ITU, GP, etc.). Any SDO can collaborate, and the artifact does not necessarily have to be associated with just one in particular. The key is to define the authors and their affiliations. Organization of events (Workshop, webinar, …)