OAuth 2.1 and DPoP for AI Agents: Design the Whole Token Lifecycle

An AI agent should not carry one broad bearer token from login through every tool call. The safer pattern separates the user’s durable grant from the short-lived credentials used by each agent instance and downstream service.

As of September 21, 2026, OAuth 2.1 is still an Internet-Draft—not a final RFC. The current draft consolidates OAuth security guidance and removes insecure features, while the stable baseline is OAuth 2.0 plus the OAuth Security Best Current Practice, RFC 9700 (OAuth 2.1 draft; RFC 9700). Build against the stable RFCs and track the draft rather than marketing an implementation as certified “OAuth 2.1 compliant.”

The lifecycle to implement

1. Establish the user grant

For an agent acting for a person, use the authorization-code flow with PKCE. The authorization server—not the model, tool or agent runtime—authenticates the user and records approval. RFC 9700 requires PKCE for public clients, recommends it for confidential clients and says the password grant must not be used (RFC 9700).

Make the approval legible at the action level. “Manage email” is usually too broad; separate reading messages, creating drafts and sending messages. OAuth supplies the protocol machinery, but your product must define scopes and approval policy that correspond to real consequences.

2. Keep the durable credential out of the agent loop

Store any refresh token in a credential broker or trusted orchestrator, not in the prompt, model context, browser storage, tool arguments or workflow transcript. The agent should receive only a short-lived access token for the next bounded operation.

For public clients, current OAuth security guidance requires refresh tokens to use sender constraint or rotation. It also recommends restricting an access token to a particular resource server and the minimum resources and actions needed (RFC 9700). Apply the same conservative posture to confidential agent services even where the normative requirement differs.

3. Bind issued tokens to an agent-held key with DPoP

DPoP turns a token from “whoever possesses this string may use it” into a token that also requires proof of the corresponding private key. The authorization server binds the token to the public key; on each API call, the agent signs a fresh DPoP proof containing the HTTP method, target URI, issue time, unique identifier and access-token hash (RFC 9449).

Generate a separate, non-exportable key where practical for each agent runtime or security boundary. Do not share one DPoP private key across a fleet: that converts a contained compromise into a fleet-wide credential problem. Resource servers must verify both the access token and its DPoP binding on every request.

DPoP is defense in depth, not a sandbox. It does not authenticate the client by itself, replace HTTPS or stop malicious code already running in the agent’s process from using the key (RFC 9449).

4. Downscope at every delegation boundary

When a planner delegates to a tool runner or a service calls a downstream API, do not forward the original token. Use OAuth Token Exchange to request a new token for the downstream resource, with narrower scope and no longer a lifetime than its parent. RFC 8693 supports exchanging a token for one appropriate to a backend service and provides the act claim for representing a delegation chain (RFC 8693).

Attenuation is an authorization-server policy, not an automatic property of token exchange. Enforce these invariants yourself:

• child scope is a subset of parent scope;
• child audience names one downstream resource;
• child expiry does not exceed parent expiry;
• delegation depth and allowed tool classes are bounded;
• the new token is bound to the receiving workload’s key, not the sender’s key.

RFC 8693 also warns that an exchange does not inherently create a live linkage between input and output tokens, including automatic revocation propagation. Maintain a grant-family or delegation graph if incident response requires cascading invalidation (RFC 8693).

5. Validate at the resource, not only at the gateway

For JWT access tokens, validate explicit token type, issuer, audience, signature and expiry, then enforce the scopes required for the requested action. RFC 9068 requires an expected audience and says a resource server must reject a token not meant for it (RFC 9068). With DPoP, also validate the proof signature, key thumbprint binding, method, URI, freshness, unique jti and ath token hash.

Publish protected-resource metadata so clients can discover the authorization servers, supported scopes and whether DPoP-bound access tokens are required. RFC 9728 defines dpop_signing_alg_values_supported and dpop_bound_access_tokens_required for this purpose (RFC 9728).

6. Rotate, expire and revoke as one system

Use refresh-token rotation or sender constraint, detect reuse, and revoke the affected grant family when replay is confirmed. Design refresh calls for concurrency: serialize refreshes per grant or provide a narrowly bounded recovery mechanism so parallel agent workers do not look like attackers.

Support refresh-token revocation and expose a user-visible way to disconnect an agent. RFC 7009 requires support for revoking refresh tokens and notes that short-lived access tokens limit the period during which a revoked grant can still be used where immediate access-token revocation is unavailable (RFC 7009). Choose access-token lifetime from the impact of the action and your revocation latency; there is no universal “agent token” duration.

A practical control plane

A defensible architecture has four separations:

1. Authorization server: authenticates the principal, records grants, issues and revokes tokens.
2. Credential broker: holds refresh tokens and performs controlled refresh or token exchange.
3. Agent runtime: holds its DPoP private key and receives only task-bounded access tokens.
4. Resource server: independently verifies token, audience, scope and proof before executing a tool action.

Log grant ID, token ID, principal, client, actor chain, audience, scope, DPoP key thumbprint, policy decision and outcome—but never token values or private keys. This gives a technical team something more useful than an “OAuth supported” checkbox: a lifecycle whose authority can be narrowed, traced and terminated.