Agent identity · Brennenstuhl on Security

Should an agent use a robot account or delegated access?

Tue, 13 Oct 2026 00:00:00 +0200

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 #

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)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

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

Link to this finding Save as image (PNG, 1200 by 630 pixels)

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

Link to this finding Save as image (PNG, 1200 by 630 pixels)

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)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on robot accounts and delegated agent access
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.

How does OAuth 2.0 Token Exchange keep provider tokens away from agents?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: OAuth 2.0 Token Exchange (RFC 8693) lets a client trade one token for another token meant for a specific target service. When a gateway runs that exchange on each tool call, as in the Agentic Identity Broker, the provider token stays between the broker, the gateway and the provider and never reaches the agent.

Key findings #

RFC 8693 lets a client present a security token to an OAuth 2.0 authorization server acting as a Security Token Service and receive a new token, for example one scoped more narrowly for a downstream service.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

In the Agentic Identity Broker, an MCP gateway exchanges the agent’s token for the matching provider token through RFC 8693 on each tool call, so the provider token never reaches the agent.

Source: What I Learned Building an Identity Broker With Coding Agents (janbrennenstuhl.eu, 2026)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

RFC 8693 warns that without client authentication at the token endpoint, anyone holding a compromised token can trade it for other tokens.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 2.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

In a JWT issued through token exchange, access control decisions must consider only the top-level claims and the current actor named in the act claim, while nested prior actors are informational.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 4.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

A token exchange creates no tight link between the input and output tokens, so passing revocation from one to the other depends on the implementation and isn’t a property of the protocol.

Source: RFC 8693, OAuth 2.0 Token Exchange (IETF, 2020), Section 2.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on token exchange for agents
Study	Year	Sample	Method	Finding
OAuth 2.0 Token Exchange (RFC 8693)IETF	2020	n/a	Specification	Defines the token exchange grant, its request and response parameters, and the act and may_act claims.
Resource Indicators for OAuth 2.0 (RFC 8707)IETF	2020	n/a	Specification	Defines the resource parameter that tells the authorization server where a token will be used.
What I Learned Building an Identity Broker With Coding Agentsthis site	2026	n/a	Field report	Describes how a gateway exchanges the agent’s token for the matching provider token on each tool call.
Economies of Scale for MCP and Agentsthis site	2026	n/a	Talk	Presents the broker’s delegation model at AGNTCon + MCPCon Europe 2026.

What to do #

For engineers #

Put the exchange in a component the agent can’t control, such as a gateway, and authenticate that component at the token endpoint. Name the target with resource or audience and ask for the smallest scope the tool call needs. RFC 8693 points out that broad requests across many target services are more likely to be refused.

Treat revocation as your own job. The RFC leaves it to the implementation whether revoking a grant or an input token affects tokens already issued, so keep issued tokens short-lived and check the grant at exchange time. Consent and revocation covers the rest.

If an agent’s token can travel further, use the act claim to record the agent as the actor and the may_act claim to state who may act for the subject.

For product and UX #

Users don’t see the exchange, but they see its effects. When a tool call fails because a grant expired or was revoked, tell the user which service and which agent were affected and how to grant access again.

How it works #

RFC 8693 defines the exchange as 1 request and 1 response at an authorization server’s token endpoint. With a gateway between an agent and its tools, the exchange runs like this:

Step through the exchange

The agent calls a tool through the gateway and presents its own token.
The gateway acts as the RFC 8693 client. It sends a POST to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:token-exchange, a subject_token that represents the person on whose behalf the request is made, and its subject_token_type. Optional parameters name the target (resource, audience), the access wanted (scope), and the token type wanted (requested_token_type).
The gateway authenticates with the normal OAuth 2.0 client authentication methods.
The authorization server validates the presented tokens and decides by policy whether to issue a token for the named target. If it refuses, it answers with invalid_request, or with invalid_target when it won’t issue a token for the requested target.
A successful response is a normal OAuth token response: access_token carries the issued token, together with issued_token_type, token_type, and, as recommended, expires_in. The issued token doesn’t have to be an OAuth access token.
The gateway calls the target service with the issued token and returns only the result to the agent.

The following request shows step 2 with placeholder hosts and tokens. It illustrates the RFC parameters and isn’t the broker’s API. I’ve left the values unencoded and added line breaks for readability; a real request URL-encodes the form body.

token-exchange.http

POST /token HTTP/1.1
Host: broker.example.com
Authorization: Basic <gateway client credentials>
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<token the agent presented>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&resource=https://api.provider.example/
&scope=<permissions the tool call needs>

The Agentic Identity Broker that Magnus Jungsbluth and I built uses this pattern, as I describe in the retrospective. A user grants an agent access to a service, such as GitHub, with a chosen permission set and an optional expiry, and the broker stores the provider tokens encrypted. On each tool call, an MCP gateway such as agentgateway exchanges the agent’s token for the matching provider token, so the provider token never reaches the agent.

RFC 8693 also defines an optional actor_token for the party that will act on behalf of the subject. In the issued JWT, the act claim can record that actor, and nested act claims record a chain of earlier actors. The broker roadmap lists token exchange for agent-to-agent calls as planned work.

How should people grant and revoke an agent's access?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: Let people grant each agent access per service, with a permission set they choose and an expiry, and let them revoke that grant at any time. Revoking the grant has to stop every token derived from it, so keep issued tokens short-lived and check the grant whenever a new token is issued.

Key findings #

In the Agentic Identity Broker, a user grants an agent access to a service with a chosen permission set and an optional expiry, and can revoke that grant at any time.

Source: What I Learned Building an Identity Broker With Coding Agents (janbrennenstuhl.eu, 2026)

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Under RFC 7009, revoking a refresh token should also invalidate all access tokens based on the same authorization grant if the authorization server supports access token revocation.

Source: RFC 7009, OAuth 2.0 Token Revocation (IETF, 2013), Section 2.1

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Immediate revocation of self-contained access tokens needs backend coordination that RFC 7009 calls non-standardized, and short-lived access tokens limit how long a revoked token stays in use.

Source: RFC 7009, OAuth 2.0 Token Revocation (IETF, 2013), Section 3

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on agent consent and revocation
Study	Year	Sample	Method	Finding
OAuth 2.0 Token Revocation (RFC 7009)IETF	2013	n/a	Specification	Defines a revocation endpoint and how revoking one token can revoke related tokens and the grant.
Best Current Practice for OAuth 2.0 Security (RFC 9700)IETF	2025	n/a	Specification	Binds refresh tokens to the consented scope and resources and lets them expire after inactivity.
Resource Indicators for OAuth 2.0 (RFC 8707)IETF	2020	n/a	Specification	Lets the authorization server tell the user which resources a client will access on their behalf.
OAuth 2.0 Token Exchange (RFC 8693)IETF	2020	n/a	Specification	Leaves revocation of tokens issued by an exchange to the implementation.
Model Context Protocol: Authorization (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Asks clients to request minimal scopes first and add scopes through step-up authorization.
What I Learned Building an Identity Broker With Coding Agentsthis site	2026	n/a	Field report	Describes per-agent grants with chosen permissions, optional expiry and revocation at any time.

What to do #

For engineers #

Model the grant as a record of its own that names the person, the agent, the service, the permissions and the expiry, and issue every token from it. Check that record whenever you issue or exchange a token, so a revocation takes effect at the next tool call. Expiring tokens are the fallback for tokens you can’t recall.

Wire revocation through every layer you control. Call the RFC 7009 revocation endpoint where the provider offers one, and don’t stop at the first token. RFC 8693 says tokens issued by a token exchange aren’t linked to their input token, so revoking one doesn’t reach the other unless you build that.

Ask for the least access first. The MCP authorization specification describes this as step-up authorization: request minimal scopes and add more when a server asks for them.

For product and UX #

Show each grant with the agent, the service, the permissions and the expiry in plain words, and put the revoke action next to it. Default to an expiry instead of open-ended access. When an agent needs more access, ask at that moment for that specific permission.

How it works #

Granting access in OAuth starts with an authorization request. The client names the access it wants in scope and, with RFC 8707, the resources in resource. RFC 8707 notes that the authorization server can use those resource values to inform the user about the resources the client will access on their behalf. The consent screen can then name the service, not only a list of scopes.

In the Agentic Identity Broker, which Magnus Jungsbluth and I built, a user grants an agent access to a service with a chosen permission set and an optional expiry. The broker keeps both the user and the agent in every authorization decision. I describe the design in the retrospective, and my AppSec essay argues for narrow, time-limited permissions that the user can revoke at any moment.

Revoking access in OAuth uses the revocation endpoint from RFC 7009. A client sends the token it wants revoked, and the server invalidates it and, depending on policy, related tokens and the grant itself. RFC 7009 gives 2 reasons this matters for people: it stops a grant from staying valid without the user’s knowledge, and revoked grants disappear from any list of grants the authorization server shows the user. The server answers with HTTP 200 even for an invalid token. A 503 means the client must assume the token still exists.

Self-contained tokens make revocation harder. A resource server can check a self-contained token, such as a JSON Web Token (JWT), without asking the authorization server, so it won’t learn about a revocation on its own. RFC 7009 names short-lived access tokens with refresh tokens as one alternative. RFC 9700 adds that refresh tokens must stay bound to the consented scope and resources, should expire after a period of inactivity, and may be revoked on security events such as a password change or logout.

How does authorization work for MCP servers?

Tue, 13 Oct 2026 00:00:00 +0200

Short answer: In the MCP authorization specification (revision 2026-07-28), a protected MCP server over HTTP is an OAuth 2.1 resource server: it publishes Protected Resource Metadata that points clients to its authorization server and accepts only tokens issued for itself. MCP clients discover that authorization server, run the authorization code flow with PKCE, and name the MCP server in a resource parameter on every authorization and token request.

This entry describes the Model Context Protocol (MCP) authorization specification as of revision 2026-07-28, which the MCP versioning page listed as the current revision on 13 October 2026. Later revisions may change these requirements.

Key findings #

As of MCP revision 2026-07-28, MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728), and MCP clients must use it to discover the authorization server.

Source: Model Context Protocol, Authorization, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

MCP clients must send the RFC 8707 resource parameter with the MCP server’s canonical URI in both authorization and token requests, whether or not the authorization server supports it.

Source: Model Context Protocol, Authorization, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

MCP servers must validate that an access token was issued specifically for them as the intended audience and must not accept or transit any other tokens.

Source: Model Context Protocol, Authorization, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

An MCP server that calls upstream APIs must use a separate token from the upstream authorization server and must not pass through the token it received from the MCP client.

Source: Model Context Protocol, Authorization Security Considerations, revision 2026-07-28

Link to this finding Save as image (PNG, 1200 by 630 pixels)

Evidence #

Primary sources on MCP authorization
Study	Year	Sample	Method	Finding
Model Context Protocol: Authorization (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Defines roles, discovery, the authorization flow, the resource parameter, token handling and step-up authorization for HTTP transports.
Model Context Protocol: Authorization Security Considerations (revision 2026-07-28)Model Context Protocol	2026	n/a	Specification	Requires audience binding, PKCE, exact redirect URI matching and a ban on token passthrough.
OAuth 2.0 Protected Resource Metadata (RFC 9728)IETF	2025	n/a	Specification	Defines the metadata document and the WWW-Authenticate parameter that point a client to a resource’s authorization servers.
Resource Indicators for OAuth 2.0 (RFC 8707)IETF	2020	n/a	Specification	Defines the resource parameter and asks authorization servers to audience-restrict tokens to it.
Economies of Scale for MCP and Agentsthis site	2026	n/a	Talk	States that an agent should not hold a shared, long-lived provider credential and presents the broker’s delegation model.

What to do #

For engineers #

For an MCP server over HTTP, publish Protected Resource Metadata, answer unauthenticated requests with a 401 that points to it, and check the audience of every token. Put the scopes an operation needs in the WWW-Authenticate challenge, all at once. If the server calls other APIs, get its own token for each of them. The token exchange entry shows one way to do that.

For an MCP client, implement both discovery mechanisms, PKCE with S256, the resource parameter, and the issuer check. Never put tokens in the query string.

An MCP server on the STDIO transport is outside this specification, which says such servers should take credentials from the environment. Keep those credentials short-lived and task-scoped, as my AppSec essay recommends for coding agents.

For product and UX #

Start with the minimal scopes and ask for more only when an operation needs them. The specification warns that misconfigured scopes may require frequent user interaction, and that challenging one scope at a time forces several authorization round-trips for one operation.

How it works #

The specification defines 3 roles. The MCP server is an OAuth 2.1 resource server, the MCP client is an OAuth 2.1 client acting for a resource owner, and the authorization server issues the tokens. Authorization is optional for MCP implementations. Implementations on HTTP-based transports should conform to the specification, and STDIO implementations should not.

A first connection follows these steps:

The client sends an MCP request without a token. The server answers with HTTP 401 and a WWW-Authenticate header that carries the resource_metadata URL from RFC 9728 and, as the specification recommends, the required scope.
The client fetches the Protected Resource Metadata and picks an authorization server from it. It then reads that server’s metadata through OAuth 2.0 Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery. Clients must support both, and if the metadata doesn’t list code_challenge_methods_supported, the client must refuse to proceed.
The client gets a client ID. It uses pre-registered client information if it has some, then Client ID Metadata Documents if the authorization server supports them. Dynamic Client Registration is deprecated and kept only as a fallback for backwards compatibility.
The client starts the authorization code flow with PKCE, the resource parameter and the selected scopes, and records the expected issuer. When the response comes back, it validates the iss parameter (RFC 9207) before it redeems the code.
The client redeems the code with the code_verifier and the resource parameter, then sends the access token in the Authorization: Bearer header on every request.

When a token lacks a scope at runtime, the server answers with 403 and error="insufficient_scope". The client then runs a step-up flow with the union of its previous scopes and the new ones.

Revision 2026-07-28 doesn’t cover token exchange in its core authorization pages. Optional authorization extensions live in a separate repository. In the Agentic Identity Broker, which Magnus Jungsbluth and I built, an MCP gateway exchanges the agent’s token for the matching provider token through RFC 8693, so the provider token never reaches the agent. I describe that design in the retrospective, and we presented it in our AGNTCon + MCPCon talk.

Agent identity · Brennenstuhl on Security

Should an agent use a robot account or delegated access?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Related #

How does OAuth 2.0 Token Exchange keep provider tokens away from agents?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Step through the exchange

Related #

How should people grant and revoke an agent's access?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Related #

How does authorization work for MCP servers?

Key findings #

Evidence #

What to do #

For engineers #

For product and UX #

How it works #

Related #