A GitHub issue about a failing deployment has been assigned to you. You ask an internal agent to check the issue against the deployment runbook and post a status update. The agent works through tools exposed over MCP, then hands the runbook lookup to a second agent.
From your side, that is one request. Behind it, several services are making separate decisions about identity and access.
The team running the agent needs to know who initiated the work and which principal is acting at each step. It also needs to know which permissions should reach the next system. That becomes harder once agents share MCP infrastructure or delegate work.
Identity at each hop
A shared service account is a tempting starting point for internal agents. Give the agent enough access to the systems it needs, then let every user’s requests run through that account.
Problems appear as soon as users have different permissions.
Suppose 100 employees use the same agent to work with GitHub. If every request arrives under one service identity, GitHub sees the application making the call but loses the user’s authorization context. The service account needs broad access across everyone the agent serves, or it has to use only the permissions every user shares.
The audit trail loses useful information as well. A log that connects the call to the user who initiated it and the agent that performed the work tells you much more than one showing only that an agent account accessed a repository.
Shared MCP deployments make this a common architecture question. Picking the magic number of agents per MCP server matters less than keeping their identities and permissions separate.
There is no single authorization pattern for every hop. Interactive agents commonly use user-delegated OAuth. Headless agents can operate under their own workload identity using client credentials. RFC 8693 token exchange supports delegation across services, with the authorization server deciding whether to issue a new token and which resource or scopes it receives.
Some enterprise services already accept a user’s corporate identity token directly. In those environments, preserving that identity across the call lets the downstream service continue enforcing its existing user-level permissions.
MCP puts a firm boundary around token handling. An MCP server must validate tokens issued specifically for it and must not accept or transit other tokens. The MCP authorization specification sets out those token-handling requirements.
That is different from the pattern Mohit Gurnani describes in his AGNTCon + MCPCon North America session, One MCP Server, Many Agents: The Identity Gap OAuth Doesn’t Close. His approach forwards a corporate identity token that the downstream service already knows how to validate, rather than forwarding the access token issued for the MCP server itself. His session goes further into the decision framework for choosing between authorization patterns and the gateway implementation used to preserve user identity across calls.
Before wiring up permissions, map the identities along the path. Who initiated the request? Which agent is executing it? Which identity will the MCP server validate? Which principal will the downstream service authorize?
If all of those collapse into one broadly privileged credential, later controls have less information to work with.
Delegation needs its own authorization boundary
The first agent in our example can read GitHub issues and post updates. It delegates a narrower job to a second agent, which only needs to retrieve a deployment runbook from the internal knowledge base.
Giving that second agent every permission held by the first increases its access without helping it complete the task.
A delegated credential can be limited to the resource and scopes required for that work. Where token exchange is available, RFC 8693 provides a standard mechanism for requesting a token for a downstream resource. The authorization server decides whether its policy allows the exchange and what authority the resulting token receives.
RFC 8693 also defines the JWT act claim. It records the current actor, while nested act claims can preserve earlier actors in a delegation chain. Under the RFC, those earlier actors are informational only. Access-control decisions use the current actor and the token’s top-level claims.
This preserves useful delegation history without handing the sub-agent the parent agent’s complete credential set.
Long-running work introduces another case. A task can pause for approval and resume 3 days later. During that gap, a user’s role can change or access to the target resource can be revoked. A credential can also expire before the agent reaches the action that changes something.
Watch out for approvals that were valid when the task started. They do not automatically remain valid when the action runs. Teams need to decide which operations trigger another authorization check and what should happen when the required authority is no longer available.
A low-risk read may only require refreshed credentials. A consequential write may need another approval before execution.
Tracing the complete action
Suppose the final GitHub call in our example produces this record:
POST /repos/acme/service/issues/184/comments → 201
A teammate reading the status update might ask, “all good?” The record confirms that the call succeeded. It says little about how the request reached that endpoint.
An agent workflow may involve a path like this:
Developer → primary agent → delegated agent → MCP server → downstream service
Authorization data and distributed tracing preserve different parts of that path.
Token claims can record the subject, current actor and scopes associated with a request. Where RFC 8693 is used, the act claim described above can retain the delegation history.
Distributed tracing follows execution across process boundaries. OpenTelemetry context propagation carries tracing context between components, while W3C Trace Context defines traceparent and tracestate. The same trace can follow a request from the primary agent through the MCP server to the service that completes it.
The 2026-07-28 MCP specification release candidate also documents W3C Trace Context propagation in _meta, fixing the traceparent, tracestate and baggage key names so traces can correlate across SDKs and gateways.
During an incident or review, the authorization trail helps identify the principals and authority involved. The trace shows which calls occurred and how the request moved through the system.
A useful audit record should connect the original request to the eventual agent action and expose any delegated work along the way. It should also identify the downstream change that completed, along with failed calls or actions rejected by policy.
Without that context, individual services can have adequate logs while the complete agent action remains difficult to reconstruct.
Six questions before an agent gets access
Before connecting an agent to another system, check whether the architecture can answer these questions:
- Who initiated the request? Can each operation be connected to its originating user or workload?
- Which agent is acting? Is the executing agent distinguishable from the principal that requested the work?
- Which authority reaches the downstream service? Does that service receive enough identity context to enforce the intended permissions?
- What happens during delegation? Can a sub-agent receive credentials limited to its assignment?
- What happens when access changes mid-task? Which actions trigger another authorization check?
- Can the complete path be reconstructed? Do authorization records and trace context preserve enough information to explain the action afterward?
Identity at AGNTCon + MCPCon North America
Identity and delegated access are on the agenda at AGNTCon + MCPCon North America, including Mohit Gurnani’s session on shared MCP deployments and Masato Kozuka’s session on user-scoped enterprise tool access.
To celebrate De La Soul playing the AI Community Bash on October 21, we’ve hidden some of their track titles in this post - how many did you spot?
Join us in San Jose on October 22-23, and use code COMMUNITY25 for 25% off registration.
Share
Author
