Web Authorization Protocol K. McGuinness Internet-Draft Independent Intended status: Standards Track 4 July 2026 Expires: 5 January 2027 OAuth 2.0 AI Agent Instance Profile draft-mcguinness-oauth-ai-agent-instance-00 Abstract 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 This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/draft-mcguinness-oauth-client-instance- assertion/draft-mcguinness-oauth-ai-agent-instance.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcguinness-oauth-ai-agent- instance/. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/draft-mcguinness-oauth-client-instance- assertion. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. McGuinness Expires 5 January 2027 [Page 1] Internet-Draft oauth-ai-agent-instance July 2026 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 5 January 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Relationship to Other Specifications . . . . . . . . . . . . 6 4. Agent Instance Claims . . . . . . . . . . . . . . . . . . . . 7 5. Evidence Carriers . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Client Instance Assertion Carrier . . . . . . . . . . . . 8 5.2. Client Attestation Carrier . . . . . . . . . . . . . . . 9 5.3. Carrier Precedence . . . . . . . . . . . . . . . . . . . 10 6. Client and Authorization Server Metadata . . . . . . . . . . 10 7. Instance Subject Derivation . . . . . . . . . . . . . . . . . 11 8. Access Token Surfacing . . . . . . . . . . . . . . . . . . . 12 9. Attested Delegation Chains . . . . . . . . . . . . . . . . . 13 10. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . . . 13 11. Trust Model and Assurance Tiers . . . . . . . . . . . . . . . 14 12. Local and Public-Client Agent Instances . . . . . . . . . . . 14 13. Error Responses . . . . . . . . . . . . . . . . . . . . . . . 15 14. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 16 15. Security Considerations . . . . . . . . . . . . . . . . . . . 16 15.1. Attestation Freshness and Model Drift . . . . . . . . . 16 15.2. Instance Identifier Lifecycle . . . . . . . . . . . . . 17 McGuinness Expires 5 January 2027 [Page 2] Internet-Draft oauth-ai-agent-instance July 2026 15.3. Provenance Assurance . . . . . . . . . . . . . . . . . . 17 15.4. Shared Trust Root on the Client Attestation Carrier . . 18 15.5. Carrier Trust Asymmetry . . . . . . . . . . . . . . . . 18 15.6. Attester Trust from Client-Asserted Metadata . . . . . . 18 15.7. Local Instance Keys and Evidence Minting . . . . . . . . 19 15.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 19 15.9. Scope of Protection . . . . . . . . . . . . . . . . . . 20 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 16.1. JSON Web Token Claims Registration . . . . . . . . . . . 20 16.1.1. agent_instance_id . . . . . . . . . . . . . . . . . 20 16.1.2. agent_platform . . . . . . . . . . . . . . . . . . . 20 16.1.3. agent_model . . . . . . . . . . . . . . . . . . . . 21 16.1.4. agent_runtime . . . . . . . . . . . . . . . . . . . 21 16.2. OAuth Dynamic Client Registration Metadata . . . . . . . 21 16.3. OAuth Authorization Server Metadata . . . . . . . . . . 21 16.4. OAuth Entity Profiles Registry . . . . . . . . . . . . . 22 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 17.1. Normative References . . . . . . . . . . . . . . . . . . 22 17.2. Informative References . . . . . . . . . . . . . . . . . 23 Design Rationale . . . . . . . . . . . . . . . . . . . . . . . . 24 Why Attester-minted identifiers rather than key-derived subjects . . . . . . . . . . . . . . . . . . . . . . . . . 24 Why carrier-pluggable . . . . . . . . . . . . . . . . . . . . . 25 Why the profile is not defined over Attestation-Based Client Authentication alone . . . . . . . . . . . . . . . . . . . 25 Why flat claims rather than one structured agent claim . . . . 25 Why both sub and agent_instance_id on the assertion carrier . . 26 Why no standardized assurance-tier claim . . . . . . . . . . . 26 Why generic agent_* claim names are registered now . . . . . . 26 Why refresh tokens keep CIA-CORE's key binding . . . . . . . . 26 Worked Example: Agent Calling an MCP Server . . . . . . . . . . . 27 Delegation and Instance Spawn . . . . . . . . . . . . . . . . . 28 Token Issuance . . . . . . . . . . . . . . . . . . . . . . . . 28 Resource Server Processing . . . . . . . . . . . . . . . . . . 29 Sub-Agent Spawn (Attested Chain) . . . . . . . . . . . . . . . 30 Key Rotation . . . . . . . . . . . . . . . . . . . . . . . . . 31 Document History . . . . . . . . . . . . . . . . . . . . . . . . 31 -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 McGuinness Expires 5 January 2027 [Page 3] Internet-Draft oauth-ai-agent-instance July 2026 1. 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 ([MCP]), 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 [CIA-CORE] 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* (Section 4). 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* (Section 4): 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 [ENTITY-PROFILES], so resource servers can distinguish agent actors from other workload actors with a single signal (Section 8). * *Attested delegation chains* (Section 9): 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. McGuinness Expires 5 January 2027 [Page 4] Internet-Draft oauth-ai-agent-instance July 2026 The claims defined here are carrier-independent (Section 5). Workload-style deployments convey them in a Client Instance Assertion per [CIA-CORE]; deployments using OAuth 2.0 Attestation-Based Client Authentication [ATTEST-CLIENT-AUTH] 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 ([RFC9396]) or deployment-specific scope design. 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. This document uses the terms "Client Instance Assertion", "client instance", "instance issuer", and "OAuth client" as defined in [CIA-CORE], and "Client Attestation", "Client Attester", and "DPoP combined mode" as defined in [ATTEST-CLIENT-AUTH]. 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 ([CIA-CORE]) 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 Section 4. Depending on the carrier (Section 5), the Agent Attester is a [CIA-CORE] instance issuer or an [ATTEST-CLIENT-AUTH] Client Attester. It is typically the agent platform's control plane, but MAY be a distinct party (see Section 11). Agent Instance Evidence: The carrier artifact conveying the agent instance claims of Section 4 to the AS: either a Client Instance Assertion, or a Client Attestation with its proof of possession. McGuinness Expires 5 January 2027 [Page 5] Internet-Draft oauth-ai-agent-instance July 2026 3. Relationship to Other Specifications This profile depends normatively on [CIA-CORE] 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 [ENTITY-PROFILES], profiling its use for attested agent instances. When the Client Attestation carrier is used, it depends on [ATTEST-CLIENT-AUTH] for attestation validation, including DPoP combined mode ([RFC9449]). Delegation-chain construction follows the act semantics of [RFC8693] as profiled by [CIA-CORE]. Runtime-environment evidence is conveyed using the Entity Attestation Token ([RFC9711]) via the agent_runtime claim (Section 4); this profile does not define an evidence format of its own. Transaction Tokens ([TXN-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 ([ID-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. [ATTEST-CLIENT-AUTH] 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 [CIA-CORE] rather than over [ATTEST-CLIENT-AUTH] 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 McGuinness Expires 5 January 2027 [Page 6] Internet-Draft oauth-ai-agent-instance July 2026 to compose with, rather than compete with, specifications that do. In particular, fine-grained permission description composes via Rich Authorization Requests ([RFC9396]), and hardware-rooted runtime evidence composes via Entity Attestation Token formats ([RFC9711]). 4. 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 (Section 16.1). The claims are validated by the AS as part of carrier validation (Section 5); unknown members within object-valued claims MUST be ignored unless a profile of this document defines their processing. agent_instance_id (REQUIRED): A StringOrURI ([RFC7519]) 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 (Section 7). The Attester MUST NOT reassign an active or audit-relevant value to a different instance; see Section 15.2. 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 McGuinness Expires 5 January 2027 [Page 7] Internet-Draft oauth-ai-agent-instance July 2026 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 (Section 15.1). 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 ([RFC9711]), 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 (Section 8). An AS that receives Agent Instance Evidence for a client registered for this profile (Section 6) MUST reject evidence that omits agent_instance_id (Section 13). Evidence whose object-valued claims are malformed (for example, agent_model without an id member) MUST be rejected the same way. 5. Evidence Carriers The claims in Section 4 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. 5.1. Client Instance Assertion Carrier The Agent Attester acts as a [CIA-CORE] instance issuer and includes the claims of Section 4 in the Client Instance Assertion. All [CIA-CORE] requirements for assertion format, presentation, and validation apply unchanged, including the (iss, jti) replay check and sender-constraint verification. McGuinness Expires 5 January 2027 [Page 8] Internet-Draft oauth-ai-agent-instance July 2026 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 Section 8. This carrier suits workload-style agent platforms that operate (or integrate with) an instance issuer, and inherits [CIA-CORE]'s per- client trust delegation: the platform's client metadata lists the Agent Attester in instance_issuers, bounding which authority may attest its instances. 5.2. Client Attestation Carrier The Agent Attester acts as an [ATTEST-CLIENT-AUTH] Client Attester and includes the claims of Section 4 in the Client Attestation JWT. The client authenticates per [ATTEST-CLIENT-AUTH] using DPoP combined mode; the DPoP key is the instance binding key for [CIA-CORE]'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 [ATTEST-CLIENT-AUTH], 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 (Section 6) 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 [CIA-CORE]'s access-token classification (authorization_code, client_credentials, refresh_token, JWT bearer, and token-exchange); grants outside that classification are refused per [CIA-CORE]. Because this carrier presents no request parameter, its activation (per the client's profile registration) substitutes for [CIA-CORE]'s parameter-presence trigger: on token-exchange in particular, it applies even when no actor_token is present. McGuinness Expires 5 January 2027 [Page 9] Internet-Draft oauth-ai-agent-instance July 2026 The [CIA-CORE] 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 [ATTEST-CLIENT-AUTH] validation together with the claim requirements of Section 4. Replay protection is provided by [ATTEST-CLIENT-AUTH] validation, including the DPoP proof freshness rules of [RFC9449]; [CIA-CORE]'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 [ATTEST-CLIENT-AUTH]; [CIA-CORE]'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 [CIA-CORE] depends on it. 5.3. Carrier Precedence A token request that presents a Client Instance Assertion while also authenticating via [ATTEST-CLIENT-AUTH] 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. 6. Client and Authorization Server Metadata This document defines one client metadata parameter (registered per [RFC7591], applicable to any registration model supported by [CIA-CORE]) and one authorization server metadata parameter (registered per [RFC8414]): 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 [CIA-CORE]'s access-token classification, except refresh_token requests, which follow Section 10; a covered request presenting no evidence MUST be rejected (Section 13). Without this requirement, McGuinness Expires 5 January 2027 [Page 10] Internet-Draft oauth-ai-agent-instance July 2026 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 (Section 4) and MUST apply the surfacing rules of Section 8; when the Client Attestation carrier is used, this registration constitutes the client's agreement required by Section 5.2. 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 Section 7, and surfacing per Section 8. 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. 7. 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 (Section 10 covers the refresh-token interaction); * audit records name an identifier the Agent Attester can resolve to session context, rather than an opaque key fingerprint. McGuinness Expires 5 January 2027 [Page 11] Internet-Draft oauth-ai-agent-instance July 2026 When a client lists multiple Agent Attesters, the subject-collision requirements of [CIA-CORE] apply: the client MUST ensure the Attesters' agent_instance_id spaces do not collide. Attesters that follow the URI-shaped minting recommendation of Section 4 satisfy this structurally, since each mints within a namespace it controls. 8. Access Token Surfacing Access-token representation follows [CIA-CORE]: 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 [CIA-CORE]. 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 [ENTITY-PROFILES]) and the value client_instance (registered by [CIA-CORE]), per the list syntax of the underlying registry. Every agent instance is a client instance; including both values lets resource servers that implement [CIA-CORE] 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 Section 15.8. 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 (Section 11) via a deployment- defined claim rather than raw evidence. For opaque (reference) access tokens, the same surfaced claims appear in introspection responses, per [CIA-CORE]'s introspection requirements. McGuinness Expires 5 January 2027 [Page 12] Internet-Draft oauth-ai-agent-instance July 2026 9. 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 ([RFC8693]) using [CIA-CORE]'s token-exchange presentation, presenting its own Agent Instance Evidence (either carrier). The resulting act chain nests the spawning agent's actor entry per [CIA-CORE]'s chain merging, and scope attenuation at each exchange follows [RFC8693]. Whether a given instance is permitted to perform such an exchange is AS authorization policy under [RFC8693] and [CIA-CORE]; 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. 10. Refresh Tokens Refresh-token handling follows [CIA-CORE], 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 Section 15.1 for the staleness this implies across refresh chains. Refresh tokens remain bound to the binding key present at their issuance, per [CIA-CORE]; this profile does not relax that binding. An instance that rotates its binding key (for example, after McGuinness Expires 5 January 2027 [Page 13] Internet-Draft oauth-ai-agent-instance July 2026 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 (Section 7). 11. 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 [RFC9711]). 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. 12. 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 ([RFC6749]) using the authorization_code grant with PKCE ([RFC7636]) 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. McGuinness Expires 5 January 2027 [Page 14] Internet-Draft oauth-ai-agent-instance July 2026 * The instance presents the evidence at the token endpoint per the Client Instance Assertion carrier (Section 5.1) alongside its normal public-client interaction. Presenting a Client Instance Assertion does not require confidential-client authentication; only [CIA-CORE]'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 [CIA-CORE], and the instance subject, surfacing, and chain semantics of this profile apply unchanged. Attestation of a local session is platform self-attestation (Section 11) 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 (Section 4) where available. 13. Error Responses Errors are returned per [RFC6749] Section 5.2, inheriting the error taxonomy of [CIA-CORE] and, on the Client Attestation carrier, of [ATTEST-CLIENT-AUTH]. This profile adds the following invalid_grant cases (returned as invalid_client when, per [CIA-CORE], 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 (Section 6); * the Agent Instance Evidence omits agent_instance_id and the client is registered for this profile (Section 6); * an object-valued agent claim is malformed (Section 4); * on the Client Instance Assertion carrier, the assertion's sub does not equal agent_instance_id (Section 5.1); * under carrier precedence, the binding keys or agent_instance_id values of the two artifacts do not match (Section 5.3); * on refresh, presented evidence is issued by a different Agent Attester or carries a different agent_instance_id than recorded at original issuance (Section 10). McGuinness Expires 5 January 2027 [Page 15] Internet-Draft oauth-ai-agent-instance July 2026 14. Conformance An AS conforms to this profile by supporting at least one evidence carrier (Section 5); requiring evidence from registered clients per Section 6; validating the agent instance claims per Section 4; deriving the instance subject per Section 7; surfacing per Section 8, including the ai_agent and client_instance values in the surfaced sub_profile; applying the refresh rules of Section 10; applying carrier precedence (Section 5.3) when both artifacts are presented; and advertising support via ai_agent_instance_profile_supported (Section 6). An AS supporting the Client Instance Assertion carrier conforms to [CIA-CORE]; an AS supporting the Client Attestation carrier conforms to [ATTEST-CLIENT-AUTH] and to the activation-policy requirement of Section 5.2. An Agent Attester conforms by meeting the minting requirements of Section 4 (in particular the uniqueness, stability, non-reassignment, and key-independence of agent_instance_id) and, per carrier, the obligations of a [CIA-CORE] instance issuer or an [ATTEST-CLIENT-AUTH] Client Attester. An Agent Platform (OAuth client) conforms by registering for this profile (Section 6) and for exactly the carriers it uses, listing its Agent Attester per Section 5.1 where applicable, and ensuring the Attester is authorized to attest its instances. A resource server conforms by processing delegated and self-acting tokens per [CIA-CORE]'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 Section 11 and Section 15.3. 15. Security Considerations This document inherits the security considerations of [CIA-CORE] and, when the Client Attestation carrier is used, [ATTEST-CLIENT-AUTH] and [RFC9449]. 15.1. 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. Section 4 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. McGuinness Expires 5 January 2027 [Page 16] Internet-Draft oauth-ai-agent-instance July 2026 On the Client Instance Assertion carrier, [CIA-CORE]'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 (Section 10) 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. 15.2. Instance Identifier Lifecycle The value of agent_instance_id to audit and containment depends on the Attester honoring its minting obligations (Section 4). 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 [CIA-CORE]'s issuer-trust guidance. 15.3. Provenance Assurance agent_platform, agent_model, and agent_runtime are only as trustworthy as the Attester tier that produced them (Section 11). 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 [RFC9711]-aligned evidence. McGuinness Expires 5 January 2027 [Page 17] Internet-Draft oauth-ai-agent-instance July 2026 15.4. 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. 15.5. 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 (Section 5.1); the AS accepts only Attesters the client has endorsed. On the Client Attestation carrier, Attester trust is AS-configured (Section 5.2); 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 Section 5.2 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. 15.6. 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 ([RFC7591]) and equally for clients identified by a Client ID Metadata Document ([CIMD]), 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. McGuinness Expires 5 January 2027 [Page 18] Internet-Draft oauth-ai-agent-instance July 2026 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 ([RFC7591]) from an authority the AS trusts. Software statements do not exist in the [CIMD] 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 (Section 5.2); 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 [CIMD]-identified agent clients. 15.7. Local Instance Keys and Evidence Minting For locally executing instances (Section 12), 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. 15.8. 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 (Section 8): 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 McGuinness Expires 5 January 2027 [Page 19] Internet-Draft oauth-ai-agent-instance July 2026 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. 15.9. 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, [RFC9396] authorization details, per-exchange attenuation as in Section 9) 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. 16. IANA Considerations 16.1. JSON Web Token Claims Registration IANA is requested to register the following claims in the "JSON Web Token Claims" registry established by [RFC7519]. 16.1.1. agent_instance_id Claim Name: agent_instance_id Claim Description: Attester-minted identifier of an AI agent instance Change Controller: IETF Specification Document(s): Section 4 of this document 16.1.2. agent_platform Claim Name: agent_platform Claim Description: Identifier of the agent platform or orchestration McGuinness Expires 5 January 2027 [Page 20] Internet-Draft oauth-ai-agent-instance July 2026 runtime of an AI agent instance Change Controller: IETF Specification Document(s): Section 4 of this document 16.1.3. 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): Section 4 of this document 16.1.4. agent_runtime Claim Name: agent_runtime Claim Description: Runtime-environment evidence for an AI agent instance Change Controller: IETF Specification Document(s): Section 4 of this document 16.2. OAuth Dynamic Client Registration Metadata IANA is requested to register the following parameter in the "OAuth Dynamic Client Registration Metadata" registry established by [RFC7591]. 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): Section 6 of this document 16.3. OAuth Authorization Server Metadata IANA is requested to register the following parameter in the "OAuth Authorization Server Metadata" registry established by [RFC8414]. McGuinness Expires 5 January 2027 [Page 21] Internet-Draft oauth-ai-agent-instance July 2026 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): Section 6 of this document 16.4. OAuth Entity Profiles Registry This document requests no registration in the "OAuth Entity Profiles" registry: the ai_agent entity profile this document surfaces (Section 8) is registered by [ENTITY-PROFILES] as part of that registry's initial contents. 17. References 17.1. Normative References [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . McGuinness Expires 5 January 2027 [Page 22] Internet-Draft oauth-ai-agent-instance July 2026 [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [ATTEST-CLIENT-AUTH] Looker, T., Bastian, P., and C. Bormann, "OAuth 2.0 Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-attestation- based-client-auth-09, 25 May 2026, . [CIA-CORE] McGuinness, K., "OAuth 2.0 Client Instance Assertion", Work in Progress, Internet-Draft, draft-mcguinness-oauth- client-instance-assertion-01, 24 June 2026, . [ENTITY-PROFILES] Mora, S. C., Dingle, P., and K. McGuinness, "OAuth 2.0 Entity Profiles", Work in Progress, Internet-Draft, draft- mora-oauth-entity-profiles-01, 15 April 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 17.2. Informative References [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . McGuinness Expires 5 January 2027 [Page 23] Internet-Draft oauth-ai-agent-instance July 2026 [CIMD] Parecki, A. and E. Smith, "OAuth Client ID Metadata Document", Work in Progress, Internet-Draft, draft-ietf- oauth-client-id-metadata-document-01, 1 March 2026, . [TXN-TOKENS] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-08, 2 March 2026, . [ID-CHAINING] Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-16, 26 June 2026, . [MCP] Anthropic, "Model Context Protocol Specification", 2025, . 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 (Section 7). McGuinness Expires 5 January 2027 [Page 24] Internet-Draft oauth-ai-agent-instance July 2026 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 [CIA-CORE]'s assertion carrier; platforms in ecosystems deploying [ATTEST-CLIENT-AUTH] 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 [ATTEST-CLIENT-AUTH], a working-group document, and omit [CIA-CORE]. 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 Section 7 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 [CIA-CORE] on both carriers. Removing the [CIA-CORE] 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. [ATTEST-CLIENT-AUTH] answers whether a genuine instance of the client is authenticating; [CIA-CORE] 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 (Section 8) 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. McGuinness Expires 5 January 2027 [Page 25] Internet-Draft oauth-ai-agent-instance July 2026 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 (Section 11) but does not register a claim conveying them, directing deployments to a deployment-defined claim instead (Section 8). 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 [CIA-CORE]'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 [CIA-CORE] 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 (Section 10), at the cost of one extra grant round-trip after a rotation. McGuinness Expires 5 January 2027 [Page 26] Internet-Draft oauth-ai-agent-instance July 2026 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 ([MCP]) that acts as an OAuth resource server. The example uses the Client Instance Assertion carrier (Section 5.1); 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 [CIA-CORE]: { "client_id": "https://agents.example.com/assistant", "jwks_uri": "https://agents.example.com/assistant/jwks.json", "token_endpoint_auth_method": "private_key_jwt", "ai_agent_instance_profile": true, "instance_issuers": [ { "issuer": "https://attester.agents.example.com", "jwks_uri": "https://attester.agents.example.com/jwks.json", "subject_syntax": "uri" } ] } McGuinness Expires 5 January 2027 [Page 27] Internet-Draft oauth-ai-agent-instance July 2026 Delegation and Instance Spawn Alice authorizes the assistant through a standard authorization_code flow with PKCE ([RFC7636]); her consent covers the client as a whole, per [CIA-CORE]'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 Section 4: { "iss": "https://attester.agents.example.com", "sub": "https://attester.agents.example.com/instances/sess-9f2c", "aud": "https://as.example.com", "client_id": "https://agents.example.com/assistant", "sub_profile": "ai_agent", "agent_instance_id": "https://attester.agents.example.com/instances/sess-9f2c", "agent_platform": "urn:example:orchestrator:v5", "agent_model": { "id": "urn:example:model:atlas", "version": "7.3" }, "iat": 1770000000, "exp": 1770000300, "jti": "ag-1a2b3c", "cnf": { "jkt": "0ZcOCORZNYy...iguA4I" } } Per Section 5.1, 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: McGuinness Expires 5 January 2027 [Page 28] Internet-Draft oauth-ai-agent-instance July 2026 POST /token HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded DPoP: 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 [CIA-CORE], classifies the request as delegation, and issues a DPoP-bound access token. Local policy surfaces agent_model (but not agent_platform) per Section 8: { "iss": "https://as.example.com", "aud": "https://mcp.example.org", "sub": "alice@example.com", "client_id": "https://agents.example.com/assistant", "scope": "projects.read issues.write", "iat": 1770000005, "exp": 1770001805, "cnf": { "jkt": "0ZcOCORZNYy...iguA4I" }, "act": { "iss": "https://attester.agents.example.com", "sub": "https://attester.agents.example.com/instances/sess-9f2c", "sub_profile": "ai_agent client_instance", "agent_model": { "id": "urn:example:model:atlas", "version": "7.3" }, "cnf": { "jkt": "0ZcOCORZNYy...iguA4I" } } } 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). McGuinness Expires 5 January 2027 [Page 29] Internet-Draft oauth-ai-agent-instance July 2026 * 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 Section 4 and Section 15.1 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 [CIA-CORE], 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 [CIA-CORE]'s token-exchange presentation, presenting its assertion as actor_token. The resulting token nests the chain: McGuinness Expires 5 January 2027 [Page 30] Internet-Draft oauth-ai-agent-instance July 2026 { "iss": "https://as.example.com", "aud": "https://mcp.example.org", "sub": "alice@example.com", "client_id": "https://agents.example.com/assistant", "scope": "projects.read", "cnf": { "jkt": "QrS...XyZ" }, "act": { "iss": "https://attester.agents.example.com", "sub": "https://attester.agents.example.com/instances/sess-a114", "sub_profile": "ai_agent client_instance", "agent_model": { "id": "urn:example:model:scout", "version": "2.0" }, "cnf": { "jkt": "QrS...XyZ" }, "act": { "iss": "https://attester.agents.example.com", "sub": "https://attester.agents.example.com/instances/sess-9f2c", "sub_profile": "ai_agent client_instance" } } } 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 (Section 9); 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 [CIA-CORE] and Section 10; 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._ McGuinness Expires 5 January 2027 [Page 31] Internet-Draft oauth-ai-agent-instance July 2026 -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. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com McGuinness Expires 5 January 2027 [Page 32]