| Internet-Draft | A2A-Auth | February 2026 |
| Kasselman, et al. | Expires 22 August 2026 | [Page] |
This document proposes a framework for secure agent-to-agent (A2A) authentication and authorization leveraging existing standards such as the Workload Identity Management and Secure Exchange (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent-to-agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent-to-agent authentication and authorization.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://PieterKas.github.io/agent2agent-auth-framework/draft-agent2agent-kasselman_lombardo-agent2agent-auth.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-agent2agent-kasselman_lombardo-agent2agent-auth/.¶
Source for this draft and an issue tracker can be found at https://github.com/PieterKas/agent2agent-auth-framework.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
TODO Introduction¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
An Agent is a workload that iteratively interacts with a Large Language Model (LLM) and a set of tools that expose interfaces to underlying services and resources until a terminating condition, determined either by the LLM or by the agent’s internal logic, is reached. It may receive input from a user, or act autonomusly. Figure 1 shows a conceptual model of the AI Agent as a workload and illustrates the high-level interaction model between the User or System, the AI Agent, the Large Language Model (LLM) and the Tools through which the underlying Services and Resources are accessed by the Agent.¶
+----------------+
| Large Language |
| Model (LLM) |
+----------------+
▲ |
(2) (3)
| ▼
+--------------+ +------------+ +-----------+ +-----------+
| User / |──(1)─►| AI Agent |──(4)─►| Tools |──(5)─►| Services |
| / | | (workload) | | | | and |
| / System |◄─(8)──| |◄─(7)──| |◄─(6)──| Resources |
+--------------+ +------------+ +-----------+ +-----------+
Figure 1: AI Agent as a Workload
¶
Optional: The User or System (e.g. a batch job or another Agent) provides an initial request or instruction to the AI Agent.¶
The AI Agent forwards the available context to the LLM. Context is implementation and deployment specific and may include User or System input, system prompt, tool descriptions, tool outputs and other relevant information.¶
The LLM returns a response to the AI Agent identifying which Tools it should invoke.¶
Based on the LLM’s output, the AI Agent invokes the relevant Tools (note that a Tool may be another Agent).¶
The Tools interacts with the underlying Services and Resources required to fulfill the requested operation.¶
The underlying Services and Resources returns the information requested by the Tools.¶
The Tools returns the information collected from the Services and Resources to the AI Agent, which sends the information as additional context to the Large Langugage Model, repeating steps 2-7 until the exit condition is reached and the task is completed.¶
Optional: Once the exit condition is reached in step 7, the AI Agent may return a response to the User or System.¶
As shown in Figure 1, the AI Agent is a workload that needs and identifier and credentials with which it can be authenticated by the User or System, Large Langugage Model and Tools. Once it is authenticated, the Large Langugage Model and Tools must determine if the AI Agent is authorized to access it. If the AI Agent is acting on-behalf-of a User or System, the User or System needs to delegate access to the AI Agent, and the context of the User or System needs to be preserved to inform authorization decisions.¶
This document describes how AI Agents should leverage existing standards defined by SPIFFE [SPIFFE], WIMSE, OAuth and OpenID SSF [SSF].¶
An Agent Identity Management System ensure that the right Agent has access to the right resources and tools at the right time for the right reason. It consists out of the following components:¶
Agent Identifiers: Unique identifier assigned to every Agent.¶
Agent Credentials: Cryptographic binding between the Agent Identifier and attributes of the Agent.¶
Agent Attestation: Mechanisms for determining and assigning the identifier and issue credentials based on measurements of the Agent's environment.¶
Agent Credential Provisioning: The mechanism for provisioning credentials to the agent at runtime.¶
Agent Authentication: Protocols and mechanisms used by the Agent to authenticate itself to Large Langugage Models or Tools (resource or server) in the system.¶
Agent Authorization: Protocols and systems used to determine if an Agent is allowed to access a Large Langugage Model or Tool (resource or server).¶
Agent Monitoring and Remediation: Protocols and mechanisms to dynamically modify the authorization decisions based on observed behaviour and system state.¶
Agent Auhtentication and Authorization Policy: The configuration and rules for each of the Agent Identity Management System.¶
Agent Compliance: Measurement of the state and fucntioning of the system against the stated policies.¶
Agents MUST be uniquely identified to enable authentication and authorization. The Secure Production Identity Framework for Everyone (SPIFFE) identifier format is widely deployed and operationally mature. The SPIFFE workload identity model defines a SPIFFE identifier (SPIFFE ID) as a URI of the form spiffe://<trust-domain>/<path> that uniquely identifies a workload within a trust domain [SPIFFE].¶
The Workload Identity in Multi-System Environments (WIMSE) working group builds on the experiences gained by the SPIFFE community and defines the WIMSE workload identifier [WIMSE_ID] as a URI that uniquely identifies a workload within a given trust domain.¶
Because SPIFFE IDs are URI-based workload identifiers and their structure aligns with the identifier model defined in the WIMSE identifier draft, all SPIFFE IDs can be treated as valid WIMSE identifiers.¶
All Agents MUST be assigned a WIMSE identifier, which MAY be a SPIFFE ID.¶
Agents MUST have credentials that provide a cryptographic binding to the agent identifier. These credentials are considered primary credentials that are provisioned at runtime. The cryptographic binding is essential for establishing trust since an identifier on its own is insufficient unless it is verifiably tied to a key or token controlled by the agent. WIMSE define a profile of X.509 certificates and Workload Identity Tokens (WITs) [WIMSE_CRED], while SPIFFE defines SPIFFE Verified ID (SVID) profiles of JSON Web Token (JWT-SVID), X.509 certificates (X.509-SVID) and WIMSE Workload Identity Tokens (WIT-SVID). SPIFFE SVID credentials are compatible with WIMSE defined credentials. The choice of an appropriate format depends on the trust model and integration requirements.¶
Agent credentials MUST be ephemeral, include an explicit expiration time, and MAY carry additional attributes relevant to the agent (e.g., trust domain, attestation evidence, or workload metadata).¶
In some cases, agents MAY need to have access to a secondary credential format to acces a proprietary or legacy system that is not compatible with the X.509, JWT or WIT it is provisioned with. In these cases an agent MAY exchange their primary credentials through a credential exchange mechanisms (e.g., OAuth 2.0 Token Exchange, Transaction Tokens, Workload Identity Federation). This allows an agent to obtain a credential targeted to a specific relying party by leveraging the primary credential in its possession.¶
Note: Static API keys are an anti-pattern for agent identity. They lack cryptographic binding, cannot convey attestation or provenance, and are difficult to rotate or scope, making them unsuitable for secure Agent-to-Agent authentication or authorization.¶
Agent attestation is the identity-proofing mechanism for AI agents. Just as humans rely on identity proofing during account creation or credential issuance, agents require a means to demonstrate what they are, how they were instantiated, and under what conditions they are operating. Attestation evidence feeds into the credential issuance process and determines whether a credential is issued, the type of credential issued and the contents of the credential.¶
Multiple attestation mechanisms exist, and the appropriate choice is deployment, and risk, specific. These mechanisms may include hardware-based attestations (e.g., TEE evidence), software integrity measurements, supply-chain provenance, platform and orchestration-layer attestations, or operator assertions. Depending on the risk involved, a single attestation may be sufficient, or, in higher risk scenarios, multi-attestation may be requred.¶
The Remote ATtestation Procedures (RATS) architecture (see [RFC9334]) provides a general model for producing, conveying, and verifying attestation evidence. RATS defines the roles of Attester, Verifier, and Relying Party, as well as the concept of Evidence, Endorsements, and Attestation Results.¶
Workload identity management systems can use different attestation mechanisms and implementations (including RATS), to represent attestation evidence and deliver it to credential provisioning systems.¶
Agent credential provisioning refers to the runtime issuance, renewal, and rotation of the credentials an agent uses to authenticate and authorize itself to other agents. Agents may be provisioned with one or more credential types as described in Section 6. Unlike static secrets, agent credentials are provisioned dynamically and are intentionally short-lived, eliminating the operational burden of manual expiration management and reducing the impact of credential compromise. Agent credential provisioning must operate autonomously, scale to high-churn environments, and integrate closely with the attestation mechanisms that establish trust in the agent at each issuance or rotation event.¶
Agent credential provisioning typically includes two phases:¶
Initial Provisioning: The process by which an agent first acquires a credential bound to its identity. This often occurs immediately after deployment or instantiation and is based on verified properties of the agent (e.g., deployment context, attestation evidence, or orchestration metadata).¶
Rotation/Renewal: The automatic refresh of short-lived credentials before expiration. Continuous rotation ensures that credentials remain valid only for the minimum necessary time and that authorization state reflects current operational conditions.¶
The use of short-lived credentials provides a signiifcant improvement in the risk profile and risk of credential exposure. It provides an alternative to explicit revocation mechanisms and simplifies lifecycle management in large, automated environments.¶
Deployed frameworks such as [SPIFFE] provide concrete mechanisms for automated, short-lived credential provisioning at runtime based on workload attestation. In addition to issuing short-lived credentials, [SPIFFE] also provisions ephemeral cryptographic key material bound to each credential, further reducing the risks associated with compromising long-lived keys.¶
Agents may authenticate to one another using a variety of mechanisms, depending on the credentials they possess, the protocols supported in the deployment environment, and the risk profile of the application. As described in the WIMSE Architecture [WIMSE_ARCH], authentication can occur at either the network layer or the application layer, and many deployments rely on a combination of both.¶
Network-layer authentication establishes trust during the establishment of a secure transport channel. The most common mechanism used by agents is mutual TLS (mTLS), in which both endpoints present X.509-based credentials and perform a bidirectional certificate exchange. When paired with short-lived workload identities—such as those issued by SPIFFE or WIMSE—mTLS provides strong channel binding and cryptographic proof of control over the agent’s credential.¶
mTLS is particularly well-suited for environments where transport-level protection, peer authentication, and ephemeral workload identity are jointly required. It also simplifies authorization decisions by enabling agents to associate application-layer requests with an authenticated transport identity.¶
Limitations There are scenarios where transport-layer authentication is not desirable or cannot be relied upon. In architectures involving intermediaries—such as API gateways, service meshes, load balancers, or protocol translators, TLS sessions are often terminated and re-established, breaking the end-to-end continuity of transport-layer identity. Similarly, some deployment models (e.g., serverless platforms, multi-tenant edge environments, or cross-domain topologies) may obscure or abstract transport identity, making it difficult for relying parties to bind application-layer actions to a transport-level credential. In these cases, application-layer authentication provides a more robust and portable mechanism for expressing agent identity and conveying attestation or policy-relevant attributes.¶
Application-layer authentication allows agents to authenticate independently of the underlying transport. This enables end-to-end identity preservation even when requests traverse proxies, load balancers, or protocol translation layers.¶
The WIMSE working group defines the following authentication mechanisms that may be used by agents:¶
WIMSE Workload Proof Tokens (WPTs) are a protocol-independent, application-layer mechanism for proving possession of the private key associated with a Workload Identity Token (WIT). WPTs are generated by the agent, using the private key matching the public key in the WIT. A WPT is defined as a signed JSON Web Token (JWT) that binds an agent’s authentication to a specific message context, for example, an HTTP request, thereby providing proof of possession rather than relying on bearer semantics [WIMSE_WPT].¶
WPTs are designed to work alongside WITs [WIMSE_CRED] and are typically short-lived to reduce the window for replay attacks. They carry claims such as audience (aud), expiration (exp), a unique token identifier (jti), and a hash of the associated WIT (wth). A WPT may also include hashes of other related tokens (e.g., OAuth access tokens) to bind the authentication contexts to specific transaction or authorizations details.¶
Although the draft currently defines detailed usage for HTTP (via a Workload-Proof-Token header), the core format is protocol-agnostic, making it applicable to other protocols. Its JWT structure and claims model allow WPTs to be bound to different protocols and transports, including asynchronous or non-HTTP messaging systems such as Kafka and gRPC, or other future protocol bindings. This design enables relying parties to verify identity, key possession, and message binding at the application layer even in environments where transport-layer identity (e.g., mutual TLS) is insufficient or unavailable.¶
The WIMSE Workload-to-Workload Authentication with HTTP Signatures specification [WIMSE_HTTPSIG] defines an application-layer authentication profile built on the HTTP Message Signatures standard [RFC9421]. It is one of the mechanisms WIMSE defines for authenticating workloads in HTTP-based interactions where transport-layer protections may be insufficient or unavailable. The protocol combines a workload’s Workload Identity Token (WIT), which conveys attested identity and binds a public key, with HTTP Message Signatures using the corresponding private key, thereby providing proof of possession and message integrity for individual HTTP requests and responses. This approach ensures end-to-end authentication and integrity even when traffic traverses intermediaries such as TLS proxies or load balancers that break transport-layer identity continuity. The profile mandates signing of key request components (e.g., method, target, content digest, and the WIT itself) and supports optional response signing to ensure full protection of workload-to-workload exchanges.¶
Agents operate in environments where authorization state can change after an access decision is made. Authroization state may change as a result of policy updates, session termination, device posture changes or elevated risk signals. Implementations SHOULD treat authorization as continuously evaluated rather than a one-time check, and SHOULD include monitoring and remediation mechanisms to detect and communicate changes in authorization status at runtime.¶
Any particiapant in the system, including the Agent, Tool, System, LLM or other resources and service MAY subscribe to change notifications using eventing mechanisms such as the OpenID Shared Signals Framework [SSF] with the Continuous Access Evaluation Profile [CAEP] to receive security and authorization-relevant signals. Upon receipt of a relevant signal (e.g., session revoked, subject disabled, token replay suspected, risk elevated), the recipient SHOULD remediate by attenuating access, such as terminating local sessions, discarding cached tokens, re-acquiring tokens with updated constraints, reducing privileges, or re-running policy evaluation before continueing to allow acccess.¶
To support detection, investigation, and accountability, deployments SHOULD produce durable logs and audit trails for both authorization decisions and subsequent remediations. This includes recording the Agent, User, System, LLM, resource or service identity, the targeted resource/tool, token identifiers or hashes, and the triggering signals that caused re-evaluation or revocation.¶
End-to-end audit is enabled when Agents, Users, Systems, LLMs, Tools, services and resources have stable, verifiable identifiers that allow auditors to trace “which entity did what, using which authorization context, and why access changed over time.”¶
Compliance for Agent-based systems SHOULD be assessed by auditing observed behavior and recorded evidence (logs, signals, and authorization decisions) against the deployment’s Agent Authentication and Authorization Policy Section 12. Since compliance criteria are specific to individual deployments, organizations, industries and jurisdictions, they are out of scope for this framework though implementers SHOULD ensure strong observability and accountable governance, subject to their specific business needs.¶
TODO Security¶
TODO Privac¶
This document has no IANA actions.¶
-----------------------End of "High Level Map"------------------------------¶
-----------------------Early Thoughts on Detailed Spec Below------------------------------¶
During agent execution, authorization must be enforced at all the components involved in the process to provide an in-depth protection of the resources that might be interacted with. For each component, we must consider the following 3 phases: - Negotiation between the component and its caller on the required pieces of authorization required to interact with the component - Acquisition of the piece of authorization by the caller at the authorization server authoritative for the component it wants to communication - Validation of the piece of authorization in the context of the request by the component¶
Those phases rely on the following standards for enforcement of the access control: - [RFC6749] is an established and maintained framework of specifications for requesting, acquiring, and proving ownership of pieces of authorization in the form of bearer tokens. - [OpenIDConnect.AuthZEN] is a new specification for exchanging authorization requests and decisions between the layer acting at the Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). - [OAuth.TRAT] is new specification for formatting pieces of authorization in the form of transaction bound bearer tokens.¶
+----------------+
| Large Language |
| Model (LLM) |
+----------------+
▲ |
│ | ┌(H)┐
| ▼ ▼ │
+--------------+ +------------+ +-------------+ +-----------+
| User / |─(A)(C)─►| AI Agent |─(E)(H)─►| Agent / |─(J)(M)─►| Services |
| / | | (workload) | | / | | and |
| / System |◄────────| |◄────────| / Tools |◄────────| Resources |
+--------------+ +------------+ +-------------+ +-----------+
▲ ▲ ▲ ▲ ▲ ▲
| ┌──(F)─────────────┘ | | | |
| | ┌───(D)───────────┘ (I) | |
| | | +---------------+ | (K) (N)
(B) | | | Policy | | | |
| | └─►| Decision |◄─────────────────┘ | |
| | | Point |◄─────────────────────┼────────────────────┘
| | +---------------+ |
| | ▲ |
| | (G)(L) |
| | ▼ |
| | +---------------+ |
| └─────►| Authorization |◄─────────────────────┘
└──────────►| server |
+---------------+
¶
Key point - OAuth is broadly supported and provides a delegation model for users to clients (aka agents). Agents can obtain access tokens directly (client credentials flow, using above authentication methods) or it can be delegated to them by a user (OAuth flows). Make point that the access token includes the client_id, which is the same as the Agent ID (ore related to it) and can be used for authorization decisions, along with other claims in an Access Token (reference JWT Access token spec). Make provision for opaque tokens as well. Discuss Downscoping of agent authorization using transaction tokens. Discuss cross-domain authorization (use cases) and how it may be achieved (identity chaining and cross-domain authorization). Discuss human in the loop authorization. Note concerns, refer to cross-device BCP as examples of consent phishing attacks. Talk about CIBA as a protocol.¶
### (A) Negotiation - OPTIONAL¶
Following [RFC9728], the System MUST act as an OAuth2 client. It MUST interact with the AI Agent on its metadata endpoint which MUST be an OAuth 2.0 protected resource as defined by [RFC9728].¶
The System will then understand which Authorization Server MUST be the authority this AI Agent; which scopes or authorization details values MAY be required to access this AI Agent; and if extension mechanisms MAY be required to fulfil.¶
To access an AI Agent, the System MUST present its authorization credential as defined in section 7 of [RFC6749] as well as defined in [RFC6750]. The client MUST be able to process error codes as defined in section 3 of [RFC6750].¶
The AI Agent MAY request additional details to be provided through a new authorization credentials using [OAuth.step-up.Auth-RFC9470] or error codes as defined in [RFC6750].¶
The AI Agent MUST validate the presented token as described in [RFC6749] as well as defined in [RFC6750].¶
If token introspection is required, the AI Agent MUST follow [RFC7662] as well as [RFC9701].¶
If the provided token is a JWT profiled token as defined in [RFC9068], the AI Agent MUST follow the section 2 of this specification as part of the token validation.¶
If the AI Agent delegates its access control logic to a Policy decision point, it MUST follow [OpenIDConnect.AuthZEN] specification for requesting and receiving a decision for the access.¶
Interactions between an AI Agent and Tools are globally specified by [MCP]. Those sections only focus on the Identification, authentication, and authorization aspects of the specification.¶
Interactions between an AI Agent and other AI Agents are globally specified by [A2A]. Note that derived specifications and domain specific specification have emerged like [AP2] for Agent payment interaction, [ACP] for Agent to commerce flows. Those sections only focus on the Identification, authentication, and authorization aspects of those specifications.¶
Following [MCP], the AI Agent MUST interact with Tools on the metadata endpoint of an OAuth 2.0 protected resource to understand which Authorization Server is the authority this resource; which scopes or authorization details values MAY be required to access this resources; and if proof of possession needs to be presented as standardized with [RFC9449].¶
Following [A2A], the AI Agent MUST interact with the other Agent through their Agent Card. If Extended Agent Card is implemented, the calling AI Agent MUST collect the information to understand which Authorization Server is the authority this resource; which scopes or authorization details values MAY be required to access this resources; and if proof of possession needs to be presented as standardized with [RFC9449].¶
[ACP] and [AP2] Agents are expected to follow the same Agent Card feature as [A2A] Agents.¶
TODO acknowledge.¶