Token passthrough creates confused deputy risk because downstream services may accept a token that was issued for a different audience. That breaks authorization boundaries and can expose data or actions beyond the original MCP request. Each upstream dependency should receive its own token with its own audience and scope.
Why This Matters for Security Teams
When an mcp server forwards a client token upstream, the security boundary stops being the MCP request and becomes whatever the upstream API is willing to trust. That is where confused deputy risk appears: a token issued for one audience can be replayed in a context it was never meant to authorize. The result is not just broken least privilege, but a loss of control over who can act on behalf of whom.
This matters because MCP deployments often sit between user intent, tool execution, and third-party APIs, so one bad forwarding decision can widen access across several systems at once. Guidance from the OWASP Agentic AI Top 10 treats token handling as an authorization boundary, not a transport detail, and NHIMG research shows how quickly that boundary erodes in real deployments. In Guide to the Secret Sprawl Challenge, the broader pattern is clear: once credentials are reused across layers, traceability and revocation both degrade.
In practice, many security teams encounter the misuse only after an upstream service has already accepted an overbroad token and performed an action that could not be cleanly attributed back to the original request.
How It Works in Practice
The safe pattern is to treat the MCP server as a trust boundary that should authenticate the client, then obtain its own upstream credential for each dependency. That upstream token should be minted for the specific audience, scope, and purpose of the downstream call, rather than relaying the client’s bearer token unchanged. This is the same basic control principle behind audience restriction in OAuth and related identity standards, where token validity depends on who the token was issued for and what it is allowed to reach.
In practical terms, that means the MCP server should:
- Validate the incoming client token for the MCP server’s own trust domain.
- Exchange or mint a new token for the upstream API with the narrowest needed audience and scope.
- Use short-lived credentials so revocation and expiry actually limit blast radius.
- Log the original request context separately from the upstream credential used.
- Keep tool permissions and upstream access decisions distinct, so a tool grant is not treated as a universal API grant.
This model aligns with current guidance from the OWASP Top 10 for Agentic Applications 2026 and with the operational concerns raised in NHIMG’s State of MCP Server Security 2025, which notes that only 18% of deployments implement any form of access scoping for tool permissions. The same problem appears in token forwarding: if every dependency inherits the same bearer token, every dependency inherits the same failure mode.
These controls tend to break down when upstream APIs are legacy systems, because they often accept bearer tokens without audience enforcement or do not support clean token exchange.
Common Variations and Edge Cases
Tighter token isolation often increases implementation overhead, requiring teams to balance stronger authorization boundaries against integration complexity. That tradeoff becomes more visible in multi-tenant MCP environments, where one server serves different users, tools, and upstream services at the same time.
There is no universal standard for this yet, but current guidance suggests a few recurring exceptions. Some upstream services still expect delegated user identity, while others require service-to-service identity only. In those cases, the right answer is not blanket passthrough, but explicit policy: define which calls can use delegated identity, which must use workload identity, and which should never leave the MCP trust domain at all.
The risk is higher when token lifetimes are long, scopes are coarse, or the MCP server chains multiple tools before making a single upstream request. That is also where breach patterns become familiar, as shown in NHIMG’s Salesloft OAuth token breach and broader secret exposure trends discussed in the Guide to the Secret Sprawl Challenge. In those environments, the control that looks simplest on paper is often the one that creates the largest blast radius in production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Token passthrough is an authorization flaw in agentic tool chains. |
| CSA MAESTRO | IAM-02 | MAESTRO addresses identity boundaries for autonomous tool execution. |
| NIST AI RMF | GOVERN | AI RMF governance covers accountability for runtime authorization decisions. |
Define who can delegate identity, who approves scopes, and how exceptions are logged.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
