Entity Attestation Token (EAT) Profile for Autonomous AI Agents

1.3.1.1. 4.1.1. ai-model-id

• ai-model-id: A globally unique model identifier encoded as a URN. The URN namespace urn:ietf:ai:model: is reserved for standardized reference models (e.g., defined in RFCs). Model owners SHOULD use their own URN namespace (e.g., based on domain name, PEN, or UUID) to avoid central coordination. Examples:¶

  • urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 (for a private model)¶

  • urn:ietf:ai:model:llama3-8b (for a well-known public model, if later standardized)¶

  • urn:dev:example.com:finance-agent-v2 (enterprise-owned model)¶

1.3.1.2. 4.1.2. use of cryptography digests

• The claims ai-model-hash, model-arch-digest, and input-policy-digest represent cryptographic digests of serialized artifacts (e.g., model weights, computational graphs, or policy documents). To support algorithm agility and avoid ambiguity, each such claim is defined as a digest structure rather than a bare byte string. A digest structure is encoded as a two-element array:¶

cbor [ alg, hash ] where: * alg is the Hash Algorithm Identifier, using either the integer or text string from the IANA COSE Algorithms registry, indicating the hash function used (e.g., '-16' for SHA-256, -44 for SHA-384, -45 for SHA3-256). * hash is the byte string output of applying that hash function to the canonical serialization of the artifact.¶

In CBOR, the digest is represented as a CBOR array: [ int / tstr, bstr ]. In JWT (JSON), it is represented as a JSON object: { "alg": "...", "hash": "base64url-encoded-hash" }. This design aligns with the Detached-Submodule-Digest type defined in [RFC 9711, Section 4.2.18.2] and enables future-proof support for multiple hash algorithms (e.g., SHA-2, SHA-3, post-quantum secure hashes) without requiring new claims or breaking existing parsers.¶

1.3.1.3. 4.1.3. ai-sbom-ref

• The ai-sbom-ref claim provides a reference to the Software Bill of Materials (SBOM) associated with the AI agent. This enables verifiers to assess the integrity, license compliance, and vulnerability status of the agent’s software supply chain. The value MAY be:¶

• A URI pointing to an SBOM document (e.g., in SPDX or CycloneDX format),¶

• A digest (using the structured digest format defined in Section 4.1) of an SBOM,¶

• Or a compact embedded representation (e.g., a minimal map of critical components).¶

Example (CBOR): cbor / ai-sbom-ref / -75012: "https://example.com/sboms/agent-xyz.spdx.json" Example (embedded digest): cbor / ai-sbom-ref / -75012: [ -44, h'abcd1234...' ] ; SHA-384 digest of SBOM When used, the SBOM SHOULD include: - Runtime environment (e.g., Python 3.11, CUDA 12.4), - AI framework versions (e.g., PyTorch 2.3, TensorFlow 2.15), - Critical dependencies (e.g., NumPy, cuDNN), - Model serialization format (e.g., ONNX v9, SafeTensors v0.4). This claim complements model integrity (ai-model-hash) by attesting to the execution context in which the model operates—critical for reproducibility and security analysis.¶

1.3.3.1. 4.3.1. Multi-Agent Platforms:

To support a user managing multiple agents with varying configurations, we should leverage the recursive nesting capability of the submods claim (CBOR key 266) as defined in [RFC 9711]. In this architectural pattern, the top-level EAT represents the user's platform or trust domain. Each agent is a submodule of that platform, and if an agent uses multiple models, those models are further nested as submodules of that specific agent.¶

The following CWT example shows a platform hosting two agents. Agent 1 is a complex orchestrator using two models, while Agent 2 is a simple worker using only one.¶

Code snippet ``` { / ueid / 256: h'0102030405060708', / User/Platform ID / / nonce / 10: h'abcdef1234567890', / Freshness Nonce / / submods / 266: { / Submodules Section /¶

/ --- Agent 1: Multi-Model Orchestrator --- /
"agent-1": {
  / swname / 270: "Orchestrator-Agent-v2",
  / submods / 266: {             / Nested Model Submodules /
    "llm-core": {
      / ai-model-id / -75000: ":uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
      / ai-model-hash / -75001: [-44, h'9a8b...']  / SHA-384 /
    },
    "tool-planner": {
      / ai-model-id / -75000: ":uuid:550e8400-e29b-41d4-a716-446655440000",
      / ai-model-hash / -75001: [-16, h'5e4f...']  / SHA-256 /
    }
  }
},

/ --- Agent 2: Single-Model Worker --- /
"agent-2": {
  / swname / 270: "Vision-Worker-v1",
  / ai-model-id / -75000: ":ietf:ai:model:vit-b-16", /
  / ai-model-hash / -75001: [-44, h'd3e2...']            /
}   } } ```

1.3.3.2. 4.3.2. Multi-Model Agents:

A single agent utilizing an orchestrator model and task-specific worker models.¶

Modern AI agents are not necessarly monolithic; sophesticated Agents can consist of an orchestrator model (e.g., a LLM) and several task-specific worker models (e.g., image classifiers or encoders). To support these configurations, this profile utilizes the submods claim (Key 266) from [RFC 9711]. Each distinct model used by the agent SHOULD be represented as an entry within the submods map. This allows for granular policy appraisal where different models may have different trust levels, privacy parameters (dp_epsilon), or residency requirements.¶

When a model is represented in a submodule, it carries its own instance of ai-model-id and ai-model-hash. If the model weights are proprietary (e.g., accessed via a cloud API), the submodule SHOULD include an ai-model-id that the Verifier can match against a provider Endorsement.¶

The following example demonstrates an agent employing an orchestrator LLM and a specialized vision model. Note the use of the digest format [alg, val] to support different hash types for each model.¶

Code snippet { / ueid / 256: h'0102030405060708', / nonce / 10: h'abcdef1234567890', / submods / 266: { "orchestrator-llm": { / ai-model-id / -75000: ":uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", / ai-model-hash / -75001: [-44, h'9a8b7c6d...'] / SHA-384 / }, "vision-classifier": { / ai-model-id / -75000: ":ietf:ai:model:vit-b-16", / ai-model-hash / -75001: [-16, h'5e4f3a2b...'], / SHA-256 / / dp-epsilon / -75005: 0.8 } } } ¶

1.3.3.3. 4.3.3. Layered Trust:

Scenarios where different system components (e.g., hardware TEE, OS runtime, and AI model) are owned or managed by different entities.¶

• Nesting Mechanism: Components SHOULD be represented as nested EATs within the submods claim (Key 266). Each nested token MAY be signed by a different attestation key belonging to the respective component owner.¶

• Verifier Role: A Verifier receiving a composite EAT SHOULD follow the Hierarchical Pattern, where it acts as a Lead Verifier and delegates the appraisal of individual submodules to specialized verifiers that hold the appropriate Trust Anchors for each owner.¶

For multi-owner attestation, a Lead Verifier SHOULD follow the Hierarchical Pattern, extracting nested sub-tokens and delegating their appraisal to specialized verifiers holding the appropriate Trust Anchors.¶

+-----------------------------------------------------------+ | Attesting Device (e.g., Edge Server / 5G UE) | | | | +----------------------------+ | | | Hardware Root of Trust | <--- Signing Key (AK_1) | | | (RoT) | | | +-------------+--------------+ | | | Measures | | v | | +-------------+--------------+ | | | TEE / Secure OS | <--- Signing Key (AK_2) | | | (Submodule 1) | (Optional) | | +-------------+--------------+ | | | Measures & Isolates | | v | | +-------------+--------------+ | | | AI Agent Environment | | | | | | | | +----------------------+ | | | | | AI Model (Target) | | | | | | - Weights Hash | | | | | | - Config | | | | | +----------------------+ | | | +----------------------------+ | +-----------------------------------------------------------+ _Figure 1: Example of a Chain of Trust _¶

Figure 1 illustrates the Chain of Trust. The Hardware Root of Trust (RoT) measures the integrity of the Trusted Execution Environment (TEE) or OS. The TEE, acting as a transitive verifier, subsequently measures the AI Agent's model binaries and policy configurations. The resulting EAT token reflects this hierarchy using nested submodules, ensuring that the ai-model-hash is reported by a trusted parent rather than the agent itself.¶

To clarify the hierarchical trust relationships in multi-owner attestation scenarios, Figure 2 illustrates the binding of components across hardware, runtime, and AI model layers. Each layer is attested by a distinct owner and represented as a nested submodule within the top-level EAT per RFC 9711 Section 4.2.18.¶

+-----------------------------------------------------------------+ | Top-Level EAT (Platform Attester) | | • ueid: Platform hardware identity (e.g., TPM/SE) | | • nonce: Freshness guarantee | | • submods: { | | "tee-runtime": { ← Signed by Platform Owner | | • ueid: TEE instance ID | | • swname: "Confidential-VM-v2" | | • submods: { | | "ai-agent": { ← Signed by AI Operator | | • swname: "Execution-Agent-v3" | | • ai-model-id: "urn:uuid:..." | | • ai-model-hash: [alg, hash] | | • submods: { | | "orchestrator": {...}, ← Model Owner A | | "vision-model": {...} ← Model Owner B | | } | | } | | } | | } | | } | +-----------------------------------------------------------------+ Figure 2: Trust hierarchy for layered attestation using EAT submods¶

1.3.3.4. Trust Binding Semantics

• Hardware → TEE: The TEE runtime measurement is included in a platform-signed attestation report (e.g., AMD SEV-SNP, Intel TDX). The top-level EAT's signature binds the tee-runtime submodule to this hardware root.¶

• TEE → AI Agent: The AI agent's code and configuration are measured into the TEE's launch digest. The ai-agent submodule is signed by the AI operator's key, which itself is endorsed by the platform owner (via an Endorsement per RFC 9334).¶

• Agent → Models: Individual models are signed by their respective providers. The agent's runtime verifies model signatures before loading; these signatures are reflected in the nested submods entries.¶

1.3.3.5. Appraisal Delegation

Per RFC 9334 Section 5.3, a Lead Verifier appraising the top-level token: 1- Validates the platform signature against a hardware Trust Anchor 2- Delegates tee-runtime appraisal to a TEE-specific verifier holding platform Endorsements 3- Delegates ai-agent appraisal to an AI policy verifier holding operator Trust Anchors 4- Optionally delegates model submodules to specialized model catalog verifiers¶

A submodule appraisal failure MUST cause rejection of the entire attestation unless policy explicitly permits partial trust (e.g., non-critical auxiliary models). This failure semantics MUST be defined by the deployment policy—not by this profile.¶