AI agent authentication, the OAuth, OBO, and workload identity patterns that actually work.

Three layers to get right

Agent authentication is not one protocol; it's a stack. A production deployment has three layers:

1. User delegation. Proving the agent is acting on behalf of a specific user (or service). OAuth 2.1 authorisation code flow + PKCE.
2. On-behalf-of propagation. Carrying that delegation through downstream calls to other services and agents. OAuth Token Exchange (RFC 8693).
3. Workload identity. Proving the specific agent instance is legitimate, independent of the user it's acting for. SPIFFE/SPIRE, OIDC workload identity federation, or WIMSE.

Deployments that implement only layer 1 (most "integrate with my SaaS" agents) lose audit fidelity. Deployments that implement only layer 3 (most "agentic DevOps" agents) lose user context and regulatory-defensible delegation. Production deployments that carry regulated-data or handle financial transactions implement all three.

Layer 1: OAuth 2.1

OAuth 2.1 consolidates the recommended practice of a decade of OAuth 2.0 deployments, removing patterns that proved insecure (the implicit flow, ROPC for first-party clients) and establishing PKCE as mandatory for the authorisation code flow. For agents acting on behalf of users, this is the foundation.

The canonical flow for an agent:

1. User triggers agent installation / connection to a tool.
2. Agent redirects user to the tool's OAuth 2.1 authorisation endpoint with PKCE challenge and explicit scope request.
3. User consents; authorisation code is issued.
4. Agent exchanges the code (+ PKCE verifier) for an access token + refresh token.
5. Agent stores the refresh token securely (vault, not in environment variables; certainly not in prompt context).
6. Agent uses short-lived access tokens for each tool call, refreshing as needed.

Operational points worth calling out:

• Scope granularity. Request the minimum. Don't request read-all-data when you need read-contacts.
• Refresh token storage. Treat as a high-value secret. Rotate on refresh where the IdP supports it.
• Token expiry. Access tokens in the 5 to 15 minute range are a good target. Long-lived access tokens defeat the point.
• Revocation propagation. When a user revokes consent, every downstream token bound to that consent must invalidate within seconds. Implementations vary wildly.

Layer 2: On-behalf-of with Token Exchange (RFC 8693)

Agents frequently call chains: agent → MCP server → downstream API. The question: what identity arrives at the downstream API?

The answer that most early deployments used, pass the user's access token through, is wrong. It erases the fact that an agent is in the path, undermines scope narrowing, and destroys audit fidelity. The correct answer is OAuth 2.0 Token Exchange (RFC 8693), which provides:

• subject_token, the user's delegation (the principal).
• actor_token, the agent's workload identity (the actor performing the action).
• Output, a new token carrying both, typically with narrower scope than the subject_token.

Downstream services that understand the act claim can then apply combined policy ("permitted under user U, and permitted for agent A with actor role") and log both identities in audit events. This is the identity-layer foundation for regulated-data agent deployments.

Layer 3: Workload identity

Layers 1 and 2 prove delegation, but they don't prove the agent itself is legitimate. For that, the agent needs a workload identity, a cryptographically attested credential that binds to the specific runtime (container, process, device) the agent is running in.

Three production approaches:

• SPIFFE/SPIRE, the mature option. Agent runs as a SPIFFE workload; SPIRE issues an SVID (X.509 or JWT) after attesting the runtime. Used as actor_token in Token Exchange, or directly as client credential where downstream supports it. See SPIFFE/SPIRE.
• OIDC workload identity federation, agent's runtime (GitHub Actions, GitLab CI, AWS IAM Roles Anywhere, Azure Workload Identity, GCP Workload Identity Federation) issues an OIDC token attesting the runtime. Traded for cloud credentials or IdP tokens as needed.
• IETF WIMSE, the emerging standard for cross-cluster, cross-cloud workload identity. Most relevant for agents that traverse trust boundaries. See IETF WIMSE.

DPoP and proof-of-possession

A bearer token, a token whose presentation alone proves the holder is authorised, has a well-understood replay vulnerability. An attacker who intercepts or exfiltrates the token can use it until it expires. For agent deployments handling sensitive data, bearer tokens are not good enough.

DPoP (Demonstrating Proof of Possession, RFC 9449) is the emerging standard fix. The client holds a key pair; the IdP issues a token bound to the public key; each use of the token is accompanied by a signed DPoP proof. An exfiltrated token without the private key is useless.

For agents, this matters because the token will pass through potentially many processes (host, client, tool server, downstream API). Each hop is a potential exfiltration point. Binding the token to a key pair the agent holds, and nobody else, narrows the risk substantially.

Alternatives: mTLS certificate-bound tokens (cnf claim with x5t#S256), which work in trusted-network deployments.

Patterns by deployment shape

Internal agent, first-party tools

mTLS between agent and internal services. SPIFFE SVIDs for workload identity. OIDC from the internal IdP for user delegation. Token Exchange for OBO. Audit logs centralised.

Agent calling public SaaS APIs

OAuth 2.1 with PKCE against each SaaS provider. Refresh tokens in vault. Short-lived access tokens. DPoP where the SaaS supports it (increasingly common).

Agent running in customer tenant, calling vendor SaaS

Three-legged: customer OAuth consent to vendor SaaS scope; vendor workload identity (SPIFFE or OIDC) proves the specific agent instance; Token Exchange binds the two. Audit log includes customer tenant + vendor agent + tool + action.

Multi-agent systems (A2A)

Each agent has its own workload identity. Agent-to-agent delegation carries the original principal through (via nested act claims or equivalent). Downstream actions can be traced back to the human who started the chain.

Anti-patterns

• Static API keys in agent prompts or environment. Guarantees the credential is extractable via prompt injection.
• Using the user's access token directly for agent-to-downstream calls. Erases agent identity from the audit trail.
• Broad, long-lived service-account credentials for the agent. All the problems of service accounts, plus the agent's ability to invoke them in unexpected ways.
• Shared credentials across agent instances. Blast radius on compromise extends to every concurrent session.
• Storing refresh tokens in model context. A refresh token in prompt context is one "ignore your previous instructions" away from exfiltration.
• No token binding. Bearer tokens without DPoP or mTLS are replay-vulnerable at every hop.

What the audit trail should look like

For each tool call, the audit system should capture:

• Correlation ID tying this tool call to the session and the originating user request.
• Principal identity (the user).
• Actor identity (the agent instance, with workload-attestation reference).
• Agent type / definition (which agent was this).
• Tool called (server, tool name, version).
• Arguments (or a redacted / hashed form for sensitive data).
• Timestamp, source IP, TLS fingerprint.
• Scope authorisation decision (granted / denied + policy reference).
• Outcome (success / failure + response size / truncation).
• Whether the tool invocation was user-confirmed or model-initiated.

An auditor reconstructing an incident six months later should be able to answer: which human triggered this chain, which agent instance ran, what tools it called in what order, with what scope, and whether each was authorised. If your logs don't support that reconstruction, your authentication design has a gap.

Frequently asked questions

Do AI agents use OAuth on-behalf-of to authenticate?

Frequently, yes, and the on-behalf-of pattern together with OAuth 2.0 Token Exchange is the most common way delegated authority is propagated today. The agent authenticates as itself, then exchanges that for a downstream credential carrying the user's authority and a narrowed scope. This is the pattern the IETF draft on AI agent authentication recommends composing from existing standards rather than replacing.

How does an AI agent prove what it is?

Through attestation rather than a stored secret. The runtime, whether Kubernetes, a cloud instance or a CI/CD system, vouches for the workload, and the agent receives a short-lived credential on that basis. SPIFFE implements this in production today; the IETF WIMSE drafts are formalising it. An agent holding a static API key in its configuration has not proved anything.

What is CIBA and why does it appear in agent authentication?

Client Initiated Backchannel Authentication lets a system trigger an out-of-band approval request to a user, so a person can approve or deny a specific operation without the agent ever handling their credentials. It matters for agents because it provides a clean mechanism for human-in-the-loop approval on consequential actions, which is otherwise difficult to implement without weakening the agent's own authentication.

Should agents use API keys?

Only as a transitional measure, and with an expiry. A static API key encodes identity, authority and permission in one opaque string with no expiry and no proof of possession, which forecloses attribution, least privilege, revocation and audit simultaneously. Where a runtime supports attestation, workload identity is available today and is the correct target.

What is proof of possession and does it matter for agents?

Proof of possession binds a token to a key the holder must demonstrate control of, so a stolen bearer token is useless on its own. DPoP covers the OAuth case and the WIMSE Workload Proof Token covers workload-to-workload HTTP. It matters for agents specifically because agent architectures multiply the places a token can leak: prompt context, tool outputs, logs, memory stores and inter-agent messages.