Why do MCP servers need a separate downstream token instead of forwarding the client token?

Why downstream tokens matter in an MCP server

An MCP server should not simply relay the client’s bearer token because the server is not the same trust boundary as the original client. The server needs its own downstream token so the resource can recognise the server as the caller, apply the right audience checks, and avoid turning one user credential into a reusable pass for every backend the server can reach.

That separation is what makes brokered access different from passthrough. The client can still authorize the overall workflow, but the downstream service sees a token minted for itself, not a generic token forwarded unchanged through the chain.

What token passthrough breaks in practice

Forwarding the original token collapses two distinct relationships into one: the client to MCP server relationship, and the MCP server to downstream service relationship. That creates ambiguous authority, because the downstream system cannot tell whether the action was directly requested by the user, mediated by the server, or opportunistically reused in a later call.

It also weakens traceability. If the same token appears across multiple hops, logs and audit records no longer show which service actually exercised the privilege at the point of action. That is why a separate token is a control, not just a protocol preference.

MCP authorization guidance is explicit that servers should act as OAuth 2.1 resource servers with audience-bound tokens rather than relying on a single forwarded credential. The protocol’s authorization model, along with audience restriction via resource indicators, is designed to preserve boundaries between the caller, the broker, and the protected resource, as described in the MCP authorization specification and RFC 8707: Resource Indicators for OAuth 2.0.

How separate downstream tokens reduce blast radius

A downstream token narrows what the MCP server can do if it is compromised or misused. Instead of one broad credential that can be replayed across many services, each token can be scoped to a specific audience, time window, and action surface. That limits lateral movement and makes revocation more precise.

It also helps prevent confused deputy behaviour. If the downstream token is minted for the target service and tied to the right audience, the service can enforce that the MCP server is authorised to act in that role only, rather than inheriting the client’s full access context by accident.

For this reason, MCP security guidance is closely aligned with sender-constrained and audience-restricted OAuth patterns. The RFC 9700 OAuth 2.0 security BCP and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) are relevant because they both address token replay and the need to bind credential use more tightly to the intended caller.

Risk and Threat Considerations

Token passthrough turns a single client credential into a shared secret across multiple trust relationships, which increases the impact of leakage, replay, and confused-deputy abuse. In an MCP chain, that can let a downstream service believe it was directly authorised by the client when it was only reached through an intermediary.

Failure mechanism: The MCP server forwards a bearer token unchanged, so the downstream service cannot distinguish delegation from direct possession, and the same credential can be reused outside its intended audience.

Impact: Audit evidence becomes unreliable, privilege boundaries blur, and compromise of one hop can expose every downstream service that accepts the forwarded token.

Practitioner Guidance

What to verify: Confirm that the MCP server exchanges or mints a downstream token for the target resource instead of forwarding the client’s original token. If the downstream service only sees a generic bearer token, the architecture is still relying on passthrough, even if the call path is otherwise authenticated.

Decision rule: If the server is acting as a broker or agent, use audience-restricted downstream tokens and treat direct forwarding as an exception that needs a documented security justification. If the downstream action is sensitive, require a token that is specific to that service and short-lived enough to limit reuse.

What practitioners underestimate: The main failure is often not “unauthorised access” in the abstract, but loss of attribution. When the wrong token is reused, the environment may still function while silently breaking auditability, incident response, and least-privilege assumptions.

Practitioner takeaway: In MCP, a separate downstream token is the mechanism that preserves who is acting, for whom, and under what audience, which is why it is essential to secure delegation without flattening trust boundaries.

Related resources from NHI Mgmt Group

• Guide: MCP Security Guide
• Why do MCP servers need audience-bound tokens instead of accepting any bearer token that reaches the route?
• Why do MCP servers need context-aware authorization instead of token validation alone?
• How should organizations prioritize security in their MCP implementations?
• Why do MCP tools need server-side policy checks instead of token-only controls?