You passed the token on. Now nobody knows it was you.

// the rule is one sentence with two halves

The MCP authorization spec states the whole thing in two lines, and most write-ups only ever quote the first:

Audience validation is the accept half: does this credential name my server? This page is the transit half, which is what happens when your server takes the credential it was handed and sends it onward to whatever it needs on the other side.

The far side stops checking

This is the part that makes forwarding worse than it looks, and the spec names it directly. When a server forwards unmodified tokens downstream, the receiving API

Nothing is being spoofed here. The mechanism is an assumption: being in the middle is exactly what makes the far side relax. It treats the call as pre-checked because it arrived through you — and if you never checked it, that assumption is the only check that ever happened.

So whatever you waved past, it waves past too.

The log names your user, not you

Most people picture this the wrong way round, including two earlier drafts of the video: you assume the far side records your server and blames you. It records the opposite.

It writes down the name on the credential it was handed, and that name is your user's. Your server never appears in its record at all. If your name were on it you would at least be traceable — which is why "nobody knows it was you" is a problem rather than a relief.

The near side loses information too. A server accepting an upstream-issued token, which may be opaque to it, cannot distinguish between the clients calling it. So neither end of the hop has a line naming your server, and you cannot separate your own traffic from a stolen credential's.

The controls you were counting on never fire

There is a third consequence the short had no room for, and it is the one that costs you quietly rather than dramatically:

Per-caller limits on the far side are aimed at a caller it cannot see. They are not defeated so much as never engaged.

And where a stolen credential is involved, the spec is blunt about what your server has become: if it passes tokens without validating their claims, an attacker holding a stolen token can use the server as a proxy for data exfiltration. Note the precondition in that sentence — it is the consequence of forwarding something you never checked, not of forwarding as such.

The fix is the negative

The token stops at your server. That is the quotable half and it is absolute: MUST NOT ... transit. Whatever your server needs on the other side, it needs its own way in.

What that looks like in your stack is deliberately not drawn here, because the spec's detailed downstream flow lives in its confused-deputy section, which has its own preconditions and is a different topic. Two things worth saying instead:

The credential you were handed is not invalid, forged or expired. It is a perfectly good credential that names somebody else, which is exactly why this ships so easily — it sails through every check you did write. And the spec's own note on starting as a "pure proxy" is worth taking seriously: "Starting with proper token audience separation makes it easier to evolve the security model." The shortcut is cheapest on day one and most expensive the day you need a control.

Sources: MCP Authorization — Token Handling · MCP Security Best Practices — Token Passthrough. Related: the accept half · untrusted content vs untrusted credentials.