Standard OAuth assumes a user or a service — not an agent acting on someone’s behalf. Here is how OAuth for AI agents actually works in 2026: token exchange, audience binding, and the new on-behalf-of draft.
What is OAuth for AI agents?
OAuth for AI agents is the set of patterns and extensions that let an agent obtain a scoped, short-lived access token to act on a user’s behalf — while carrying its own identity, so every action is attributable to both the user and the agent. It matters because classic OAuth was built for two actors: a user, and an app the user trusts. An agent is a third actor that acts semi-autonomously, and that breaks the original assumptions.
The goal of OAuth for AI agents is a token that answers three questions at once: who authorized this (the user), who is acting (the specific agent), and what exactly may it do (one resource, minimal scope, for a short time). Get those three right and you have delegation you can audit; get them wrong and you have a confused deputy with a master key.
OAuth for AI agents = delegated, on-behalf-of authorization. The agent presents the user’s grant plus its own identity, and receives a token scoped to one resource and a minimal set of permissions — with the full delegation chain recorded in the token’s claims.
Why standard OAuth wasn’t built for agents
Standard OAuth breaks for agents because it models only two roles — the user and a single client app — with no first-class way to represent ‘an agent acting for a user.’ Teams hit three failures fast.
The shared-service-token trap: giving the agent one broad machine token means every action looks like the same robot, attributable to no specific user — an audit and security dead end. The confused deputy: an over-scoped token lets a manipulated agent do far more than the user intended. No delegation chain: when the agent calls a downstream API, the original token’s context is lost, so the resource server can’t tell who really authorized the request. OAuth for AI agents exists to close exactly these gaps.
“An agent with one broad service token isn’t authorized — it’s unsupervised.”
The case for per-user delegation
The building blocks: token exchange, resource indicators, and on-behalf-of
OAuth for AI agents is assembled from three standards, two of them already stable.
Token exchange (RFC 8693) is the core move: the agent trades the user’s delegated token plus its own actor_token for a new, narrower token, and the result carries an act claim naming the agent. Resource Indicators (RFC 8707) bind that token to exactly one audience — one API — so a stolen token can’t be replayed elsewhere. The new on-behalf-of draft (draft-oauth-ai-agents-on-behalf-of-user, revision 02) adds a requested_actor parameter to the authorization request and an actor_token to the token request, producing a token that documents the full delegation chain from user to agent. It is not yet a ratified standard, but it points clearly where the protocol layer is heading.
The code below shows the token exchange in practice — the single most important request to understand in OAuth for AI agents.
# RFC 8693 token exchange: an agent acts ON BEHALF OF a user, with its OWN identity.
POST /oauth/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<USER_DELEGATED_TOKEN> # the user's grant being delegated
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=<AGENT_CREDENTIAL_JWT> # WHO is acting — the agent's own identity
&actor_token_type=urn:ietf:params:oauth:token-type:jwt
&resource=https://api.example.com/calendar # RFC 8707 audience binding (one resource)
&scope=calendar.events.read # least privilege — read, not write
# The returned access token carries an `act` claim documenting the delegation chain:
# { "sub": "user-123", "act": { "sub": "agent-scheduler-7" }, "aud": ".../calendar",
# "scope": "calendar.events.read", "exp": <short> }
# The resource server now knows: user-123 authorized agent-scheduler-7 to read this calendar only.How to implement OAuth for AI agents, step by step
Implement delegation in five steps, each enforcing least privilege. Expand each for the detail.
1. Get a per-user grant, not a service token
Have each user authorize the agent individually (per-user OAuth), so the agent holds a delegated grant tied to that specific person. Never substitute a shared service account for user-facing actions — you lose attribution and least privilege at once.
2. Give the agent its own verifiable identity
The agent needs a credential that proves which agent is acting — a signed JWT or a workload identity (SPIFFE). This becomes the actor_token in the exchange and the act claim in the result.
3. Exchange for a narrow, audience-bound token (RFC 8693 + 8707)
At each call, exchange the user’s grant + the agent’s identity for a fresh token scoped to one resource (resource=, RFC 8707) and the minimal scope. Don’t pass the original broad token downstream.
4. Keep tokens short-lived and re-exchange per hop
Short expiry limits blast radius. When the agent calls a second service, exchange again for a token bound to that audience — chaining delegation instead of widening it.
5. Log and verify the delegation chain
Resource servers should read the act claim and enforce policy on it. The chain (user → agent → optional sub-agent) is your audit trail and your kill switch.
OAuth for AI agents in the wider stack: SPIFFE, OPA, and MCP
OAuth handles delegation, but it sits beside two other layers in a 2026 agent security stack. The CNCF’s service-to-service recommendation pairs SPIFFE for workload identity (who is the agent, cryptographically), OAuth 2.0 for access delegation (what may it do for this user), and OPA for policy (should it, given context). Identity, delegation, policy — three jobs, three tools.
This is also why the Model Context Protocol (MCP) authorization spec requires OAuth 2.1 plus RFC 8707 audience binding: when an agent calls MCP tools, each token must be pinned to the specific server it is for, so a token minted for one tool can’t be replayed against another. If you build on MCP, you are already doing OAuth for AI agents whether you call it that or not.
Avoid: shared service tokens for user actions, over-broad scopes, long-lived tokens, passing one token across audiences, and skipping the act-claim audit. Each one turns a helpful agent into a confused deputy.
Builder’s take
On Cyntr, the moment agents started touching real user data, OAuth for AI agents stopped being a checkbox and became the whole ballgame. The trap everyone falls into first is handing the agent one fat service token and hoping scopes save them. They don’t. The agent has to carry the user’s delegated grant AND its own identity, scoped to one resource, short-lived.
- Never give an agent a shared service token for user actions — use per-user delegation so every call is attributable to a specific user AND a specific agent.
- Bind every token to one audience (RFC 8707) and the narrowest scope that works; a token good for ‘everything’ is a confused-deputy waiting to happen.
- Keep tokens short-lived and exchange (RFC 8693) for a fresh, narrower token at each downstream hop rather than passing the original around.
- Log the delegation chain — the `act` claim is your audit trail when someone asks ‘why did the agent do that?’
Frequently asked questions
It is delegated, on-behalf-of authorization for agents: the agent presents the user’s grant plus its own identity and receives a short-lived token scoped to one resource and minimal permissions, with the delegation chain recorded in the token’s claims. It exists because standard OAuth only models a user and a single app, not an agent acting for a user.
Because a normal token represents either a user or a service, with no way to say ‘this agent is acting for this user.’ That leads to shared service tokens (no attribution), over-broad scopes (confused deputy), and a lost delegation chain downstream. The agent-specific patterns fix all three.
Token exchange lets the agent trade the user’s delegated token plus its own actor token for a new, narrower token. The result carries an `act` claim naming the agent, so every downstream call is attributable to both the user and the specific agent — the core mechanic of OAuth for AI agents.
No, not for user-facing actions. Use per-user delegation so each call is tied to a specific user and a specific agent. Shared service accounts destroy attribution and least privilege and are a common security failure.
The Model Context Protocol authorization spec requires OAuth 2.1 plus RFC 8707 resource indicators, so each token is bound to the specific MCP server it targets. Building agents on MCP means implementing OAuth for AI agents by default.
Not fully. Token exchange (RFC 8693) and Resource Indicators (RFC 8707) are stable RFCs, and the on-behalf-of agent draft (draft-oauth-ai-agents-on-behalf-of-user) is at revision 02 but not yet working-group adopted. The building blocks are standard; the agent-specific glue is still maturing.
Primary sources
- OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents (draft-02) — IETF
- RFC 8693 — OAuth 2.0 Token Exchange — IETF
- RFC 8707 — Resource Indicators for OAuth 2.0 — IETF
- Per-User OAuth for AI Agents: why it matters — Composio
- Agent identity and delegated authorization: OAuth patterns — Tian Pan
Last updated: May 30, 2026. Related: Identity Provenance.
