Network Working Group P. Kasselman Internet-Draft DeFakto Intended status: Informational J. Lombardo Expires: 22 August 2026 AWS Y. Rosomakho Zscaler 18 February 2026 Agent-to-Agent Authentication and Authorization draft-agent2agent-kasselman_lombardo-agent2agent-auth-latest Abstract 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. About This Document 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. Status of This Memo 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 Notice 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. Table of Contents 1. Introduction 2. Conventions and Definitions 3. Agents are workloads 4. Agent Identity Management System 5. Agent Identifier 6. Agent Credentials 7. Agent Attestation 8. Agent Credential Provisioning 9. Agent Authentication 9.1. Network layer authentication 9.2. Application layer authentication 9.2.1. WIMSE Proof Tokens (WPTs) 9.2.2. HTTP Message Signatures (HTTP Sig) 10. Agent Authorization 10.1. Leverage OAuth 2.0 as a Delegation Authorization Framework 10.2. Use of OAuth 2.0 Access Tokens 10.3. Obtaining an OAuth 2.0 Access Token 10.3.1. User Delegates Authorization 10.3.2. Agent Obtains Own Authorization 10.3.3. System Access to Agents 10.3.4. OAuth 2.0 Security Best Practices 10.4. Risk reduction with Transaction Tokens 10.5. Cross Domain Access 10.6. Human in the Loop 10.7. Tool-to-Service Acccess 10.8. OAuth 2.0 Discovery in Dynamic Environments 10.8.1. Authorization Server Capability Discovery 10.8.2. Protected Resource Capability Discovery 10.8.3. Client Capability Discovery 11. Agent Monitoring and Remediation 12. Agent Authentication and Authorization Policy 13. Agent Compliance 14. Security Considerations 15. Privacy Considerations 16. IANA Considerations 17. Agent Authorization - Next Level Detail 17.1. System to AI Agent 17.1.1. Flow 17.1.2. (B) Initial Authorization 17.1.3. (C) Access to the AI Agent 17.1.4. (D) Controlling access to the AI Agent 17.2. AI Agent To Other Agent / Tools 17.2.1. (E) Negotiation 17.2.2. (F) AI Agent Authorization 17.2.3. Security 17.3. Agent-to-Resource Authorization 17.3.1. Human-in-the loop 17.4. Case of Multi-Domain Authorization 17.4.1. Cross Domain Agent-to-Agent Authorization 17.5. Agent to Agent Authorization 18. Normative References Acknowledgments Authors' Addresses 1. Introduction TODO Introduction 2. Conventions and Definitions 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. 3. Agents are workloads 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 1. Optional: The User or System (e.g. a batch job or another Agent) provides an initial request or instruction to the AI Agent. 2. 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. 3. The LLM returns a response to the AI Agent identifying which Tools it should invoke. 4. Based on the LLM’s output, the AI Agent invokes the relevant Tools (note that a Tool may be another Agent). 5. The Tools interacts with the underlying Services and Resources required to fulfill the requested operation. 6. The underlying Services and Resources returns the information requested by the Tools. 7. 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. 8. 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]. 4. Agent Identity Management System 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. +--------------+----------------------------------+--------------+ | Policy | Monitoring & Remediation | Complaince | | +----------------------------------| | | | Authorization | | | +----------------------------------| | | | Authentication | | | +----------------------------------| | | | Provisioning | | | +----------------------------------| | | | Attestation | | | +----------------------------------| | | | Credentials | | | +----------------------------------| | | | Agent Identifier | | +--------------+----------------------------------+--------------+ Figure 2: Agent Identity Management System 5. Agent Identifier 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:/// 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. 6. Agent Credentials 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. 7. Agent Attestation 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. 8. Agent Credential Provisioning 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: 1. *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). 2. *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. 9. Agent Authentication 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. 9.1. Network layer authentication 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. 9.2. Application layer authentication 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: 9.2.1. WIMSE Proof Tokens (WPTs) 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. 9.2.2. HTTP Message Signatures (HTTP Sig) 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. 10. Agent Authorization Agents act on behalf of a user, a system, or on their own behalf as shown in Figure 1 and needs to obtain authorization when interacting with protected resources. 10.1. Leverage OAuth 2.0 as a Delegation Authorization Framework The OAuth 2.0 Authorization Framework [RFC6749] is widely deployed and defines an authorization delegation framework that enables an agent to obtain limited access to a protected resource (e.g. a service or API) under well-defined policy constraints. An agent MUST use OAuth 2.0-based mechanisms to obtain authorization from a user, a system, or on its own behalf. OAuth 2.0 defines a wide range of authorization grant flows that supports these scenarios. In these Oauth 2.0 flows, an Agent acts as an OAuth 2.0 Client to an OAuth 2.0 Authorization Server, which receives the request, evaluate the authorization policy and returns an access token, which the Agent presents to the Resource Server (i.e. the protected resources such as the LLM or Tools in Figure 1) it needs to access to complete the request. 10.2. Use of OAuth 2.0 Access Tokens An OAuth access token represents the authorization granted to the Agent. In many deployments, access tokens are structured as JSON Web Tokens (JWTs) [RFC9068], which include claims such as 'client_id', 'sub', 'aud', 'scope', and other attributes relevant to authorization. The access token MUST include the Agent identity as the 'client_id' claim as defined in Section 2.2 of [RFC9068]. If the Agent is acting on-behalf of another user or system, it MUST include the user or system identifier in the 'sub' claim as defined in Section 2.2 of [RFC9068]. These identitifiers MUST be used by resource servers protected by the OAuth 2.0 authorization service, along with other claims in the access token, to determine if access to a resource should be allowed. The acccess token MAY include additional claims to convey contextual, attestation-derived, or policy-related information that enables fine-grained access control. The resource server MAY use the access token and the information it contains along with other authorization systems (e.g. policy based, attribute based or role based authorization systems) when enforcing access. Where JWT access tokens are not used, opaque tokens may be issued and validated through introspection mechanisms. This framework supports both models and does not require a specific token format, provided that equivalent authorization semantics are maintained. 10.3. Obtaining an OAuth 2.0 Access Token Agents MUST obtain OAuth 2.0 accss tokens using standards OAuth 2.0 Authorization Flows. 10.3.1. User Delegates Authorization When obtaining an access token on-behalf of a user, the Authorization Code Grant MUST be used as described in Section 4.1 of [RFC6749]. 10.3.2. Agent Obtains Own Authorization Agents obtaining access tokens on their own behalf MUST use the Client Credentials Grant as described in Section 4.4 of [RFC6749] or the JWT Authorization Grant as described in section 2.1. of [OAuth.Private.JWT.Auth-RFC7523]. When using the Client Credentials Grant, the Agent MUST authenticate itself using one of the mechanisms described in Section 9 and MUST NOT use static, long lived client secrets to authenticate. 10.3.3. System Access to Agents When Agents are invoked by a System (e.g. a batcch job, or another Agent), the System SHOULD treat the Agent as an OAuth protected resource. The System SHOULD obtain an access token using the same mechanisms defined for an Agent and then present the OAuth access token to the Agent. The agent should validate the access token, including verifiying that the 'aud' claim of the access token includes the Agent. Once validated, the Agent SHOULD use OAuth 2.0 Token Exchange as defined in [RFC8693] to exchange the access token it received for a new access token to access. The Agent then uses the newly issued access token to access the protected resources (LLM or Tools) it needs to complete the request. If a System invokes an Agent and does not treat the Agent as an OAuth protected resource, the Agent MUST obtain its own OAuth access token as described in {#agent_obtains_own_access_token}. 10.3.4. OAuth 2.0 Security Best Practices Agents MUST support the Best Current Practice for OAuth 2.0 Security as described in [RFC9700] when requesting acccess tokens. 10.4. Risk reduction with Transaction Tokens Resources servers, whether they are LLMs, Tools or Agents (in the Agent-to-Agent case) may be composed of multiple microservices that are invoked to complete a request. The access tokens presented to the Agent, LLM or Tools can typically be used with multiple transactions and consequently have broader scope than needed to complete any specific transaction. Passing the access token from one microservice to another within an Agent, LLM or the Tools invoked by the Agent increases the risk of token theft and replay attaccks. For example, an attacker may discover and access token passed between microservices in a log file or crash dump, exfiltrate it, and use it to invoke a new transaction with different parameters (e.g. increase the trnasaction amount, or invoke an unrelated call as part of executing a lateral move). To avoid passing access tokens between microservices, the Agent, LLM or Tools SHOULD exchange the access token it receives for a transaction token, as defined in the Transaction Token specification as defined in [OAuth.TRAT]. The transaction token allows for identity and auhtorization information to be passed along a call chain between microservices. The transaction token issuer enriches the transaction token with context of the caller that presented the access token (e.g. IP address etc), transaction context (transaction amount), identity information and a unique transaction identifier. This results in a dowscoped token that is bound to a specific transaction that cannot be used as an access token, with another transaction, or within the same transaction with modified transaction details (e.g. change in transaction amount). Transaction tokens are typically short lived, further lmiting the risk in case they are obtained by an attacker by liomiting the time window during which these tokens will be accepted. A transaction token MAY be used to obtain an access token to call another service (e.g. another Agent, Tool or LLM) by using OAuth 2.0 Token Exchange as defined in [RFC8693]. 10.5. Cross Domain Access Agents often require access to resources that are protected by different OAuth 2.0 authorization servers. When the components in Figure 1 are protected by different logical authorization servers, an Agent SHOULD use OAuth Identity and Authorization Chaining Across Domains as defined in [OAuth.IDChaining], or a derived specification such as the Identity Assertion JWT Authorization Grant [OAuth.IDJAG], to obtain an access token from the relevant authorization servers. When using OAuth Identity and Authorization Chaining Across Domains ([OAuth.IDChaining]), an Agent SHOULD use the access token or transaction token it received to obtain a JWT authorization grant as described in section 2.3 of [OAuth.IDChaining] and then use the JWT authorization grant it receives to obtain an access token for the resource it is trying to access as defined in section 2.4 of [OAuth.IDChaining]. When using the Identity Assertion JWT Authorization Grant [OAuth.IDJAG], the identity assertion (e.g. the OpenID Connect ID Token or SAML assertion) for the target end-user is used to obtain a JWT assertion (ID-JAG) as described in section 4.3 of [OAuth.IDJAG], which is then used to obtain an access token as described in section 4.4 of [OAuth.IDJAG]. OAuth Identity and Authorization Chaining Across Domains ([OAuth.IDChaining]) provides a general mechanism for obtaining cross-domain access that can be used whether an identity assertion like a SAML or OpenID Connect token is available or not. The Identity Assertion JWT Authorization Grant [OAuth.IDJAG] is optimised for cases where an identity assertion like a SAML or OpenID Connect token is available from an identity provider that is trusted by all the OAuth authorization servers as it removes the need for the user to re-authenticate. This is typically used within enterprise deployments to simplify authorization delegation for multiple software-as-a-service offerings. 10.6. Human in the Loop An OAuth authorization server MAY conclude that the level of access to a resource that an Agent, LLM or Tool is requesting requires additional authorization from the User. When it determines that additional authorization is required, it SHOULD either decline the request or request additional authorization from the User by using the OpenID foundation Client Initiated Backchannel Authentication (CIBA). This will trigger a request to the user to grant additional authorization (e.g. through a push notification). Once the user grant authorization, the authorization server issues an access token to the Agent which it may then use to complete the task. 10.7. Tool-to-Service Acccess Tools expose interfaces to underlying services and resources. Access to the Tools SHOULD be controlled by OAuth which MAY be augmented by policy, attribute or role based authorization systems (amongst others). If the Tools are implemented as one or more microservices, it should use transaction tokens to reduce risk as described in Section 10.4 to avoid passing access tokens around within the Tool implementation. Access from the Tools to the resources and services MAY be controlled through a variety of auhtorization mechanisms, includidng OAuth. If access is controlled through OAuth, the Tools SHOULD use OAuth 2.0 Token Exchange as defined in [RFC8693] to exchange the access token it received for a new access token to access the resource or service in question. If the Tool needs acces to a resource protected by an auhtorization server other than the Tool's own authorization server, it SHOULD use the OAuth Identity and Authorization Chaining Across Domains ([OAuth.IDChaining]) to obtain an access token from the authroization server protecting the resource it needs to access. 10.8. OAuth 2.0 Discovery in Dynamic Environments In dynamic agent deployments (e.g., ephemeral workloads, multi-tenant services, and frequently changing endpoint topology), Agents and other participants MAY use OAuth discovery mechanisms to reduce static configuration and to bind runtime decisions to verifiable metadata. 10.8.1. Authorization Server Capability Discovery An Agent that needs to obtain tokens MAY discover authorization server endpoints and capabilities using OAuth 2.0 Authorization Server Metadata [RFC8414] and/or OpenID Connect Discovery [OpenIDConnect.Discovery]. This allows the Agent to learn the as issuer identifier, authorization and token endpoints, supported grant types, client authentication methods, signing keys (via jwks_uri), and other relevant capabilities without preconfiguring them. 10.8.2. Protected Resource Capability Discovery When an Agent is invoking a Tool, the Agent MAY use OAuth 2.0 Protected Resource Metadata [RFC9728] to discover how the resource is protected, including the resource identifier and the applicable Authorization Server(s) that protects Tool access. This enables an Agent to select the correct issuer/audience and token acquisition flow at runtime, even when resources are deployed or moved dynamically. A Tool that atttempts to acccess and OAuth protected resource MAY use OAuth 2.0 Protected Resource Metadata [RFC9728] in a similar way as an Agent. Similarly, a System may use [RFC9728] when accessing an Agent. 10.8.3. Client Capability Discovery Other actors (e.g., Authorization Servers, registrars, or policy systems) may need to learn about any entities (System, Agent, Tool) that acts as OAuth clients. Where supported, they MAY use Client ID Metadata Documents [OAuth.CIMD], which allow a client to host its metadata at a URL-valued client_id so that the relying party can retrieve client properties (e.g., redirect URIs, software statement / display information, and other registered client metadata) without prior bilateral registration. As an alternative, entities acting as OAuth clients MAY register their capabilities with authroization servers as defined in the OAuth 2.0 Dynamic Client Registration Protocol [RFC7591]. 11. Agent Monitoring and Remediation 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.” 12. Agent Authentication and Authorization Policy The configuration and runtime parameters for Agent Identifiers Section 5, Agent Credentials Section 6, Agent Attestation Section 7, Agent Credential Provisioning Section 8, Agent Authentication Section 9, Agent Authorization Section 10 and Agent Monitoring and Remediation Section 11 collectively constitute the authentication and authorization policy within which the Agent operates. Because these parameters are highly deployment- and risk-model- specific (and often reflect local governance, regulatory, and operational constraints), the policy model and document format are out of scope for this framework and are not recommended as a target for standardization within this specification. Implementations MAY represent policy in any suitable “policy-as-code” or configuration format (e.g., JSON/YAML), provided it is versioned, reviewable, and supports consistent evaluation across the components participating in the end-to-end flow. 13. Agent Compliance 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. 14. Security Considerations TODO Security 15. Privacy Considerations TODO Privac 16. IANA Considerations This document has no IANA actions. -----------------------End of "High Level Map"------------------------------ -----------------------Early Thoughts on Detailed Spec Below------------------------------ 17. Agent Authorization - Next Level Detail 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. 17.1. System to AI Agent ### (A) Negotiation - OPTIONAL 17.1.1. Flow 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. 17.1.1.1. Security The System MUST follow the best current practices described in [RFC9700]. 17.1.2. (B) Initial Authorization Based on the information collected as part of (A) or based on its configuration, the System MUST initiate an authorization request to the Authorization Server acting as authority for the AI Agent. 17.1.2.1. Flow For this, the System MUST use one of the grant types described in [RFC6749] as follows: * In a case of the System is acting on its behalf, it MUST start a client credential grant flow as described in section 1.3.4 of [RFC6749]; * In the case of the System is acting on behalf of a user: - If the System can interact directly with the user (e.g., browser-based), the System MUST use the authorization code grant flow as described in Section 4.1 of [RFC6749]; - If the System has limited input capabilities, but the User is present at the device, the System MUST use the Device Authorization Grant [RFC8628]; - If the User is not present at the consuming device (decoupled flow), the System MUST use Client-Initiated Backchannel Authentication [OpenIDConnect.CIBA]. 17.1.2.2. Extensions As part of the grant flow, the User / System MUST also fulfill all the expected extensions it has an understanding of. For example, not exhaustively: - Binding the requested tokens to a possessed key as defined in [RFC9449] or {#wpt} - Requesting additional authorization details as defined in [RFC9396] or [RFC9126] 17.1.2.3. Identification The System MUST act as an OAuth2 Client which MAY be assigned a WIMSE identifier, which MAY be a SPIFFE ID. If so, the System MUST provide a way to resolve one value to the other, either through: - A metadata document URL used OAuth2 Client identifier as defined in [OAuth.CIMD]; - Metadata information provided as part of the Private Key JWT OAuth client credential as defined in [OAuth.Private.JWT.Auth-RFC7523] - Public Certificate information provided as part of the mutual TLS OAuth client credential as defined in [OAuth.mTLS.Auth-RFC8705] 17.1.2.4. Authentication The System MUST authentication using either: - Private Key JWT OAuth client authentication as defined in [OAuth.Private.JWT.Auth-RFC7523] - Mutual TLS OAuth client authentication as defined in [OAuth.mTLS.Auth-RFC8705] 17.1.2.5. Security The System MUST follow the best current practices described in [RFC9700] for the interactions with the AI Agent and [RFC8725] when handling JWTs. 17.1.3. (C) Access to the AI Agent 17.1.3.1. Flow 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]. 17.1.3.2. Security The client MUST follow the best current practices described in [RFC9700]. 17.1.4. (D) Controlling access to the AI Agent 17.1.4.1. Flow 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. 17.1.4.2. Security TODO 17.2. AI Agent To Other Agent / Tools 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. 17.2.1. (E) Negotiation 17.2.1.1. Case of a Tool 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]. 17.2.1.2. Case of an Agent 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. 17.2.2. (F) AI Agent Authorization Based on the information collected as part of (E), the AI Agent is initiating an authorization request with the Authorization Server acting as authority for the AI Tools. Such authorization request can allow to down, change or translate scope; enrich the authorization with new details based on the context; extend the time boundaries of the authorization; or change from a delegation mode to an impersonation mode and reversely. * If the AI Agent acts on its behalf as a system: - If it does not want or need to refer to the previous context, it MUST start a client credential grant flow as described in section 1.3.4 of [RFC6749]; - If it does want or need to refer to the previous context, it MUST start a token exchange flow as described in [RFC8693]. The AI Agent will be able to decide in between obtaining tokens representing a Delegation or an Impersonation as described in section 1.1 of the specification. * If the AI Agent acts on delegation by a user: - If the AI Agent can interact and want to interact with the user through the client, it MUST start an authorization code grant flow as described in section 1.3.1 of [RFC6749]; - If the AI Agent cannot or does not want to interact with the user through the client, it MAY: o Start a token exchange flow as described in [RFC8693]. The AI Agent will be able to decide in between obtaining tokens representing a Delegation or an Impersonation as described in section 1.1 of the specification. o Start a client initated backchannel authorized request as described in [OpenIDConnect.CIBA] If the AI Agent knows that the underlying actions Transaction Tokens 17.2.3. Security If the metadata documents are cryptographically signed, the AI Agent MUST validate the signature before using the information for any authentication and authorization decision. 17.3. Agent-to-Resource Authorization Present token, peform additional authorization (RBAC etc?) Direct or via tools Resources, services. Agent -> Tool -> Service -> Resource 17.3.1. Human-in-the loop Agent framework problem -> human in the loop - confirm something that it can already do - agent framework capability - confirmation. Risk management flow. Human in the loop - request esalated privelages. Step-up authorization - refernece the draft (maybe) MCP Elicitation to agent to perform some browser things - start authz code grant flow. CIBA 17.4. Case of Multi-Domain Authorization 17.4.1. Cross Domain Agent-to-Agent Authorization Identiyt chaining, ID-Jag. 17.5. Agent to Agent Authorization 18. Normative References [A2A] "Agent2Agent (A2A) Protocol", n.d., . [ACP] "Agentic Commerce Protocol", n.d., . [AP2] "Agent Payments Protocol (AP2)", n.d., . [CAEP] "OpenID Continuous Access Evaluation Profile 1.0", n.d., . [MCP] "Model Context Protocol", n.d., . [OAuth.CIMD] "OAuth Client ID Metadata Document", n.d., . [OAuth.IDChaining] "OAuth Identity and Authorization Chaining Across Domains", n.d., . [OAuth.IDJAG] "Identity Assertion JWT Authorization Grant", n.d., . [OAuth.mTLS.Auth-RFC8705] "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", n.d., . [OAuth.Private.JWT.Auth-RFC7523] "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", n.d., . [OAuth.SPIFFE.Client.Auth] "OAuth SPIFFE Client Authentication", n.d., . [OAuth.step-up.Auth-RFC9470] "OAuth 2.0 Step Up Authentication Challenge Protocol", n.d., . [OAuth.TRAT] "Transaction Tokens", n.d., . [OpenIDConnect.AuthZEN] Gazitt, O., Ed., Brossard, D., Ed., and A. Tulshibagwale, Ed., "Authorization API 1.0", 2026, . [OpenIDConnect.CIBA] "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", n.d., . [OpenIDConnect.Discovery] "OpenID Connect Discovery 1.0", n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] "The OAuth 2.0 Authorization Framework", n.d., . [RFC6750] "The OAuth 2.0 Authorization Framework: Bearer Token Usage", n.d., . [RFC7591] "OAuth 2.0 Dynamic Client Registration Protocol", n.d., . [RFC7662] "OAuth 2.0 Token Introspection", n.d., . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8414] "OAuth 2.0 Authorization Server Metadata", n.d., . [RFC8628] "OAuth 2.0 Device Authorization Grant", n.d., . [RFC8693] "OAuth 2.0 Token Exchange", n.d., . [RFC8725] "JSON Web Token Best Current Practices", n.d., . [RFC9068] "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", n.d., . [RFC9126] "OAuth 2.0 Pushed Authorization Requests", n.d., . [RFC9334] "Remote ATtestation procedureS (RATS) Architecture", n.d., . [RFC9396] "OAuth 2.0 Rich Authorization Requests", n.d., . [RFC9421] "HTTP Message Signatures", n.d., . [RFC9449] "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", n.d., . [RFC9700] "Best Current Practice for OAuth 2.0 Security", n.d., . [RFC9701] "JWT Response for OAuth 2.0 Token Introspection", n.d., . [RFC9728] "OAuth 2.0 Protected Resource Metadata", n.d., . [SPIFFE] "Secure Production Identity Framework for Everyone", n.d., . [SPIFFE_BUNDLE] "SPIFFE Bundle", n.d., . [SPIFFE_FEDERATION] "SPIFFE Federation", n.d., . [SPIFFE_ID] "SPIFFE-ID", n.d., . [SPIFFE_JWT] "JWT-SVID", n.d., . [SPIFFE_X509] "X509-SVID", n.d., . [SSF] "OpenID Shared Signals Framework Specification 1.0", n.d., . [WIMSE_ARCH] "Workload Identity in a Multi System Environment (WIMSE) Architecture", n.d., . [WIMSE_CRED] "WIMSE Workload Credentials", n.d., . [WIMSE_HTTPSIG] "WIMSE Workload-to-Workload Authentication with HTTP Signatures", n.d., . [WIMSE_ID] "WIMSE Identifier", n.d., . [WIMSE_WPT] "WIMSE Proof Token", n.d., . Acknowledgments TODO acknowledge. Authors' Addresses Pieter Kasselman DeFakto Email: pieter@defakto.security Jean-François Lombardo AWS Email: jeffsec@amazon.com Yaroslav Rosomakho Zscaler Email: yrosomakho@zscaler.com