When an AI agent or service calls an API for a user, give it a delegated token that names both the user and the agent, not a token that makes it indistinguishable from the user. OAuth token exchange, RFC 8693, defines both options and the claims that record who is acting.
The problem with agents using user tokens
Passing a user's access token down to an agent or tool is easy. It also means the downstream API sees only the user. You lose the record that an automated actor made the call, you cannot limit the agent separately, and a leak of that token exposes everything the user can do.
What token exchange does
The client posts to the token endpoint with grant_type set to urn:ietf:params:oauth:grant-type:token-exchange. It sends:
subject_token: required, identifies the party on whose behalf the request is made, withsubject_token_typeactor_token: optional, identifies the party that will act, withactor_token_typeaudienceorresource: where the new token will be used
The authorization server, acting as a security token service, returns a new token.
Impersonation vs delegation
Impersonation. The actor receives the subject's rights and is indistinguishable from the subject in the granted context. A request with only a subject_token has impersonation semantics.
Delegation. The actor keeps its own identity and acts as an agent for the subject. It needs an actor_token, and the result is usually a composite token that names both.
For agents, delegation is the better default because audit logs and policy can see the agent.
The act and may_act claims
The act claim names the current actor. Nested act claims record earlier actors in a chain, for example user to agent to tool. The RFC says access control decisions should consider only the top level claims and the current actor. Earlier actors are informational.
The may_act claim states that one party is authorized to act for another. The authorization server can check it when deciding whether to allow the exchange.
Narrow the audience
The resource parameter is an absolute URI without a fragment. The audience parameter is a logical name unique within that authorization server. Both can repeat. If the server cannot issue a token for the target, it should return invalid_target. Asking for one specific audience per downstream call keeps a leaked token from working elsewhere.
Design checklist for agent calls
- Use delegation, with the agent's own identity as the actor.
- Request the narrowest scope and one audience per call.
- Keep exchanged tokens short lived.
- Log both subject and actor for every call.
- Restrict which agents may act for which users with
may_actor server policy. - Do not forward the original user token to tools.
Where Safeguard fits
Safeguard includes agent identity and an MCP Guardrail for controlling what agents can reach. They address the same question this post covers: knowing which agent did what. See Safeguard's MCP Guardrail and agent identity.
Quick check
Is delegation always possible?
It needs support from your authorization server and an actor token. If your server cannot issue composite tokens, record the agent identity in your own audit log as a fallback.
Does the act claim limit what the agent can do?
No. It records who is acting. Limits come from scope, audience and server policy.
Sources
Last reviewed: 19 October 2026.
