OpenA2A

US info@opena2a.org

Security Individual Submission agent authorization AI agents delegation credential isolation behavioral attestation This document defines the OpenA2A Agent Authorization Protocol (AAP), a protocol for authorization in AI agent systems. AAP provides mechanisms for agent identity assertion, scoped capability grants, cross-agent delegation, behavioral attestation, cross-organizational federation, and revocation propagation. AAP is the authorization complement to agent communication protocols such as A2A and the Model Context Protocol, in the same way that OAuth 2.0 complements HTTP for web applications. AAP has two layers. The token model, defined in this document, specifies the AAP credentials and assertions: what they contain, how they are signed, and how they are verified. A companion broker and resolution layer specifies how an agent obtains and exercises a grant without the credential value ever entering the agent's reasoning context. This confinement property, that no secret, temporary credential, or backend identifier reaches the agent or the model behind it, is the primary design goal of the protocol.

Introduction AI agent systems present authorization challenges that existing protocols such as OAuth 2.0 , SAML, and OpenID Connect were not designed to address. Agents are non-deterministic: the same agent with identical permissions can behave differently depending on its inputs, conversation history, and model state. Static authorization grants cannot account for this behavioral variability. A second, agent-specific hazard is credential exposure. An autonomous agent that holds a secret in its reasoning context can be induced, through prompt injection or tool-output poisoning, to disclose or misuse it. AAP therefore treats the confinement of credentials away from the agent's reasoning context as a first-class requirement rather than a deployment detail. AAP introduces six protocol components that together provide authorization coverage for agent-to-agent, agent-to-service, and human-to-agent interactions:

1. Agent Identity Token (AIT): a cryptographic identity assertion.
2. Capability Grant Token (CGT): a scoped, short-lived authorization.
3. Delegation Assertion (DA): cross-agent capability delegation.
4. Behavioral Attestation Claim (BAC): a real-time behavioral state proof.
5. Cross-Organizational Trust Federation: mutual trust between issuing authorities.
6. Revocation Propagation: federated revocation within a bounded interval.

AAP is positioned as the authorization complement to agent communication protocols such as A2A and the Model Context Protocol , which convey messages and tool invocations but do not themselves define scoped, attested authorization. A governing constraint applies to every choice in AAP: the protocol and its vocabulary are open, and nothing in AAP requires a vendor, cloud provider, or government to surrender control of its own trust root. The topology is a trust program of federated, conformant Root Authorities, not a single root, the same property that let DNS, TLS, OAuth, and OpenID Connect achieve broad deployment.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Some JSON examples in this document carry digest values longer than the 72-character line limit; those lines are folded using the single backslash strategy of . The backslash fold marker and the leading whitespace of a continuation line are display artifacts, not part of the example content.

Agent

An AI system that can take actions on behalf of a user or organization.

Agent Trust eXtension (ATX)

A signed credential issued by a Registry attesting to an agent's identity, code integrity, capabilities, and trust level, as defined in . The AIT references an ATX by hash.

Agent Security Context (ASC)

Shared state describing an agent's current security posture across monitoring components.

Registry / Root Authority

A trust authority that issues ATXs, maintains a transparency log , and computes trust scores. Participants operate conformant Root Authorities under the Agent Trust Protocol .

Broker

A local, operator-controlled component that resolves an abstract grant reference to a concrete, scoped action on a resource without exposing any credential to the agent, as specified in .

Agent Identity Token (AIT) The AIT is a cryptographic assertion of agent identity, analogous to an OpenID Connect ID Token. It is presented by an agent to identify itself to other agents, services, and infrastructure. An AIT is an identity assertion only; it conveys no authorization (see ). An AIT is an AAP token in the serialized form of : a JWT whose claims follow the JWT registry naming convention. The required claims are "iss" (the issuing Registry decentralized identifier), "sub" (the agent decentralized identifier), "atx_reference" (the SHA-256 of the agent's current ATX), "trust_level" (the Registry trust level, an integer from 0 to 4), "iat" and "exp" (the validity window as NumericDate values, that is, seconds since the epoch), and "jti" (a unique token identifier). The optional "agent_id", "declared_purpose", and "aap_ver" claims MAY also appear. No reference implementation mints AITs yet; the claim schema and this generated example pin the form for implementers. AIT verification MUST be local. The verifier checks the signature against the issuer's public key, distributed via the trust anchor mechanism. No network call to a Registry is required at verification time.

Capability Grant Token (CGT) The CGT is a short-lived, scoped authorization token, analogous to an OAuth 2.0 access token . It authorizes a specific capability exercise under fine-grained authorization constraints. In a broker deployment , the CGT is what the broker mints from a verified ATX before exchanging it for a downstream credential. The CGT claim set is ratified byte-for-byte from the reference broker implementation. The required claims are "iss" (the minting broker's issuer identifier), "sub" (the agent decentralized identifier, taken from the verified ATX and never from agent input), "aud" (the downstream audience or resource), "scope" (the downstream authorization scope as a string, for example "orders.read"), "trust_class" (the abstract ATX capability exercised for this grant, in "class:action" form), "issuer_chain" (the ATX issuer chain), "trust_level" (an integer from 0 to 4), "iat" and "exp" (the validity window, where "exp" minus "iat" is the policy time-to-live), and "jti". The "fga_constraints", "intent_verified", "max_uses", and "context_required" claims are OPTIONAL and are not minted by the v1 reference. In a broker deployment the CGT is used as the OAuth 2.0 Token Exchange "subject_token" with a "subject_token_type" of "urn:ietf:params:oauth:token-type:jwt", so the downstream authorization server verifies it as a standard JWT against the broker's published key material. A CGT has a bounded time-to-live. This document defines three tiers; profiles MAY define others:

STANDARD

4 hours.

PRIVILEGED

30 minutes.

SUPER_PRIVILEGED

15 minutes, no renewal; human approval REQUIRED.

Delegation Assertion (DA) The DA enables cross-agent capability delegation, analogous to OAuth 2.0 Token Exchange . A delegatee's capability scope MUST NOT exceed the delegator's scope. The exchange mode of the broker profile is a realization of the DA over . A DA is subject to the following constraints:

• A maximum delegation depth limits the length of a delegation chain.
• The delegator's ATX hash is embedded to preserve an audit trail.
• Scope is cryptographically bounded and MUST NOT be broadened by a delegatee.

A DA is an AAP token in the form of : the CGT claim set plus the delegation members of . Here "sub" is the delegatee; "act" carries the delegating agent as {"sub": delegator}, with nested "act" objects expressing a chain, innermost actor first; "max_depth" bounds further delegation; and "delegator_atx" embeds the delegator's ATX hash for the audit trail. The delegatee's "scope" and "trust_class" MUST be equal to or a subset of the delegator's. The v1 reference realizes delegation through the broker profile's Exchange mode, where the broker assertion is the subject token of the exchange; it does not yet mint standalone DAs with an "act" chain.

Behavioral Attestation Claim (BAC) The BAC is a short-lived signed assertion of an agent's current behavioral state, with a time-to-live on the order of 60 seconds. It has no direct parallel in existing web protocols; it exists because agents are non-deterministic. A BAC declares its level in the "bac_level" claim, an integer 1, 2, or 3. The levels are cumulative: an L2 claim carries the L1 members, and an L3 claim carries all of them.

1

Build-time attestation: the "atx_reference".

2

Runtime self-attestation: additionally the "binary_hash".

3

Behavioral continuity: additionally the "drift_score", the "anomaly_state", and "intent_verified".

The validity window MUST satisfy "exp" minus "iat" less than or equal to 60 seconds. BAC verification is local: the receiver verifies the signature against the issuing Registry instance's published public key, under the suite model of . The post-quantum profile, an ML-DSA-65 signature alongside Ed25519 via the multi-signature form of , is shipped for CGTs (the reference broker mints it and the conformance suite carries generated hybrid fixtures); for BACs it remains a target: no implementation mints BACs yet, and the v1 BAC fixtures carry a single Ed25519 signature.

Cross-Organizational Federation Federation follows a PKI-style hierarchy: subordinate Registry nodes (Root Authorities) issue ATXs that are trusted by their peers according to published trust lists. Any federated node can verify any other node's ATXs without direct contact. No participant joins a central operator; each operates a conformant Root Authority and cross-trusts its peers.

Revocation Propagation When any node revokes an ATX, the revocation MUST propagate to all federation members within 60 seconds via signed push. No member is required to poll. Authorization revocation in the broker profile is bound entirely to this mechanism; the profile defines no separate revocation system.

Security Considerations

Credential Confinement Where AAP is deployed via a broker, no credential value, temporary token, or backend identifier may enter an agent's reasoning context. This requirement is normative in the broker profile and is the property that defends against the credential-harvest and exfiltration attack classes catalogued in . An agent emits an abstract grant reference; the broker verifies the agent's ATX, evaluates resource policy, obtains a scoped credential, performs the operation, and returns only the result.

Replay Prevention All tokens include a unique identifier in the "jti" claim: 16 random bytes encoded as 32 lowercase hexadecimal characters, as minted by the reference implementation. Receivers MUST track used identifiers for the token's time-to-live window and MUST reject a repeated identifier. The reference verifiers enforce this: an identifier is remembered from first acceptance until the token's "exp", and a second presentation inside that window is rejected after all other checks pass.

Cryptographic Agility and Post-Quantum Readiness The signature suite is a named, swappable field, the JOSE "alg" of each signature's protected header (), so suites can be added or retired by negotiation rather than by a new credential format. A verifier MUST reject a token whose declared suite it does not support rather than silently downgrade. Suite acceptance is pinned by verifier policy per path, never selected by the token; a producer configured for the hybrid profile on a path MUST NOT fall back to a classical-only token on that path except through explicit version negotiation. The v1 suite registry () contains two active entries: "EdDSA" (Ed25519 ) and "ML-DSA-65" (FIPS 204 , whose JOSE "alg" identifier and AKP key type are registered by ). The post-quantum profile is a hybrid of Ed25519 and ML-DSA-65, carried as two signature entries of the multi-signature form (), one per suite: a hybrid token verifies only if at least one ML-DSA-65 signature and at least one Ed25519 signature verify, with every declared entry verifying. The hybrid form is RECOMMENDED wherever both ends implement AAP; single-suite compact tokens remain the interoperability baseline. ML-DSA-65 signing uses the empty context string and no pre-hash variant, as requires, and ML-DSA-65 verification keys publish as AKP JSON Web Keys. The reference implementation mints all three forms, and the conformance suite carries generated hybrid and ML-DSA-65 fixtures, including rejection fixtures in which one of a hybrid token's two signatures is invalid. Key exchange, where AAP deployments negotiate transport keys, targets a hybrid of X25519 and ML-KEM-768 ; ML-KEM has no final JOSE registration, so that row remains reserved on the adoption path this section previously applied to ML-DSA-65.

Intent Verification Semantic intent classification can express constraints that static policies cannot. Intent classification is probabilistic; systems MUST NOT rely on it alone to authorize irreversible actions.

Trust Is Not Authorization A valid AIT or ATX is an identity and posture assertion, not permission to act on a resource, and trust is not transitive. Authorization exists only where a local policy grants it. Brokers MUST default-deny.

Token Serialization and Signing This section pins the byte-level form of every AAP token: the AIT, CGT, DA, and BAC. AAP tokens are JOSE objects, that is, JWTs over JWS . The form is ratified from the reference implementation: what the reference broker actually signs is normative, byte for byte. The signed bytes are the JWS Signing Input: AAP defines no other canonical form: serialization is canonicalization. The producer serializes the header and claim set once, as compact JSON with no insignificant whitespace, and signs those exact bytes; a verifier operates on the transmitted base64url segments and never re-serializes. There is no separate canonicalization step and no field projection. This is a deliberate difference from ATX and ATP, and it exists because AAP tokens, uniquely in the family, are verified by foreign systems: OAuth 2.0 Token Exchange authorization servers and OpenID Connect-style verifiers that understand exactly one thing, a standard JWT. Base64url is unpadded, per . The protected header carries "alg" (a suite identifier from the registry below), "typ" (the value "JWT"), and "kid" (the key identifier of the signing key in the issuer's published key material; Ed25519 keys publish as OKP JSON Web Keys and ML-DSA-65 keys as AKP JSON Web Keys per ). The compact serialization "header.payload.signature" is the v1 baseline and is REQUIRED on every interoperability path where a foreign system verifies the token; in particular a CGT or DA presented as an "subject_token" MUST be compact. A compact token carries exactly one signature, and therefore exactly one suite. The suite of a compact token is pinned per path by verifier policy (): "EdDSA" is the interoperability baseline, and an "ML-DSA-65" compact token serves counterparties that support the suites. During the current adoption window the RECOMMENDED default on foreign-interoperability paths remains "EdDSA", because deployed token-exchange and OpenID Connect-style verifiers do not yet verify the suites. Where more than one signature is required, the hybrid post-quantum profile of , the token is carried as JWS General JSON Serialization (), with one signature entry per suite, each with its own protected header over the same payload. Every declared entry MUST verify; a verifier MUST NOT accept a token on a subset of its declared signatures. A general-form token that declares any ML-DSA-65 entry is on the hybrid profile and MUST carry at least one Ed25519 entry and at least one ML-DSA-65 entry; a verifier MUST reject a general-form token missing either family, so a stripped hybrid token can never degrade to single-family acceptance. Multiple entries of one suite with no ML-DSA-65 entry remain a legal multi-signature (co-signature) form. The v1 suite registry contains two entries:

EdDSA

Ed25519 . Active; the interoperability baseline.

ML-DSA-65

FIPS 204 , JOSE registration . Active. Hybrid with EdDSA via the multi-signature form, or single-suite compact on post-quantum-capable interoperability paths. ML-DSA-44 and ML-DSA-87, though registered for JOSE, are not in this registry and are rejected as unknown suites.

Adding or retiring a suite is a change to this registry plus version negotiation, never a change of format. Claim names use the JWT registry convention, lowercase with snake_case for compound names such as "trust_class" and "issuer_chain". This is a deliberate exception to the OpenA2A camelCase JSON convention, which governs API responses rather than IETF-track token claims. The "iat" and "exp" claims are NumericDate values (seconds since the epoch), not date strings. The optional "aap_ver" claim carries the claim-schema version; it is OPTIONAL in v1 and REQUIRED from the first federated version, where a peer broker must select a claim schema without a shared channel.

IANA Considerations This document requests registration of the "aap" URI scheme in the Uniform Resource Identifier (URI) Schemes registry, and, via the broker profile , the "grant" URI scheme. It further anticipates registries for AAP protocol versions, credential-provider mode identifiers, and signature suite identifiers, to be coordinated with the ATX signature suite registry . Until those registries exist, the signature suite registry of is managed within this specification. The concrete registration templates will be provided in a future revision of this document.

Normative References National Institute of Standards and Technology National Institute of Standards and Technology OpenA2A OpenA2A Informative References OpenA2A A2A Project Model Context Protocol OpenA2A

Related Work The "AAP" acronym is contested in this space. An independent Internet-Draft, "Agent Authorization Profile" , specifies an OAuth 2.0 and JSON Web Token profile for agent authorization; it is a profile of existing OAuth mechanisms and introduces no new protocol elements. A separate Internet-Draft uses the same "AAP" letters for an unrelated "Agent Attachment Protocol" concerned with edge-node attachment. The present document defines a distinct token model (AIT, CGT, DA, and BAC), a broker-based credential-confinement layer, and a federation and revocation model. These documents are author-namespaced and are intended to coexist on the Internet-Drafts record. Closest in intent is the "Delegated Agent Authorization Protocol" , which extends OAuth 2.0 with agent grant and delegation semantics. The present document differs in that authorization is exercised through a local broker that confines the credential value away from the agent's reasoning context () and binds to behavioral attestation (), rather than issuing an OAuth token the agent holds directly. Related agent-identity drafts using the "AIP" acronym address identity assertion rather than the scoped-authorization and credential-confinement problems that are the focus of this document.

Acknowledgments This specification was authored in the open and benefits from review of its authorization and delegation model by the OpenA2A community.