The token that travelled too far
An MCP server wraps a third-party CRM. It accepts the bearer token the client presents and forwards that same token upstream.
Two things follow. The CRM's audit log attributes every request to the end user's client rather than to your server, so you can't tell callers apart. And a token stolen from an unrelated service, if its signature checks out, gets replayed straight through.
Boundaries, outermost first: Your boundary: MCP server (resource server) CRM boundary: CRM API (upstream; FAILED: wrong identity), CRM's auth server Outside every boundary: MCP client, an empty slot for the the upstream call's credential Connections: MCP client calls MCP server — token for YOU (step 1) MCP server calls the upstream call's credential (step 2) CRM's auth server controls the upstream call's credential — issues the upstream call's credential calls CRM API — a different token (step 3)