This field-guide entry has not been reviewed in its new form yet. The studies are summarized as published; no review date is implied.
Key findings #
When several people share an agent that holds a robot account, the agent acts with the combined permissions of all its users, and nobody can tell whose request was whose.
Under the delegation semantics of OAuth 2.0 Token Exchange, the acting party keeps its own identity, separate from the person whose rights it uses.
The OAuth 2.0 security best current practice says an access token’s privileges should be restricted to the minimum the use case requires, and the token should be audience-restricted to a specific resource server.
Coding agents should not hold persistent identity and access management (IAM) roles or long-lived API keys; an identity broker can issue short-lived, task-scoped credentials on demand instead.
Evidence #
| Study | Year | Sample | Method | Finding |
|---|---|---|---|---|
| OAuth 2.0 Token Exchange (RFC 8693)IETF | 2020 | n/a | Specification | Defines delegation and impersonation semantics and the act claim that names the acting party. |
| Best Current Practice for OAuth 2.0 Security (RFC 9700)IETF | 2025 | n/a | Specification | Asks for least-privilege, audience-restricted tokens and warns when resource servers can’t tell client tokens from user tokens. |
| Model Context Protocol: Authorization (revision 2026-07-28)Model Context Protocol | 2026 | n/a | Specification | Treats clients acting for a user differently from clients acting on their own behalf. |
| What I Learned Building an Identity Broker With Coding Agentsthis site | 2026 | n/a | Field report | Explains why the Agentic Identity Broker keeps both the user and the agent in every authorization decision. |
| AppSec in the Age of Agentic Engineeringthis site | 2026 | n/a | Essay | Argues for short-lived, task-scoped credentials and user-revocable delegation for agents. |
What to do #
For engineers #
Ask first whom the agent acts for. If it runs a job on its own behalf, a dedicated client with its own narrow permissions is a reasonable fit. The MCP authorization specification explicitly mentions such client_credentials clients. If it acts for a person, use a grant that names that person and that agent, and keep it narrow and short-lived as RFC 9700 asks.
Prefer delegation over impersonation. A delegated token can carry the agent as the actor next to the person as the subject, so a resource server and your logs can tell them apart. RFC 9700 also warns that a resource server that can’t distinguish tokens obtained with a person’s involvement from tokens a client obtained on its own may let that client reach the person’s resources.
Keep provider credentials out of the agent’s context. Token exchange shows how a gateway can do this on each tool call.
For product and UX #
Show people which agent holds access to which service, with what permissions and until when. Give them one place to revoke that access. If several people use the same agent, show each of them only the grants they made.
How it works #
With a robot account, the agent holds a long-lived credential for each MCP server or API it calls. In OAuth terms, that is closest to a client that gets tokens for itself, without a person in the flow. RFC 9700 quotes the JSON Web Token (JWT) profile for access tokens (RFC 9068): the sub claim of such a token should identify the client application, while a token obtained with a person’s involvement should identify that person. A robot account therefore can’t express who asked for an action. In my retrospective, I describe the consequences once several people share the agent: combined permissions, no attribution, and credentials within reach of anything that tricks the agent.
RFC 8693 describes 2 ways one party can use another’s rights. With impersonation, party A gets B’s rights and is indistinguishable from B in that context. With delegation, A keeps its own identity, and it’s explicitly understood that A acts for B. The RFC uses this exact phrase: “In a sense, A is an agent for B.” A token that carries both identities is a composite token. In a JWT, the act claim names the acting party.
The Agentic Identity Broker that Magnus Jungsbluth and I built applies delegation. A user grants an agent access to a service with a chosen permission set and an optional expiry and can revoke the grant at any time. The broker keeps both the user and the agent in every authorization decision. The essay and our AGNTCon + MCPCon talk explain the design, and the project page links the code.
This model covers agents that act for a person. For autonomous agents with no human in the loop, I wrote in the retrospective that every approach I know of is still brittle.