--- title: "The Token That Passes Every Check Except the Right One" canonical: "https://current.tinyfish.ai/issue/38/practitioners-corner/article/31159/the-token-that-passes-every-check-except-the" publication: "TinyFish" publisher: "TinyFish" language: "en-US" guide: "https://current.tinyfish.ai/llms.txt" author: "Sable Whitford" author_url: "https://current.tinyfish.ai/team/201" issue: 38 section: "practitioners-corner" section_name: "Practitioner's Corner" published: 2026-07-15 updated: 2026-07-17 word_count: 341 source_links: 1 --- # The Token That Passes Every Check Except the Right One *By [Sable Whitford]()* *July 15, 2026* [Read on the website]() The MCP authorization spec names a failure mode that matters well beyond the protocol itself. It's the confused-deputy problem, and it works like this: an MCP server receives a bearer token that is properly signed, unexpired, issued by a legitimate authorization server. The server checks validity and lets the request through. Then it forwards that same token to a downstream API. Every check passed. The wrong checks. The token was never issued *for that server*. It was issued for a different service entirely, and the MCP server accepted it because it asked "is this token valid?" instead of "was this token issued for me?" One of those is a cryptographic question; the other is a relational one, and skipping it means you've built a replay surface into your architecture. The spec is [explicit about this](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization): servers MUST validate that tokens were intended for them specifically, and MUST NOT pass client tokens through to upstream APIs. Each hop requires its own token, its own authorization relationship. A valid token with no audience binding is just a skeleton key that happens to be well-formatted. **What the spec requires:** - Clients MUST include [resource indicators](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization) (RFC 8707) identifying the intended server in every token request - Servers MUST reject tokens that don't include them in the audience claim - Bearer tokens MUST appear in every HTTP request, even within a single session **What the spec forbids:** - Token passthrough — forwarding a client's token to upstream APIs without obtaining a separate token - Accepting tokens with incorrect or missing audience claims - Including access tokens in URI query strings **Why passthrough breaks things:** A forwarded token lets the downstream API assume the MCP server validated it. Rate limiting, audit trails, and trust boundaries all break because accountability can't be traced per-hop. **The proxy attack variant:** When an MCP proxy uses a static client ID, an attacker can craft a malicious redirect URI. If the authorization server remembers consent via cookies, the consent screen gets skipped, and the authorization code lands on the attacker's server. ## More - [Practitioner's Corner — Issue 38]() - [Issue 38]() - [Publication guide]()