OAuth for AI Agents: Scopes, Token Exchange and Per-Action Authorization

Picture an agent that must read a customer's invoices. Handing it the customer's password would be reckless, and a shared master key is little better. OAuth was designed for this handoff and offers three useful ideas: scopes limit a token's reach, delegation records whose behalf the agent acts on, and short lifetimes limit what a theft yields. Real agent setups often adopt one idea and skip the rest.

The patterns below fit agents. Sources are RFC 8693 for token exchange, RFC 9700 for current security practice, the MCP authorization specification as a worked example, and the OWASP Non-Human Identities list for risk framing. Our own advice is labelled, and this is no security audit.

What every agent token should state

Four facts belong in or behind each token. The agent's identity, meaning its own client and never a shared one. The principal, which may be a user, a team or nobody. The permission: scopes, resources and limits. The lifespan: an expiry and a revocation route. A token that carries only the permission fact cannot be audited afterwards. For the identity background, see why an agent is neither a user nor a service.

Agents on their own: client credentials

An agent that compiles a report overnight acts for nobody, so it signs in as itself. In OAuth terms this is the client credentials grant, with a separate client for each agent and scopes trimmed to its single task. This avoids borrowing a person's identity and keeps the trail readable. The soft spot is the client secret, which lasts for ages. Where possible replace it with short-lived signed assertions, a subject covered in the workload identity article.

Two grants should be left out altogether. The OAuth security best current practice, RFC 9700, published in January 2025, states that the resource owner password credentials grant must not be used and that clients should not use the implicit grant (RFC 9700). Agents have no reason to touch either.

Working for a person: authorization code with PKCE

If the agent serves a specific person, that person approves access in a consent screen. The MCP authorization specification is built this way: the client takes the OAuth 2.1 client role, the server acts as resource server, and the user grants permission. Clients are expected to use PKCE and to send a resource parameter, defined in RFC 8707, tying the token to its intended server. Servers, per the specification, must verify that tokens were minted for them as audience (MCP authorization specification).

The same discipline helps for every API that agents call. RFC 9700 asks that access tokens be restricted to a particular resource server and that each resource server confirm, on every request, that the token was meant for it, refusing otherwise (RFC 9700). What happens when servers skip that check is shown in the confused deputy article.

Across hops: exchange the token, name the actor

Say agent A asks service B to act for a user. B should never receive the token A originally held. RFC 8693 describes token exchange through a security token service, in two flavours. Delegation lets the issued token include an act claim that names whoever is acting, so subject and actor both show up. Impersonation makes the actor indistinguishable from the subject (RFC 8693). For agents the right flavour is delegation: logs keep the chain, and a resource server can hold the agent to tighter limits than the user.

Shaping scopes for agents

Name each scope after one operation, for instance reading tickets, and not after a whole product. Begin with a small set and raise it through challenges when a task truly needs more; the MCP specification advises a minimal first scope with incremental elevation, each step logged (MCP authorization specification). Skip wildcards and omnibus scopes, which the same document counts among common mistakes. And keep reading apart from writing: an agent that consumes untrusted content has little business holding a write scope in the same session.

Expiry, theft and revocation

A short-lived access token is worth less to a thief. RFC 9700 adds that refresh tokens for public clients must be sender-constrained or rotated, and that sender-constrained access tokens, via DPoP or mutual TLS, resist replay (RFC 9700). Tokens do leave laptops, as the infostealer article documents. Limit access token lifetimes to minutes or hours, guard refresh tokens like secrets, and keep the ability to revoke by agent, by user and by scope.

Frequent mistakes, one line each

• Sharing one client across agents. The logs blur and a leak reaches every agent. Give each agent and environment its own client.
• Handing the user's token downstream. Audience binding and audit both break. Exchange it and attach an actor claim.
• Wide scopes granted early. One stolen token opens everything. Start narrow and step up.
• Refresh tokens in config files. They are a favourite target. Use the OS credential store, short lives and rotation.
• No revocation path that anyone has tried. Rehearse revoking one agent.

OWASP's Non-Human Identities Top 10 lists overprivileged NHI (NHI5), long-lived secrets (NHI7) and NHI reuse (NHI9), which line up with several items above (OWASP NHI Top 10). The choice of credential type underneath is compared in API keys, OAuth and workload identity.

Scopes cannot describe one action

A scope names a class of access, such as write access to payments. What an agent really needs is narrower still: this transfer, to this account, up to this amount. A scope cannot say that, so a payments token will serve any payment a steered agent attempts, which is exactly the harm prompt injection aims for.

OAuth already has a standard for finer permissions. RFC 9396, Rich Authorization Requests, defines an authorization_details parameter for carrying fine-grained authorization data in OAuth messages (RFC 9396). My view is that high-impact agent actions should be authorised per action with that kind of structured detail, and that scopes should only set the outer fence.

I would drop this advice if your authorization server does not support rich authorization requests, as support is uneven and the specification does not make it a requirement for MCP. In that case combine narrow per-job scopes with a policy checkpoint and an approval step that shows the specific action, which achieves the same limit by other means. The advice also costs engineering effort, so apply it first to the few actions that move money, change access or delete data.

An eight-question review

Ask of each agent: does it own a client named for its owner and purpose? Are redirect URIs exact matches? Do access tokens expire within hours, with refresh tokens in a store or broker? Do the scopes fit one job without wildcards? Does every resource server check audience and issuer? Is delegation recorded with an actor claim wherever a user is involved? Can every grant be listed and revoked in a single step? Do logs tie client, user, scope and result together? Start with whichever of questions one, four or seven earned a no.

Open points

• Framework support for token exchange is uneven, so check your SDK.
• Standard claims for agent actors may emerge from NIST's work; see the initiative article.
• We tested no specific authorization server.

OAuth for agents, answered