]> Independent

public@karlmcguinness.com

Security Web Authorization Protocol OAuth AI agent agent identity client instance attestation This specification profiles the OAuth 2.0 Client Instance Assertion for AI agent deployments, where a single OAuth client identifier represents an agent platform running many concurrent agent instances. It defines claims that convey an attested agent instance identifier and agent provenance (platform, model, runtime environment) from an agent attester to the authorization server, rules for surfacing that identity in issued access tokens, and delegation-chain semantics for agents that spawn sub-agents. The claims are carrier-independent: they may be conveyed in a Client Instance Assertion or in a Client Attestation defined by OAuth 2.0 Attestation-Based Client Authentication. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction AI agent platforms are OAuth clients. A platform registers a single client_id and then runs many concurrent agent instances under it: one per user session, task, or delegated workflow. Resource servers receiving access tokens from these platforms see only the platform's client_id; this includes Model Context Protocol servers (), which use OAuth for authorization. Every agent session collapses into one identity, defeating per-agent authorization, audit attribution, incident response, and abuse containment. The OAuth 2.0 Client Instance Assertion specification defines the general mechanism this profile builds on: a client instance proves its identity to the authorization server (AS) at the token endpoint, and the validated instance identity surfaces in the issued access token as act.sub (when the agent acts on a user's or another principal's behalf) or top-level sub (when the agent acts as itself), sender-constrained to a key the instance holds. This profile adds what agent deployments need beyond a bare instance identifier:

• A stable, attester-minted agent instance identifier (). The instance subject is an identifier the agent attester mints for the agent session rather than a key thumbprint, so it survives key rotation and names something an audit record can act on.
• Attested agent provenance (): optional claims conveying the agent platform, the model an agent instance runs, and evidence about its runtime environment, so resource servers can apply provenance-aware policy.
• A uniform agent classification: surfacing rules that mark agent actors with the ai_agent entity profile registered by , so resource servers can distinguish agent actors from other workload actors with a single signal ().
• Attested delegation chains (): when an agent spawns a sub-agent, each hop presents its own instance evidence, producing an act chain in which every actor was attested rather than merely asserted.

The claims defined here are carrier-independent (). Workload-style deployments convey them in a Client Instance Assertion per ; deployments using OAuth 2.0 Attestation-Based Client Authentication convey them in the Client Attestation. The claims, the subject derivation, and the access-token surfacing are identical in both cases. This profile does not define agent capability or tool-permission semantics; deployments expressing fine-grained agent permissions compose this profile with Rich Authorization Requests () or deployment-specific scope design.

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 when, and only when, they appear in all capitals, as shown here. This document uses the terms "Client Instance Assertion", "client instance", "instance issuer", and "OAuth client" as defined in , and "Client Attestation", "Client Attester", and "DPoP combined mode" as defined in .

Agent:

An autonomous or semi-autonomous software actor, typically driven by a machine-learning model, that performs tasks by calling APIs, optionally on behalf of a user or another principal.

Agent Platform:

The OAuth client under which agent instances run. The platform holds the client registration and operates the control plane that spawns, supervises, and terminates agent instances.

Agent Instance:

A client instance () that is an agent: a specific agent session, task execution, or runtime.

Agent Attester:

The authority that authenticates agent instances and mints the agent instance claims defined in . Depending on the carrier (), the Agent Attester is a instance issuer or an Client Attester. It is typically the agent platform's control plane, but MAY be a distinct party (see ).

Agent Instance Evidence:

The carrier artifact conveying the agent instance claims of to the AS: either a Client Instance Assertion, or a Client Attestation with its proof of possession.

Relationship to Other Specifications This profile depends normatively on for token-endpoint processing, sender-constraint binding, access-token representation, refresh-token semantics, and resource-server processing. It surfaces the ai_agent entity profile defined and registered by , profiling its use for attested agent instances. When the Client Attestation carrier is used, it depends on for attestation validation, including DPoP combined mode (). Delegation-chain construction follows the act semantics of as profiled by . Runtime-environment evidence is conveyed using the Entity Attestation Token () via the agent_runtime claim (); this profile does not define an evidence format of its own. Transaction Tokens () address propagation of immutable context across workloads within a trust domain after initial authorization; this profile addresses agent instance identity at initial token issuance. The two are complementary: a deployment may derive transaction tokens from access tokens issued under this profile, carrying the agent instance identity into the transaction context. Identity and authorization chaining () enables an authorization server in one domain to issue tokens redeemable in another, the pattern underlying enterprise cross-application access deployments in which an enterprise identity provider brokers agent access to third-party resources. That work moves identity across domains; it does not define agent claims. The two compose naturally: an authorization server applying this profile at issuance carries the agent instance identity and provenance into the chained tokens it brokers. authenticates a client instance at the token endpoint but defines no representation of it in issued tokens; the design rationale appendix records why this profile builds its representation layer on rather than over alone. Agent identity is an active topic in multiple communities. This profile deliberately limits itself to two things: conveying attested agent instance identity and provenance to the OAuth token endpoint, and representing that identity in issued access tokens. It does not define agent-to-agent authentication protocols, agent discovery, capability or tool description, or model governance, and is designed to compose with, rather than compete with, specifications that do. In particular, fine-grained permission description composes via Rich Authorization Requests (), and hardware-rooted runtime evidence composes via Entity Attestation Token formats ().

Agent Instance Claims The following claims are conveyed in the Agent Instance Evidence by the Agent Attester. Claim names are registered in the JSON Web Token Claims registry (). The claims are validated by the AS as part of carrier validation (); unknown members within object-valued claims MUST be ignored unless a profile of this document defines their processing.

agent_instance_id (REQUIRED):

A StringOrURI () identifying this agent instance, minted by the Agent Attester. The value MUST be unique among all instances attested by this Attester (across every OAuth client the Attester serves, so that resource servers evaluating the identifier need not qualify it by client_id) and MUST be stable for the lifetime of the agent instance. The value MUST NOT be derived from a proof-of-possession key: keys are binding material, not identity (). The Attester MUST NOT reassign an active or audit-relevant value to a different instance; see . Attesters SHOULD mint URI-shaped values within a namespace they control (for example, https://attester.example.com/instances/sess-9f2c), which makes the minting authority evident to consumers of the identifier.

agent_platform (OPTIONAL):

A StringOrURI identifying the agent platform or orchestration runtime under which the instance executes (for example, an identifier naming the orchestrator product and its major version). The value identifies software operated by the Agent Platform, not the OAuth client identity, which continues to be conveyed by client_id.

agent_model (OPTIONAL):

A JSON object characterizing the primary model configured for the agent instance, as determined by the Agent Attester at evidence issuance. The object contains an id member (REQUIRED, a StringOrURI model identifier) and MAY contain a version member (a string). The claim describes the instance's configuration, not each individual operation: an agent instance may route individual operations to other models (for example, routing, fallback, or auxiliary models) without invalidating the claim. A change to the primary configured model, however, means previously issued evidence no longer describes the instance, and the Attester MUST issue fresh evidence before the instance obtains further tokens under this profile (). A registry of model identifiers is out of scope; agent_model.id interoperability is an agreement between the Attester and the resource servers that consume it.

agent_runtime (OPTIONAL):

A JSON object conveying evidence about the runtime environment of the agent instance, such as confidential-computing or trusted-execution attestation results. This document defines one member: eat (OPTIONAL), containing an Entity Attestation Token (), carried as the JWT compact serialization when the EAT is in JWT form or base64url-encoded when in CWT form. The two forms are distinguishable by structure: a JWT compact serialization contains period separators, while a base64url-encoded CWT does not. Additional members MAY be defined by deployments or companion profiles; unknown members MUST be ignored. agent_runtime is consumed by the AS for policy and is not surfaced to resource servers by default ().

An AS that receives Agent Instance Evidence for a client registered for this profile () MUST reject evidence that omits agent_instance_id (). Evidence whose object-valued claims are malformed (for example, agent_model without an id member) MUST be rejected the same way.

Evidence Carriers The claims in are carried in exactly one of the following artifacts per token request. The claims, their validation, and all downstream processing are identical regardless of carrier.

Client Instance Assertion Carrier The Agent Attester acts as a instance issuer and includes the claims of in the Client Instance Assertion. All requirements for assertion format, presentation, and validation apply unchanged, including the (iss, jti) replay check and sender-constraint verification. The assertion's sub MUST equal the agent_instance_id value; the AS MUST reject an assertion where the two differ. The assertion's sub_profile SHOULD include the value ai_agent; regardless of what the evidence carries, surfacing follows . This carrier suits workload-style agent platforms that operate (or integrate with) an instance issuer, and inherits 's per-client trust delegation: the platform's client metadata lists the Agent Attester in instance_issuers, bounding which authority may attest its instances.

Client Attestation Carrier The Agent Attester acts as an Client Attester and includes the claims of in the Client Attestation JWT. The client authenticates per using DPoP combined mode; the DPoP key is the instance binding key for 's sender-constraint requirement, and the issued access token MUST be DPoP-bound to that key. Because the Client Attestation's sub names the OAuth client under , the instance subject on this carrier comes exclusively from the agent_instance_id claim. Applying this carrier changes the shape of the client's issued access tokens. Whether the AS applies it for a given client is established through the client's registered metadata () or by out-of-band agreement; an AS MUST NOT apply it to a client that has not agreed to receive instance representation in its tokens. This carrier is available on the grants covered by 's access-token classification (authorization_code, client_credentials, refresh_token, JWT bearer, and token-exchange); grants outside that classification are refused per . Because this carrier presents no request parameter, its activation (per the client's profile registration) substitutes for 's parameter-presence trigger: on token-exchange in particular, it applies even when no actor_token is present. The validation steps that depend on a presented assertion (token-type matching, descriptor lookup, signature verification, claim validation, client_id binding, and replay checking) are satisfied on this carrier by the completed validation together with the claim requirements of . Replay protection is provided by validation, including the DPoP proof freshness rules of ; 's (iss, jti) replay cache does not apply because no Client Instance Assertion is presented. Trust for this carrier is the AS-to-Attester trust of ; 's instance_issuers metadata is not consulted. For delegation cases on this carrier, the AS MUST set act.iss to the issuer identifier of the validated Client Attestation JWT. For self-acting cases, the Attester issuer is not represented as a standard access-token claim; the AS MUST retain it with token state for revocation, introspection, audit, and issuer-aware resource-server policy; in particular, per-instance revocation keyed on the issuer-and-subject pair per depends on it.

Carrier Precedence A token request that presents a Client Instance Assertion while also authenticating via uses the Client Instance Assertion as the Agent Instance Evidence: its claims are authoritative for instance identity and provenance. To ensure the two artifacts describe the same instance, the AS MUST verify that the assertion's cnf binding key and the DPoP key matched against the Client Attestation's cnf identify the same key material (for cnf.jkt, thumbprint equality); if they differ, the AS MUST reject the request with invalid_grant. If both artifacts carry agent_instance_id, the values MUST be equal; the AS MUST reject the request with invalid_grant otherwise.

Client and Authorization Server Metadata This document defines one client metadata parameter (registered per , applicable to any registration model supported by ) and one authorization server metadata parameter (registered per ):

ai_agent_instance_profile (client metadata):

OPTIONAL. Boolean, default false. When true, the client is registered for this profile. The AS MUST require Agent Instance Evidence on every token request from the client on the grants covered by 's access-token classification, except refresh_token requests, which follow ; a covered request presenting no evidence MUST be rejected (). Without this requirement, an instance could omit evidence and obtain tokens indistinguishable from an ordinary client's, silently escaping the attribution this profile provides. The client's registration or AS policy MAY exempt designated grant types whose requests are not made by agent instances (for example, client_credentials used by the platform's control plane); exempted requests are processed as ordinary OAuth requests and receive no instance representation. The AS MUST require agent_instance_id in the client's Agent Instance Evidence () and MUST apply the surfacing rules of ; when the Client Attestation carrier is used, this registration constitutes the client's agreement required by . Deployments without access to this parameter MAY establish the same registration by out-of-band agreement.

ai_agent_instance_profile_supported (AS metadata):

OPTIONAL. Boolean. Indicates that the AS supports this profile: validating agent instance claims, deriving the instance subject per , and surfacing per . An AS implementing this profile MUST include this parameter, set to true, in any authorization server metadata it publishes. Clients SHOULD verify it before depending on agent instance surfacing, since an AS without support may process the underlying carrier without applying this profile's representation.

Instance Subject Derivation The instance subject used for access-token surfacing is the agent_instance_id value, scoped to the Agent Attester that minted it. The AS MUST NOT derive the instance subject from a proof-of-possession key thumbprint: keys are binding material, not identity, and key rotation MUST NOT change the agent instance's identity. Consumers needing key-level correlation can use the access token's cnf confirmation claim directly. Because the subject is Attester-minted and key-independent:

• the identity is stable across DPoP or binding-key rotation within an instance's lifetime: access tokens obtained with a rotated key carry the same instance subject, so resource-server policy state and audit trails keyed on the subject survive rotation ( covers the refresh-token interaction);
• audit records name an identifier the Agent Attester can resolve to session context, rather than an opaque key fingerprint.

When a client lists multiple Agent Attesters, the subject-collision requirements of apply: the client MUST ensure the Attesters' agent_instance_id spaces do not collide. Attesters that follow the URI-shaped minting recommendation of satisfy this structurally, since each mints within a namespace it controls.

Access Token Surfacing Access-token representation follows : the instance subject appears as act.sub in delegation cases and as top-level sub in self-acting cases, and the issued access token is sender-constrained per . This profile additionally specifies:

• The surfaced sub_profile (top-level in self-acting cases, act.sub_profile in delegation cases) MUST include both the value ai_agent (defined by ) and the value client_instance (registered by ), per the list syntax of the underlying registry. Every agent instance is a client instance; including both values lets resource servers that implement but not this profile continue to classify the actor correctly. Other applicable registered values MAY additionally be included.
• The AS MAY surface agent_platform and agent_model subject to local policy and the privacy considerations of . Surfaced provenance claims appear within the act object in delegation cases (they describe the actor) and at top level in self-acting cases (the instance is the subject). An AS MUST NOT surface provenance claims that were not present in validated Agent Instance Evidence.
• agent_runtime evidence is consumed by the AS for policy and MUST NOT be surfaced to resource servers verbatim. Deployments that expose a runtime-assurance signal to resource servers SHOULD surface a coarse assurance tier () via a deployment-defined claim rather than raw evidence.

For opaque (reference) access tokens, the same surfaced claims appear in introspection responses, per 's introspection requirements.

Attested Delegation Chains When an agent instance spawns a sub-agent that requires its own access token, the sub-agent obtains it via token exchange () using 's token-exchange presentation, presenting its own Agent Instance Evidence (either carrier). The resulting act chain nests the spawning agent's actor entry per 's chain merging, and scope attenuation at each exchange follows . Whether a given instance is permitted to perform such an exchange is AS authorization policy under and ; this profile defines no separate spawn-permission mechanism. Because chain merging preserves the spawning agent's entry, spawning cannot be used to shed identity: a compromised instance that spawns sub-agents remains visible in every descendant chain. The property this profile targets: every actor entry the AS introduces into a chain corresponds to an instance that presented Agent Instance Evidence at the hop where it was introduced. An AS MUST NOT introduce an actor entry for an agent instance that did not present such evidence. Inner actor entries preserved verbatim from a subject_token were attested at the hop (and by the AS) that introduced them; the attested-at-every-hop property therefore spans exactly the hops processed under this profile. Chains that cross agent platforms or authorization servers (a sub-agent running on a different platform, under a different OAuth client, possibly at a different AS) compose through cross-domain token exchange and are governed by the trust and federation policy of the domains involved; this profile defines no additional cross-domain rules.

Refresh Tokens Refresh-token handling follows , with the derived instance subject, the Agent Attester, and any surfaced provenance claims recorded as originating instance state. Fresh Agent Instance Evidence presented on refresh MUST be issued by the same Agent Attester and carry the same agent_instance_id recorded at original issuance; the AS MUST reject a refresh presenting evidence from a different Attester or for a different instance with invalid_grant. A refresh processed without fresh evidence re-surfaces the provenance recorded at original issuance; see for the staleness this implies across refresh chains. Refresh tokens remain bound to the binding key present at their issuance, per ; this profile does not relax that binding. An instance that rotates its binding key (for example, after migrating between nodes) therefore cannot use a previously issued refresh token with the new key; it obtains new tokens through a fresh grant or token exchange, presenting fresh evidence that carries its unchanged agent_instance_id. The instance's identity, and everything resource servers key on it, is unaffected by the rotation ().

Trust Model and Assurance Tiers The strength of agent instance claims depends on who the Agent Attester is relative to the agent platform:

Platform self-attestation:

The Attester is the agent platform's own control plane. The claims reflect the platform's internal bookkeeping; assurance rests on organizational separation between the control plane and the agent runtime, comparable to a workload identity provider attesting its own workloads.

Hardware-rooted attestation:

The Attester incorporates evidence from a trusted-execution or confidential-computing environment (conveyed via agent_runtime, aligned with ). Claims about the runtime are rooted in hardware rather than platform assertion.

Independent attestation:

The Attester is a party distinct from the platform operator (for example, an enterprise attesting agent instances it runs on a third-party platform). Claims reflect a trust relationship independent of the platform.

Authorization servers and resource servers MAY condition policy on the tier. Deployments SHOULD document which tier their Attester provides and MUST NOT represent platform self-attestation as hardware-rooted or independent attestation.

Local and Public-Client Agent Instances Agent instances do not necessarily run on platform infrastructure: command-line and desktop agents execute on end-user machines, typically as public clients () using the authorization_code grant with PKCE () and without a client-level credential. This profile applies to such deployments with the following pattern:

• The local agent instance generates its per-instance proof-of-possession key locally and authenticates to the agent platform's control plane (how is out of scope; typically the user's platform login). The control plane, acting as the Agent Attester, mints Agent Instance Evidence whose cnf binds the key the local instance presented and whose agent_instance_id names the local session.
• The instance presents the evidence at the token endpoint per the Client Instance Assertion carrier () alongside its normal public-client interaction. Presenting a Client Instance Assertion does not require confidential-client authentication; only 's instance-assertion authentication method does, and public clients do not use that method.
• The issued access token is sender-constrained to the locally held key per , and the instance subject, surfacing, and chain semantics of this profile apply unchanged.

Attestation of a local session is platform self-attestation () with a narrower meaning: the Attester vouches that it issued the session to an authenticated platform account and bound the presented key, not for the integrity of the end-user host the instance runs on. Resource servers applying tier-conditioned policy SHOULD treat locally executing instances accordingly; deployments needing runtime-integrity claims for local instances can convey hardware-rooted evidence from the host via agent_runtime () where available.

Error Responses Errors are returned per Section 5.2, inheriting the error taxonomy of and, on the Client Attestation carrier, of . This profile adds the following invalid_grant cases (returned as invalid_client when, per , the evidence is the client authentication credential):

• a token request on a covered grant other than refresh_token presents no Agent Instance Evidence, and neither the client's registration nor AS policy exempts the grant type ();
• the Agent Instance Evidence omits agent_instance_id and the client is registered for this profile ();
• an object-valued agent claim is malformed ();
• on the Client Instance Assertion carrier, the assertion's sub does not equal agent_instance_id ();
• under carrier precedence, the binding keys or agent_instance_id values of the two artifacts do not match ();
• on refresh, presented evidence is issued by a different Agent Attester or carries a different agent_instance_id than recorded at original issuance ().

Conformance An AS conforms to this profile by supporting at least one evidence carrier (); requiring evidence from registered clients per ; validating the agent instance claims per ; deriving the instance subject per ; surfacing per , including the ai_agent and client_instance values in the surfaced sub_profile; applying the refresh rules of ; applying carrier precedence () when both artifacts are presented; and advertising support via ai_agent_instance_profile_supported (). An AS supporting the Client Instance Assertion carrier conforms to ; an AS supporting the Client Attestation carrier conforms to and to the activation-policy requirement of . An Agent Attester conforms by meeting the minting requirements of (in particular the uniqueness, stability, non-reassignment, and key-independence of agent_instance_id) and, per carrier, the obligations of a instance issuer or an Client Attester. An Agent Platform (OAuth client) conforms by registering for this profile () and for exactly the carriers it uses, listing its Agent Attester per where applicable, and ensuring the Attester is authorized to attest its instances. A resource server conforms by processing delegated and self-acting tokens per 's resource-server rules, treating actors whose sub_profile includes ai_agent as agent instances, and treating surfaced provenance claims subject to the assurance-tier considerations of and .

Security Considerations This document inherits the security considerations of and, when the Client Attestation carrier is used, and .

Attestation Freshness and Model Drift Agent Instance Evidence describes the instance as of evidence issuance. The claim most exposed to drift is agent_model: a platform that hot-swaps or upgrades the model serving a session invalidates previously issued evidence. requires fresh evidence after a model change, but the AS cannot detect a violation in-band; resource servers applying model-version policy are trusting the Attester's issuance discipline. On the Client Instance Assertion carrier, 's short assertion lifetimes bound the drift window. On the Client Attestation carrier, the window is bounded by the Client Attestation's lifetime, which some Attester ecosystems set to hours or days, plus DPoP proof freshness; the DPoP proof establishes recent possession of the bound key, not recent Attester endorsement. Deployments requiring current provenance SHOULD use short-lived evidence and SHOULD require fresh evidence on refresh rather than permitting refresh from stored originating instance state. Surfaced provenance is additionally static for the lifetime of each issued access token: a token surfacing agent_model remains valid after the platform upgrades the instance's primary model, until the token expires. Refresh processed from stored originating state () extends this window across the refresh-token lifetime. Resource servers gating sensitive operations on provenance SHOULD account for the access-token TTL in their policy assumptions, and ASes serving such resource servers SHOULD keep access-token lifetimes short relative to the deployment's model upgrade cadence.

Instance Identifier Lifecycle The value of agent_instance_id to audit and containment depends on the Attester honoring its minting obligations (). An Attester that reassigns an identifier to a different instance destroys audit attribution and can redirect per-instance policy (including revocation) at the resource server and AS. An Attester that mints one identifier for many instances (for example, a pool identifier) silently collapses per-agent containment back to the aggregate. These obligations are operational: the AS verifies the evidence signature and claims but cannot verify in-band that the Attester's minting practice is sound. Clients SHOULD list only Attesters whose practices they have audited, mirroring 's issuer-trust guidance.

Provenance Assurance agent_platform, agent_model, and agent_runtime are only as trustworthy as the Attester tier that produced them (). Under platform self-attestation, a model claim is the platform's statement about itself; resource servers MUST NOT treat it as independently verified. Policy that gates sensitive operations on provenance (for example, minimum model version) SHOULD take the assurance tier into account, and deployments needing verifiable runtime claims SHOULD use hardware-rooted attestation via agent_runtime and -aligned evidence.

Shared Trust Root on the Client Attestation Carrier On the Client Attestation carrier, the AS-to-Attester trust that authenticates the client also underpins the instance identity and provenance surfaced to resource servers. Compromise of the Attester's signing key therefore affects client authentication, instance identity, and provenance simultaneously. Operators SHOULD evaluate Attester key custody and rotation accordingly and ensure incident response covers access-token revocation for all three.

Carrier Trust Asymmetry The two carriers place control over the Attester set with different parties. On the Client Instance Assertion carrier, the client controls which authorities may attest its instances, by listing them in its instance_issuers metadata (); the AS accepts only Attesters the client has endorsed. On the Client Attestation carrier, Attester trust is AS-configured (); the client has no in-band mechanism to bound which Attesters the AS will accept for it, and a mistakenly-trusted or compromised Attester at the AS can mint agent identities under the client's client_id without any client-published endorsement being violated. The same claims therefore arrive under two different trust models depending on carrier. The registration-time agreement required by is the client's control point on the attestation carrier: clients SHOULD establish the acceptable Attester set as part of that agreement. Deployments in which the client requires in-band, auditable control over its attestation surface SHOULD use the Client Instance Assertion carrier.

Attester Trust from Client-Asserted Metadata In deployments where the client's metadata originates from the client itself rather than from a vetted registration process, the instance_issuers list and the ai_agent_instance_profile flag arrive from a party the AS has no prior relationship with. This is the case for unauthenticated dynamic registration () and equally for clients identified by a Client ID Metadata Document (), where the metadata document is authored and hosted by the client at a URL it controls; both occur when agent applications register with an authorization server discovered at run time. An unauthenticated registrant naming an Attester it controls gains nothing against other clients (the Attester attests only that client's instances), but the AS is nonetheless accepting a trust root and a token-shape obligation from an unvetted source. An AS accepting client-asserted metadata SHOULD NOT honor instance_issuers entries from such a source unless each listed Agent Attester is validated against AS policy, for example an AS-side allowlist of recognized platform Attesters, or, for dynamic registration, a signed software statement () from an authority the AS trusts. Software statements do not exist in the model; there, the allowlist applies unchanged, and the AS MAY additionally condition acceptance on the provenance of the client identifier itself, which is a URL the client demonstrably controls. The ai_agent_instance_profile flag in metadata listing no instance_issuers implicates the Client Attestation carrier, whose Attester trust is AS-configured (); honoring the flag there accepts a token-shape obligation but no new trust root. AS-operated allowlists of well-known agent platform Attesters are the expected deployment pattern for resource ecosystems serving dynamically registered or -identified agent clients.

Local Instance Keys and Evidence Minting For locally executing instances (), the instance binding key is held on an end-user machine rather than on platform infrastructure. A process that extracts the key and current evidence can act as the instance until they expire. Local instances SHOULD generate and hold binding keys in a platform keystore or hardware-backed key store where the host provides one, and Attesters SHOULD issue short-lived evidence to locally executing instances. The Attester's evidence-minting interface is part of the identity boundary: whoever can authenticate to it obtains evidence binding a key they control, so possession of a user's platform credentials suffices to mint agent instances attributed to that account. Attesters SHOULD bind evidence minting to the authenticated session through which the instance was established, SHOULD audit minting events with the same rigor as token issuance, and SHOULD rate-limit minting per account.

Privacy Agent provenance claims reveal implementation details (orchestrator, model identity and version, and indirectly the platform's upgrade cadence) to every resource server that receives them. Surfacing is therefore selective (): the AS surfaces only what local policy requires, and agent_runtime evidence is never surfaced verbatim. agent_instance_id is a per-instance identifier linkable across every request the instance makes for its lifetime. Platforms SHOULD scope instance lifetimes to the task or session they represent; long-lived instances accumulate long linkable histories at every resource server they touch. Where instances act on behalf of users, the identifier's granularity SHOULD NOT be chosen such that it becomes a stable pseudonym for the user across contexts the user would consider separate.

Scope of Protection Instance identity supports attribution, per-agent policy, and containment; it does not constrain what a compromised or prompt-injected agent does within the scope it was granted. An attested chain records which instance acted; it does not make the action safe. Least-privilege composition (scope design, authorization details, per-exchange attenuation as in ) remains the containment mechanism; this profile makes its enforcement and audit per-agent rather than per-platform. Similarly, the ai_agent classification is a policy-routing signal whose membership is determined by the Agent Attester; this profile defines no test for what constitutes an agent, and the boundary (autonomous agent versus script versus assistive tool) is inherently a judgment of the attesting party. Resource servers MUST NOT derive security guarantees from the classification itself, as distinct from the attested identity and provenance that accompany it.

IANA Considerations

JSON Web Token Claims Registration IANA is requested to register the following claims in the "JSON Web Token Claims" registry established by .

agent_instance_id

Claim Name:

agent_instance_id

Claim Description:

Attester-minted identifier of an AI agent instance

Change Controller:

IETF

Specification Document(s):

of this document

agent_platform

Claim Name:

agent_platform

Claim Description:

Identifier of the agent platform or orchestration runtime of an AI agent instance

Change Controller:

IETF

Specification Document(s):

of this document

agent_model

Claim Name:

agent_model

Claim Description:

Model identifier and version an AI agent instance is operating with

Change Controller:

IETF

Specification Document(s):

of this document

agent_runtime

Claim Name:

agent_runtime

Claim Description:

Runtime-environment evidence for an AI agent instance

Change Controller:

IETF

Specification Document(s):

of this document

OAuth Dynamic Client Registration Metadata IANA is requested to register the following parameter in the "OAuth Dynamic Client Registration Metadata" registry established by .

Client Metadata Name:

ai_agent_instance_profile

Client Metadata Description:

Boolean indicating that the client is registered for the OAuth 2.0 AI Agent Instance Profile

Change Controller:

IETF

Specification Document(s):

of this document

OAuth Authorization Server Metadata IANA is requested to register the following parameter in the "OAuth Authorization Server Metadata" registry established by .

Metadata Name:

ai_agent_instance_profile_supported

Metadata Description:

Boolean indicating authorization server support for the OAuth 2.0 AI Agent Instance Profile

Change Controller:

IETF

Specification Document(s):

of this document

OAuth Entity Profiles Registry This document requests no registration in the "OAuth Entity Profiles" registry: the ai_agent entity profile this document surfaces () is registered by as part of that registry's initial contents.

References Normative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] 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 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. 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 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. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. MATTR Bundesdruckerei SPRIND This specification defines an extension to the OAuth 2.0 protocol [RFC6749] 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. Independent This specification defines the Client Instance Assertion: a signed JWT identifying a concrete runtime instance of an OAuth 2.0 client. It registers the client_instance_assertion request parameter for carrying the assertion at the OAuth 2.0 token endpoint on the authorization_code, client_credentials, refresh_token, and JWT bearer (RFC 7523) grants; on the token-exchange grant (RFC 8693), the same assertion is presented as actor_token with actor_token_type set to urn:ietf:params:oauth:token-type:client-instance-jwt, also registered by this specification. This specification does not introduce a new client_instance identifier in protocol messages. Instead, it defines client metadata parameters (applicable to clients identified by a Client ID Metadata Document (CIMD) or registered via OAuth Dynamic Client Registration (RFC 7591)) that let a client_id identify a logical client whose concrete runtime instances are authenticated by one or more trusted instance issuers (for example, workload identity systems). The Authorization Server validates the instance assertion and represents the instance either as an act claim, when another principal is present (e.g., a user delegating to the instance), or as the access token's sub, when the instance itself is the principal (e.g., a client credentials grant). The issued access token is sender-constrained to a key the instance possesses. Microsoft Corporation Microsoft Corporation Independent This specification introduces Entity Profiles as a mechanism to categorize OAuth 2.0 entities—clients and subjects—based on their operational context. Entity Profiles provide structured descriptors for the client initiating the OAuth flow and the subject represented in tokens. This document defines new JWT Claim names and metadata parameters for use in JWTs issued or consumed in OAuth flows, including but not limited to access tokens, ID tokens, JWT authorization grant assertions, and transaction tokens, as well as in token introspection responses, dynamic client registration, and Authorization Server metadata. It also defines vocabulary for classifying acting entities within delegation chains. 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 OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. 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. 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. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. Anthropic

Design Rationale This appendix records design choices that motivated the normative text.

Why Attester-minted identifiers rather than key-derived subjects Deriving the instance subject from a proof-of-possession key thumbprint is superficially attractive, since it requires no minting infrastructure, but fails as identity. A key thumbprint carries no semantic content an audit record or policy can act on; key rotation silently mints a new actor, orphaning audit trails and resource-server policy state at exactly the moments (migration, key hygiene) rotation is routine; and key-level correlation is already available to every consumer via the access token's cnf confirmation claim, so a thumbprint-shaped subject adds no information. This profile therefore requires an Attester-minted, key-independent identifier and forbids key-derived subjects ().

Why carrier-pluggable The interoperable surface of this profile is the claims, the subject derivation, and the token surfacing, not the transport that conveys the claims to the AS. Workload-style agent platforms already operate instance issuers and fit 's assertion carrier; platforms in ecosystems deploying already present Client Attestations and should not need a second artifact carrying the same facts. Binding the agent claims to a single carrier would fragment the profile by deployment style without any interoperability gain.

Why the profile is not defined over Attestation-Based Client Authentication alone A natural question is why this profile does not depend solely on , a working-group document, and omit . Attestation-based client authentication authenticates a client instance at the token endpoint and deliberately stops there: it defines no representation of the instance in issued access tokens, no instance identifier (the attestation's sub is the client_id; the instance is identified only by its key, the key-as-identity model that rejects), no token-exchange or delegation-chain semantics, no introspection content, and no identity continuity across key rotation. Everything a resource server sees under this profile is machinery imported from on both carriers. Removing the dependency would not remove that machinery; it would relocate it into this document, coupling a general instance-representation layer to the AI-agent use case. The Client Instance Assertion carrier additionally serves deployments the attestation carrier structurally cannot: platforms that keep an existing client authentication method and add instance evidence rather than replacing their credential, clients requiring in-band control over their Attester set, SPIFFE-based workload reuse, mTLS sender constraint, and short-lived per-issuance evidence. answers whether a genuine instance of the client is authenticating; defines what the resource server sees afterward. This profile is a profile of the second question.

Why flat claims rather than one structured agent claim A single structured agent claim object was considered. Flat claims were chosen because individual JWT claim registrations are the established practice of the JWT Claims registry, selective surfacing () operates naturally per claim, and consumers can adopt agent_instance_id without parsing a container whose other members they ignore. The two object-valued claims (agent_model, agent_runtime) group members that are only meaningful together.

Why both sub and agent_instance_id on the assertion carrier On the Client Instance Assertion carrier the assertion's sub must equal agent_instance_id, which is deliberately redundant. Carrying the claim on both carriers gives implementations a single code path for subject derivation regardless of carrier, and the equality check on the assertion carrier is a cheap integrity cross-check. Making the claim optional where sub already carries the value was considered and rejected as an invitation to carrier-conditional bugs.

Why no standardized assurance-tier claim This document names three assurance tiers () but does not register a claim conveying them, directing deployments to a deployment-defined claim instead (). The tiers are policy vocabulary between an AS and its resource servers, not attested facts: which tier a given Attester provides is an operational judgment the AS makes when it configures trust, and a standardized claim would present that judgment with the same apparent authority as the attested claims it summarizes. Registering a tier claim before deployments demonstrate convergent semantics would freeze the wrong thing; one can be added by a later document without disturbing anything defined here.

Why generic agent_* claim names are registered now Agent identity claims are being invented independently across the industry. Registering agent_instance_id, agent_platform, agent_model, and agent_runtime early is intended to converge that activity on one vocabulary before divergence hardens, not to claim the namespace for this document; the semantics here are deliberately minimal so that other specifications can profile them. Coordination with related work in other bodies is invited, and the names are open to revision during working group review.

Why refresh tokens keep 's key binding Allowing a refresh token to be re-bound to a rotated key on presentation of fresh evidence was considered, since the Attester-minted identity makes "same instance, new key" provable. It was rejected for this version: it would relax a MUST and enlarge the refresh-token replay surface to the Attester trust boundary. Identity continuity across rotation is preserved without it, since new grants and exchanges under the unchanged agent_instance_id carry the same subject (), at the cost of one extra grant round-trip after a rotation.

Worked Example: Agent Calling an MCP Server Alice uses an AI assistant operated by an agent platform to triage issues in her project tracker. The tracker's API is fronted by a Model Context Protocol server () that acts as an OAuth resource server. The example uses the Client Instance Assertion carrier (); the Client Attestation carrier would convey the same claims with the flow otherwise unchanged. Deployment:

• User: alice@example.com
• OAuth client (agent platform): https://agents.example.com/assistant
• Agent Attester (the platform's control plane): https://attester.agents.example.com
• AS: https://as.example.com
• MCP resource server: https://mcp.example.org (fronting the project tracker)

The platform's registered client metadata lists its control plane as a trusted instance issuer per :

Delegation and Instance Spawn Alice authorizes the assistant through a standard authorization_code flow with PKCE (); her consent covers the client as a whole, per 's authorization-time consistency rules. To handle her request, the platform's control plane spawns agent instance sess-9f2c, provisions it a per-instance DPoP key, and, acting as the Agent Attester, mints a Client Instance Assertion carrying the claims of : Per , the assertion's sub equals agent_instance_id. The identifier names the session in the Attester's namespace; it is not derived from the DPoP key.

Token Issuance The instance redeems the authorization code, presenting the assertion and a DPoP proof signed with its instance key: grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &code_verifier=... &client_id=https%3A%2F%2Fagents.example.com%2Fassistant &client_assertion_type= urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer &client_assertion=eyJhbGciOiJFUzI1NiIs... &client_instance_assertion=eyJhbGciOiJFUzI1NiIs... ]]> The AS validates per , classifies the request as delegation, and issues a DPoP-bound access token. Local policy surfaces agent_model (but not agent_platform) per :

Resource Server Processing The MCP server validates the JWT and the accompanying DPoP proof, then applies agent-aware policy that is impossible when it sees only client_id:

• act.sub_profile containing ai_agent routes the request through the server's agent policy tier (for example, requiring human-in-the-loop confirmation for destructive tools).
• Local policy requires agent_model.version of at least 7 for issues.write; a token surfacing an older attested model would be limited to read-only tools. (The attested model characterizes the instance's primary configuration at evidence issuance, not each individual operation, and is static for the token lifetime; see and for the limits of such policy.)
• Rate limits and anomaly detection are keyed on (client_id, act.sub): one runaway session is throttled without affecting the platform's other agents.
• The audit record attributes the action end to end: "alice@example.com via agent instance sess-9f2c (model atlas 7.3) updated issue 4711."

If sess-9f2c misbehaves, the MCP server reports act.sub; the platform terminates the session, and the AS applies per-instance revocation keyed on (act.iss, act.sub) per , containing one agent without revoking the platform's client registration.

Sub-Agent Spawn (Attested Chain) The agent delegates a subtask (summarizing a long issue thread) to a specialized sub-agent. The platform spawns instance sess-a114 running a smaller model, with its own DPoP key and its own assertion (agent_instance_id .../instances/sess-a114, agent_model {"id": "urn:example:model:scout", "version": "2.0"}). The sub-agent exchanges the parent's access token per 's token-exchange presentation, presenting its assertion as actor_token. The resulting token nests the chain: The chain reads outward-in: sub-agent sess-a114 (scout 2.0) acting for agent sess-9f2c (atlas 7.3), acting for Alice. Every actor entry corresponds to an instance that presented Attester evidence at its hop (); scope was attenuated to projects.read at the exchange.

Key Rotation Mid-session, the platform migrates sess-9f2c to another node and rotates its DPoP key. The Attester mints a fresh assertion with the same agent_instance_id and the new cnf.jkt. Access tokens obtained with the new key carry the same act.sub: the MCP server's per-agent rate-limit state, policy decisions, and audit trail continue uninterrupted. Had the subject been derived from the key thumbprint, the rotation would have silently minted a new actor identity, orphaning the audit trail. (Refresh tokens remain bound to the key present at their issuance per and ; the migrated instance obtains new tokens through a fresh grant or exchange under its unchanged identity.)

Document History RFC EDITOR: please remove this section before publication.

-00

• Initial version.

Acknowledgments The author thanks participants in the OAuth Working Group for discussions on client instance identity and agent identity that informed this document.