Your MCP server is taking the wrong tokens

// the anti-pattern

The MCP Security Best Practices page names it directly:

And the mitigation is written in RFC 2119 language, not as advice:

Forwarding the credential the client already holds is the shortest path to a working server, and it looks like delegation. That is exactly why it gets shipped.

The token isn't broken

This is the part that matters, and the part most summaries skip. A passthrough vulnerability does not involve a forged, expired or malformed token. It involves a completely genuine credential that was issued for a different service.

The piece that makes this click is the one most explanations skip: your server does not issue its own logins. It trusts an authorization server, and that same authorization server mints tokens for many resource servers, not just yours. Every one of them is properly signed and unexpired. Each carries a claim naming the single service it was issued for.

So picture a row of venues that all sell through one ticketing app. Someone shows up at your door holding a ticket for the cinema. It is a real ticket, from the app you trust, and it has not expired. Your doorman checks that it is genuine, and it is, so in they go.

The ticket never stopped being for the cinema. Your door just never asked. That is the whole bug, and note what it is not: the ticket has no special power, and nothing about it is forged. Your door simply had no standard beyond "is this real". Which means your check is not may this caller use me — it is does this caller have a token from anywhere. Anyone who has ever signed in to anything on that issuer can call you, and it will all look fine.

Every check you probably did write — is it well-formed, is the signature good, has it expired — passes. The check that was missing is the one asking who the token was made for:

The spec points at exactly this: when a server "doesn't verify that tokens were specifically intended for it (for example, via the audience claim, as mentioned in RFC9068), it may accept tokens originally issued for other services". That, it says, "breaks a fundamental OAuth security boundary, allowing attackers to reuse legitimate tokens across different services than intended".

What it costs once you forward it

Accepting the wrong token is one problem. Passing it downstream is a second, larger one — and the reason is the opposite of what people usually assume. Forwarding the token does not stamp your name on the request. It stamps the token's.

The record does not point back at you. In the spec's words, the downstream resource server's logs "may show requests that appear to come from a different source with a different identity, rather than the MCP server that is actually forwarding the tokens". The far side reads the credential it was handed, so your server never appears in it. Your own server, meanwhile, "will be unable to identify or distinguish between MCP Clients" when they arrive holding opaque upstream tokens. Neither end has a true account of who did what.

You become the exfiltration path. The spec is blunt: a malicious actor in possession of a stolen token "can use the server as a proxy for data exfiltration". That is what makes this worth caring about. You are not the name on the record — you are the route, and the route is the part nobody logged.

The rule

Validate the audience. Reject anything not issued for you. Your MCP server is a resource server in its own right, not a pipe — it needs its own tokens, and it needs to check that the ones it receives were minted for it.

The spec adds a practical reason to do this even if you are "just a proxy" today: "Even if an MCP Server starts as a 'pure proxy' today, it might need to add security controls later. Starting with proper token audience separation makes it easier to evolve the security model."

Related: prompt injection is the other half of the MCP threat picture and is a genuinely different problem — that one is untrusted content steering the model, where this one is your server trusting a credential. And what the model actually sees of your tool covers the design side of the same server.