MCP Token Passthrough Needs an Audience Boundary

The decision: pass through, broker or reject

The architectural question is not whether a client can log in. It is whether an MCP server should ever see a bearer token that can also be replayed somewhere else. If the answer is yes, the server is now part of the authorization plane. That may be acceptable for a narrow gateway you fully control. It is usually the wrong default for a tool server that can be extended, patched, proxied or compromised by someone else. In practice, think in three outcomes: Pass through, broker or reject.

Use three outcomes. Pass through only when the downstream resource, token audience, transport, logging and revocation rules are all owned and audited as one unit. Broker when a narrow, single-purpose gateway can mint or exchange a token for exactly one downstream audience and does not persist it. Reject when the server would receive a broad bearer token, when the token might be reused across services, or when the team cannot prove where the credential can travel.

What the MCP documents now say

The MCP security best-practices page explicitly calls out token passthrough risks, local MCP server compromise and SSRF-style attacks. That is already enough to dismiss the fantasy that a local server is automatically safe because it is “just on my machine.” The document is not saying token forwarding is impossible. It is saying token forwarding is a security decision with real blast radius.

The MCP authorization specification goes further and requires servers to validate that access tokens were issued specifically for them as the intended audience. In other words, the server is not entitled to any token merely because a client sent it one. The tools specification reinforces that tool exposure and invocation are security-sensitive, which matters when a server can call downstream APIs, mutate state or relay credentials on the user’s behalf.

Why audience restriction changes the problem

OAuth resource indicators exist because a bearer token without a clear audience is too easy to misuse. RFC 8707 defines resource indicators so the client can request a token for a specific protected resource, and RFC 9728 gives the protected resource a standard metadata document so the client can discover where the authorization belongs. RFC 9700 then treats audience-restricted access tokens as a current best practice for limiting replay and token leakage.

That is the design pattern MCP should inherit. The client should know which downstream resource it is talking to, the resource should expose the metadata needed to obtain the right token, and the server should validate the audience rather than accepting a generic credential and deciding later what it may mean. If the token can be forwarded to multiple services, the audience boundary has already been blurred.

The local relay shows how little work token forwarding requires

I ran a tiny loopback demo on Node v24.10.0 with one local proxy and one local downstream server. The client sent `Authorization: Bearer aag-demo-token` to the proxy. The proxy forwarded the header unchanged to the downstream resource. The downstream server then returned the same bearer token in its response. That is not a defect report against MCP. It is a demonstration of how easily a relay can inherit the user’s authority if nobody constrains it.

The exact response was `{"clientAuthorization":"Bearer aag-demo-token","downstream":{"receivedAuthorization":"Bearer aag-demo-token","url":"/resource"}}`. In one line of JSON, you can see the whole problem: once the server forwards the header unchanged, the downstream service cannot tell whether the client intentionally delegated that audience or the relay simply copied a token it should have dropped.

Localhost is not a trust boundary

The MCP docs call out local server compromise for a reason. A local stdio or localhost transport tells you where packets moved, not who can read the process memory, environment, logs or file descriptors. A compromised local server can still exfiltrate headers, cache refresh tokens, call arbitrary downstream APIs and pivot through the same workstation identity the user trusts for everything else.

The risk is larger when the server can see raw headers, bearer tokens, tool arguments or unredacted payloads. Logs, traces and error reporters are another leakage path. So are SSRF-style fetches to metadata endpoints or authorization servers. The moment the server is allowed to reach outward on its own, it can become a credential broker, an exfiltration point or a confused deputy even if the client never intended that authority.

The safe pattern is narrow and explicit

If passthrough is unavoidable, treat it like a production integration boundary. Pin one downstream resource. Bind the token audience to that resource. Make the forwarding code path explicit and one-way. Keep refresh tokens out of the relay entirely. Refuse to store the token in caches, temp files, traces or crash reports. Rotate tokens quickly enough that any accidental exposure has a short lifetime.

Then add isolation: run the MCP server as least-privilege process code, deny arbitrary outbound destinations, audit the exact downstream hostnames and paths, and verify that the server cannot discover or mint broader authority on its own. If you cannot write down the destination allowlist, the credential lifetime and the revocation story in one paragraph, the passthrough is too broad to approve.

When to reject the design outright

Reject the design when the server is multi-tenant, extensible, plugin-driven or operated by a third party and the token would let that server act across multiple resources. Reject it when the team wants to pass through a single opaque bearer token because that is easier than integrating resource metadata or token exchange. Reject it when the only justification is that the server is local and “therefore safe.”

Also reject it when the team cannot prove the following: who issues the token, which resource is the audience, whether the relay sees the full token, where the token is logged, whether refresh tokens exist, whether the downstream can revoke independently and whether a compromise of the relay would expose authority beyond the intended resource. Missing any one of those answers means the token path is still under-specified.

What to measure before approval

Measure the end-to-end path, not the marketing promise. Record which process first sees the token, which hop forwards it, which service validates the audience, which logs redact it and which component is able to rotate or revoke it. Repeat the test with the relay compromised, the downstream unavailable and the token expired. A secure architecture should fail closed in each case.

Also measure how the design behaves when a downstream service requests a different audience, a token expires mid-conversation or a tool call fans out into a second dependency. If the answer is always “the same bearer token gets copied again,” the architecture is not a bounded authorization design. It is just credential forwarding with better branding.

The operating rule

Use audience-bound tokens by default. Use resource metadata and token exchange when a relay must exist. Keep local MCP servers on a short leash because localhost is still a process with authority. If the protocol path cannot prove where the token belongs, do not forward the token.

That rule is stricter than a product demo but cheaper than a credential incident. It preserves the useful part of MCP—typed tools, discoverable resources and structured orchestration—without letting a convenience relay become a latent authorization proxy.

Disclosures

AccessAllGPT did not receive access, payment, private data or review from the MCP project, Anthropic, the IETF or any vendor. The local experiment used only synthetic headers and loopback networking. No vendor supplied data, paid for placement or received an endorsement. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with OpenAI. Publication-wide relationships are listed on the disclosures page.