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.

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 carries an agent identifier, a decentralized identifier for the agent, a hash reference to the agent's current ATX, a declared purpose, a trust level, issuance and expiry timestamps, a hybrid signature, and the issuer's decentralized identifier: 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. 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.

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 is issued at one of three levels:

L1

Build-time attestation: ATX plus scan results.

L2

Runtime self-attestation: binary hash match.

L3

Behavioral continuity: drift score, anomaly state, and intent verification.

BAC verification is local. The receiver verifies the ML-DSA-65 signature against the issuing authority's public key.

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 ("jti"). Receivers MUST track used identifiers for the token's time-to-live window and MUST reject a repeated identifier.

Post-Quantum Readiness All signatures use a hybrid of Ed25519 and ML-DSA-65 . Key exchange uses a hybrid of X25519 and ML-KEM-768 . The signature suite is a named, negotiable field, so suites can be added or retired by negotiation rather than by a new credential format.

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.

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 . 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.