--- author: Jan Brennenstuhl canonical_url: https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/delegation-vs-robot-accounts/ description: Why an agent that acts for people needs delegated access tied to each person, and when a robot account still fits. id: jb-guide-delegation-vs-robot-accounts kind: guide license: name: CC BY 4.0 scope: Original text; credited third-party media retain their own rights. url: https://creativecommons.org/licenses/by/4.0/ markdown_url: https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/delegation-vs-robot-accounts/index.md modified: '2026-10-13T00:00:00+02:00' published: '2026-10-13T00:00:00+02:00' review_basis: '' review_status: not-reviewed reviewed: '' series: '' status: published title: Should an agent use a robot account or delegated access? topics: - agentic-engineering - identity-authentication --- # Should an agent use a robot account or delegated access? **Short answer:** When an agent acts for a person, give it delegated access that names both the person and the agent, with narrow scopes, an expiry, and a way to revoke it. A robot account shared by several people gives the agent their combined permissions and hides whose request was whose. ## Key findings > **Finding f-agent-robot-account-combined-permissions:** 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. > > Source: [What I Learned Building an Identity Broker With Coding Agents (janbrennenstuhl.eu, 2026)](https://www.janbrennenstuhl.eu/agentic-identity-broker/) > Link: https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/delegation-vs-robot-accounts/#f-agent-robot-account-combined-permissions > **Finding f-agent-delegation-keeps-actor-identity:** 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. > > Source: [RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 1.1](https://www.rfc-editor.org/rfc/rfc8693#section-1.1) > Link: https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/delegation-vs-robot-accounts/#f-agent-delegation-keeps-actor-identity > **Finding f-agent-token-least-privilege:** 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. > > Source: [RFC 9700, Best Current Practice for OAuth 2.0 Security (IETF, 2025), Section 2.3](https://www.rfc-editor.org/rfc/rfc9700#section-2.3) > Link: https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/delegation-vs-robot-accounts/#f-agent-token-least-privilege > **Finding f-agent-no-long-lived-keys:** 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. > > Source: [AppSec in the Age of Agentic Engineering (janbrennenstuhl.eu, 2026)](https://www.janbrennenstuhl.eu/appsec-agentic-engineering/) > Link: https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/delegation-vs-robot-accounts/#f-agent-no-long-lived-keys ## Evidence **Primary sources on robot accounts and delegated agent access** | Study | Year | Sample | Method | Finding | | --- | --- | --- | --- | --- | | [OAuth 2.0 Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693) (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)](https://www.rfc-editor.org/rfc/rfc9700) (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)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) (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 Agents](https://www.janbrennenstuhl.eu/agentic-identity-broker/) (this 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 Engineering](https://www.janbrennenstuhl.eu/appsec-agentic-engineering/) (this 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](https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/mcp-authorization/) 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](https://www.rfc-editor.org/rfc/rfc9700#section-2.3) 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](https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/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](https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/consent-and-revocation/). 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](https://www.janbrennenstuhl.eu/agentic-identity-broker/), 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](https://www.rfc-editor.org/rfc/rfc8693#section-1.1) 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](https://www.janbrennenstuhl.eu/talks/economies-of-scale-for-mcp/) explain the design, and the [project page](https://www.janbrennenstuhl.eu/projects/agentic-identity-broker/) 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. ## Related - [How does OAuth 2.0 Token Exchange keep provider tokens away from agents?](https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/token-exchange/) - [How should people grant and revoke an agent's access?](https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/consent-and-revocation/) - [How does authorization work for MCP servers?](https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/mcp-authorization/) - [AppSec in the Age of Agentic Engineering](https://www.janbrennenstuhl.eu/appsec-agentic-engineering/) --- Cite as: Jan Brennenstuhl. "Should an agent use a robot account or delegated access?." Brennenstuhl on Security, 13 October 2026. https://www.janbrennenstuhl.eu/knowledge-base/agent-identity/delegation-vs-robot-accounts/ License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) for the original text; credited third-party media keep their own rights.