]> Anthropic

paulc@anthropic.com

sec agent identity AIMS workload identity workload authorization grant This document profiles the Agent Identity Management System (AIMS) framework for agent platforms that host many agent instances per customer. Each agent is identified by an opaque, non-reassignable agent identifier; the agent obtains access tokens by presenting a JWT authorization grant (RFC 7523), signed by the platform's per-tenancy issuer, in the assertion parameter at the authorization server protecting the resource server. Trust is established once, by reference to the issuer's published metadata and keys; agent creation requires no per-agent step at the authorization server or resource server; and authorization is expressed over platform-asserted agent properties that resource servers map locally to permissions. This profile addresses agents acting on their own behalf; access on behalf of a user or other principal is out of scope, though the design is intended to compose with existing delegation mechanisms in which the agent appears as the actor. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at . Note to Readers This document is an early, exploratory individual draft, published to solicit discussion of the deployment pattern it describes. It is not a working group document, does not describe a shipped or committed design, and does not represent a position or roadmap of the author's employer. Every aspect of it is subject to change or withdrawal, including whether this profile should exist as a separate document at all. Most sections are placeholders. Issues and pull requests: https://github.com/pcarleton/draft-carleton-workload-authz-grant.

Introduction Agent platforms increasingly host many agent instances per customer, created and retired at the cadence at which the customer organizes its work -- per channel, repository, or pipeline. An individual agent may persist for weeks or months, but the person creating it is typically not the person authorized to provision credentials at the resource servers it will access. Per-agent credentials are therefore not issued in practice, and deployments collapse to a single credential shared across all agents of an installation -- the pattern , Section 7, identifies as an antipattern -- at the cost of any attribution of an individual agent's actions at the resource server. Existing workload identity federation addresses an analogous problem between an organization's workloads and infrastructure providers, but its claim and policy semantics are defined per provider rather than portably, and it has not been applied between agent platforms and SaaS resource servers. The Model Context Protocol's proposed Workload Identity Federation extension defines the corresponding wire mechanics for MCP servers; this profile is intended to be interoperable with it. This document specifies a profile of for that deployment pattern. Agent platforms are the motivating deployment, and the terminology throughout uses "Agent"; the mechanism itself is not agent-specific and applies to any platform hosting workloads that need federated access to third-party resource servers. The mechanism is called the Workload Authorization Grant (WAG): a platform-signed JWT authorization grant asserting a workload's identity and platform-asserted properties. Trust in the platform's issuer is established once, by reference, and thereafter agents are accepted on first presentation with no per-agent registration step. A design goal of this profile is a minimal adoption path for services that already operate an OAuth deployment: supporting it requires changes only at the authorization server's token endpoint, which accepts the JWT authorization grant from allowlisted issuers. The access tokens the authorization server issues are unchanged in format and semantics, and resource servers continue to trust their authorization server exactly as they do today.

Relationship to AIMS remains the base specification for anything not restated here. This profile constrains as follows:

AIMS component	Here	Relationship
Identifiers (Sec. 6)		Constrained: opaque, immutable, non-reassignable agent identifier, RECOMMENDED to be a Workload Identifier , carried as sub
Credentials (Sec. 7), Authentication (Sec. 9)		Constrained: JWT authorization grant (assertion), platform-signed; no per-agent credential; client identity deliberately unspecified
Credential Provisioning (Sec. 8)		Constrained: platform-internal
Authorization (Sec. 10, case 10.4.2)		Added: standard property claims; by-reference trust ()
Monitoring/Remediation (Sec. 11)		TODO
Policy (Sec. 12), Compliance (Sec. 13)	--	Inherited

Relationship to WIMSE and SPIFFE TODO. A reader arriving from WIMSE or SPIFFE will ask where the Workload Identity Token and the SPIFFE ID are in this design. Explain: why the assertion is an authorization grant rather than a WIMSE WIT; how the Agent Identifier's RECOMMENDED URI form relates to a SPIFFE ID; and what changes if the Platform's issuer is backed by a SPIFFE/WIMSE-style workload identity plane rather than operated as a standalone OAuth issuer.

Scope In scope: agents acting on their own behalf (, Section 10.4.2). Out of scope: on-behalf-of access, legacy integration via static credentials, runtime attestation, agent-to-agent protocols. This profile deliberately does not specify on-behalf-of flows; the design is intended to compose with delegation mechanisms in which the agent appears as the actor rather than the subject (e.g., the act claim and actor_token parameter of , or ), and that composition is left to future documents.

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 Platform ("Platform"):

The service that hosts Agents and operates the per-tenancy issuers that vouch for them.

Agent:

A hosted workload with its own Agent Identifier, context, and configuration.

Agent Property:

A Platform-asserted attribute carried as a claim in the authorization grant.

Authorization Server (AS):

The OAuth authorization server at which Agents present authorization grants and obtain access tokens; commonly, but not necessarily, operated by the same vendor as the Resource Server it protects.

Resource Server (RS):

The service holding customer resources, accessed with the access tokens the Authorization Server issues.

Enterprise IdP:

The customer's identity provider (optional).

Customer Administrator:

The human who performs one-time trust establishment.

Deployment Model TODO: diagram. One-time trust establishment by the Customer Administrator (); agent creation by end users with no interaction with the Resource Server (); per-request JWT authorization grant ().

Agent Identity Model An Agent's identity has three units: the tenancy's issuer, which signs assertions about the Agent; the Agent Identifier, opaque, unique within the issuer, immutable, and never reassigned, carried as the assertion's sub (); and claims, carrying everything else (). Renaming an Agent MUST NOT change its Agent Identifier. Resource Servers MUST NOT parse or pattern-match the Agent Identifier for authorization; single-agent policy is an exact match on it. The Agent Identifier MAY be, and is RECOMMENDED to be, a Workload Identifier URI with an opaque path; a bare opaque string is also permitted. URI form costs no opacity -- the path remains meaningful only to the issuing Platform -- and carries the trust boundary inside the identifier's authority component, which is what relying parties that evaluate only subject and audience need (). When the Agent Identifier is a URI, the Authorization Server validates its authority component against the allowlisted issuer's tenancy once, at token issuance; Resource Servers treat the complete identifier as an opaque, exact-match string regardless of form and MUST NOT derive trust from its components.

Authorization Grant The Agent obtains access tokens from the Authorization Server by presenting a JWT as an authorization grant per , Section 2.1, issued by the Platform as a third party in the sense of , Section 3. The token request carries grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, the JWT in the assertion parameter, and the target resource in the resource parameter . This profile deliberately does not specify the OAuth client identity or attach semantics to client_id. In the simplest deployment the token request is made without client authentication. Deployments MAY layer client authentication on top -- for example, the Platform authenticating as an OAuth client in its own right with a Client ID Metadata Document and a private_key_jwt client assertion -- a composition that becomes natural when the authorization grant's issuer is the customer's Enterprise IdP rather than the Platform (obtained, e.g., by token exchange with the IdP). This document intentionally leaves that composition open rather than fully specifying it ().

JWT Authorization Grant Claims The following claims are used within the Workload Authorization Grant JWT:

iss:

REQUIRED - The issuer identifier of the Platform's per-tenancy issuer ().

sub:

REQUIRED - The Agent Identifier as defined in .

aud:

REQUIRED. The value SHOULD include both the Authorization Server's issuer identifier and its token endpoint URL; an Authorization Server supporting this profile MUST accept an assertion whose aud includes either value ( itself leaves the audience strings to out-of-band configuration). adds the issuer identifier as an audience option for authorization grants (while restricting client-authentication assertions, a different slot, to it alone); carrying both values keeps an assertion valid across deployed and future processing.

jti:

REQUIRED - Unique ID of this JWT as defined in .

exp:

REQUIRED - as defined in .

iat:

REQUIRED - as defined in .

The assertion is signed under a key in the issuer's published JWK Set . The Authorization Server MUST resolve the signing key by iss (), not via a client registration. The assertion carries the Agent's Properties (), and the Authorization Server MUST make them available to the Resource Server's authorization decision. Authorization Servers supporting this profile MUST include urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported in their metadata . shows an example token request (with extra line breaks for display purposes only):

Example token request

shows the decoded claims of the assertion carried in that request; name, namespace, groups, roles, and ctx are Agent Properties ():

Example assertion claims

The Authorization Server MUST NOT issue refresh tokens, as access tokens are short-lived and audience-restricted . Assertion lifetimes SHOULD be as short as system availability constraints allow. TODO: proof-of-possession -- the assertion is a bearer grant; options are sender-constrained access tokens, or attestation-based client authentication (Platform as client attester, agent instance signs the PoP JWT) if agent instances hold keys.

Trust Establishment The Customer Administrator once records, at the Authorization Server, an allowlist entry binding one issuer to one tenancy: the issuer identifier, from which the issuer's metadata and JWK Set location are discovered per (retrieved over https ), and the tenancy's initial Property-to-permission mapping for the Resource Server (). Establishment is by reference; no keys or secrets are transferred, and key rotation is by JWK Set update alone. Platforms serving multiple customers MUST use a distinct issuer per tenancy: the issuer is the trust boundary the allowlist expresses, and a shared issuer would move tenancy enforcement into claim evaluation at every Authorization Server -- including relying parties that can evaluate only subject and audience (). The proposed MCP Workload Identity Federation extension recommends (SHOULD) that authorization servers rely only on issuing keys bound to a single tenant; this profile deliberately tightens that boundary to a per-tenancy issuer MUST. Multi-issuer operation is scoped by issuer throughout. An Authorization Server MUST resolve and cache keys per allowlist entry and MUST NOT merge key sets across issuers, and it MUST interpret sub and jti only within the scope of the presenting iss. A Resource Server that keeps a Property-to-permission mapping () likewise scopes it by iss. An Agent Identifier is unique within its issuer, not globally: policy and audit records are keyed on the (iss, sub) pair, or on the complete URI-form identifier, which carries the tenancy in its authority component.

Agent Instantiation Creating an Agent is Platform-internal and MUST NOT require any ahead-of-time interaction with the Resource Server, the Authorization Server, an Enterprise IdP, or the Customer Administrator. The Authorization Server first learns that an Agent exists when the Agent presents its first authorization grant: it MUST accept a previously-unseen Agent Identifier presented as sub under an allowlisted issuer, and authorization -- at the Authorization Server and the Resource Server alike -- is via , never identifier structure. Agents are not dynamically registered clients . Optionally, a Platform MAY project Agents into an Enterprise IdP (e.g., as resources) for inventory and lifecycle governance. Such projection MUST NOT be required ahead of time: performing it just in time, including synchronously during first token issuance, is acceptable. TODO: BYO-IdP deployment model.

Agent Properties and Authorization TODO. Initial standard property claims: name, a human-readable display name as in an OpenID Connect ID Token (mutable, and never a key for authorization or attribution -- that is the Agent Identifier); namespace, groups, roles, and an optional ctx naming the collaboration context; additional attributes use collision-resistant claim names per , Section 4.3. TODO: whether an Agent needs a human-usable, "@"-referenceable address within the Platform, analogous to sharing a document with an email address, distinct from both name and the opaque Agent Identifier; noted here, deliberately unsolved. A Resource Server keeps a local, administrator-controlled mapping from Property predicates to permissions; possession of a Property is not itself authorization. Deny semantics do not travel. TODO: worked example.

Attribution TODO. The Authorization Server logs jti at token issuance; Resource Servers log the Agent Identifier (sub) and referenced Properties; internal fan-out via rather than forwarding the access token.

Retirement and Lifecycle Retirement is expressed by cessation: the Platform stops signing assertions for a retired Agent, so residual access is bounded by the remaining lifetime of any outstanding assertion plus the lifetime of any access token already issued. Assertion and access-token lifetimes SHOULD be chosen with this bound in mind. No signal yet informs an Authorization Server that an Agent Identifier is permanently retired; that gap is shared with neighboring workload identity ecosystems, whose common baseline is likewise short credential lifetimes plus ceasing issuance (). Broader lifecycle management is out of scope for this document. In particular, resources that come to be owned by an Agent (documents, records, long-lived artifacts) need succession planning when the Agent is retired; this profile makes the retirement event's access consequences legible, but does not manage its downstream effects.

Open Issues

• Relying parties that authorize only on subject and audience (e.g., cloud IAM federation trust policies) and cannot evaluate Property predicates; URI-form Agent Identifiers () carry the tenancy inside the identifier for this case, but the residual gap is unassessed.
• Proof-of-possession: the authorization grant is bearer; see .
• Issuer placement: issuer operated by the Platform versus by the Enterprise IdP, with the Platform obtaining assertions by token exchange with the IdP; client authentication is redundant in the former case and load-bearing in the latter; what, if anything, client_id means in each case.
• Staleness and retirement signaling in place of per-agent revocation (issuer- or Property-scoped epoch versus event push versus lifetime alone, ); a gap shared with neighboring workload identity ecosystems.
• Addressing: whether an Agent needs a human-usable, "@"-referenceable address (to share a resource with an agent the way one shares with an email address), distinct from the display name and the Agent Identifier.

Security Considerations TODO: unseen agent identifiers under trusted issuers; issuer allowlist as the trust boundary; tenant confusion at multi-issuer Authorization Servers (); bearer-assertion theft and assertion lifetime; Platform as root of trust; credential non-exposure to the model; automated trust establishment.

IANA Considerations This document has no IANA actions at this time; provisional claim names () may be registered in a future revision.

References Normative References A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (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 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 authentication and authorization. Zscaler Palo Alto Networks This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. Self-Issued Consulting Ping Identity Disney Okta This document updates RFC7521, RFC7522, RFC7523 and RFC9126 with respect to the treatment of audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Okta This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. MATTR Bundesdruckerei SPRIND This specification defines an extension to the OAuth 2.0 protocol (RFC 6749) that enables a client instance to include a key-bound attestation when interacting with an Authorization Server or Resource Server. This mechanism allows a client instance to prove its authenticity verified by a client attester without revealing its target audience to that attester. It may also serve as a mechanism for client authentication as per OAuth 2.0. CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Microsoft Okta Microsoft Nextident The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. This document provides a platform-neutral schema for representing AI agents' identities in SCIM JSON format, enabling them to be transferred using the SCIM protocol between a client and service provider. This establishes an agentic identity so that an agent can subsequently be authenticated and authorized to interact with the service. Okta Independent Ping Identity This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. This pattern is informally referred to as Cross-App Access (XAA). Model Context Protocol Community n.d.

Acknowledgments The author thanks Kevin Kelley, Aaron Parecki, Brian Campbell, Pieter Kasselman, Nick Steele, Emily Lauber, and Maxwell Gerber for discussions that shaped this document. This profile builds directly on the Agent Identity Management System framework and would not exist without it. Further acknowledgments will be added in a future revision.