Capability Attestation Extensions for the Entity Attestation Token (EAT) in Agentic AI Systems

Introduction The Entity Attestation Token (EAT) defines a CBOR/COSE-based structure for representing signed claims about an entity's identity, configuration, and operational state. While EAT is widely adopted for device attestation, agentic AI systems—such as autonomous planners, LLM-based agents, and API orchestrators—require more granular and dynamic attestation of their capabilities, constraints, and compositional structure. This document defines EAT extensions for agentic AI, supporting:

Attestation of agent capabilities, behavioral policies, and internal module composition.
Secure, privacy-preserving assertions suitable for decentralized, multi-agent environments.
Mechanisms for endorsement and trust anchor management.

These extensions are intended to facilitate secure agent interaction, policy-based access control, and dynamic trust establishment.

Terminology

Agent: An autonomous computational entity capable of executing plans, interacting with services, and making decisions.
Capability Attestation: The process of proving what an agent can do, including reasoning methods, tool use, language models, and planning systems.
Agent Capability Token (ACT): An EAT-compliant token carrying claims about agentic capability attributes.
Submodule: A functional component within an agent (e.g., planner, retriever, executor) that may have its own EAT claims.

Use Cases

Trust establishment between AI agents prior to interaction, ensuring only agents with appropriate capabilities participate in sensitive workflows.
Secure registration of AI agents in public or private registries, with verifiable claims about their operational scope and limitations.
Policy-based access control where access to resources or APIs is granted based on attested agent capabilities and policy constraints.
Dynamic capability negotiation in multi-agent systems, enabling agents to adaptively select partners or workflows based on verified capabilities.

Capability Attestation Claims The following claims are introduced for agent capability attestation. Each claim is assigned a unique CBOR label in the EAT claims registry.

agent_id (CBOR label 40001): Globally unique identifier for the agent.
agent_capabilities (CBOR label 40002): Map describing capabilities, e.g., planning methods, NLP models, tool use, reasoning, delegation.
policy_constraints (CBOR label 40003): Operational policies and constraints, e.g., data access, temperature limits, explainability.
capability_version (CBOR label 40004): Version string of the capability declaration.
model_fingerprint (CBOR label 40005): Hash or identifier of the core model or weights.
dynamic_proof (CBOR label 40006): Challenge-response or external validation artifact.
submodules (CBOR label 40007): Array of nested EATs, each representing a submodule with its own signed claims.
endorsements (CBOR label 40008): Endorsement by registry or certifying authority, including issuer, cert_type, and signature.

Example agent_capabilities claim: { "planning": ["BFS", "A*", "LlamaPlan"], "nlp_models": ["llama3-8b", "gpt-4.5-turbo"], "tool_use": ["web_access", "code_exec"], "reasoning": ["symbolic", "LLM-hybrid"], "delegation": true } Example policy_constraints claim: { "data_access": ["PII_restricted"], "temperature_limit": 0.8, "explainability_required": true }

Nested and Modular Agent Representations Agentic AI systems may be composed of multiple modules, each with distinct capabilities and trust requirements. The submodules claim enables the inclusion of multiple signed, nested EATs, each representing a submodule. Each submodule EAT must include its own agent_capabilities and be signed by the same or a recognized authority. This compositional approach supports modular attestation, allowing verifiers to assess the trustworthiness of both the agent as a whole and its individual components.

Endorsements and Trust Anchors Endorsements provide third-party assurance of agent capability claims. The endorsements claim encodes information such as the issuer, certificate type, and a COSE_Sign1 signature over the claims or schema. Example endorsements claim: { "issuer": "AgenticAITrust.org", "cert_type": "capability-schema", "signature": "<COSE_Sign1 representation>" } Trust anchors for capability validation should be managed by ecosystem authorities, using X.509 or DICE profiles as appropriate. Verifiers must validate endorsement signatures and check certificate revocation status as part of the trust evaluation process.

Security Considerations

All claims must be signed using COSE_Sign1. Endorsements should be cryptographically verifiable.
Include freshness indicators such as iat (issued at), exp (expiration), and nonces for replay protection.
The dynamic_proof claim enables challenge-response or external validation to demonstrate live capability.
Only disclose claims necessary for the verifier's trust decision, minimizing exposure of internal details.
Implementers must ensure compliance with relevant security best practices for cryptographic operations and key management.

Privacy Considerations

Capability claims may reveal sensitive internal structure. Use COSE_Encrypt for confidentiality when required.
Selective disclosure via layered EATs can support verifier-specific access.
Implementers must ensure compliance with relevant privacy laws and regulations when attesting capabilities.

IANA Considerations This document requests allocation of CBOR labels 40001–40008 in the Entity Attestation Token (EAT) claims registry.