An MCP server accepts upstream API tokens from clients and forwards them unchanged to the downstream API. Besides weakening security controls, how does this token passthrough damage accountability and auditing?
Select an answer to reveal the explanation.
Short Explanation
Passing tokens straight through is like letting visitors wear each other's badges. The front desk (your server) can't tell who's who, and the back office (the downstream API) logs the wrong name on every visit. Good luck reconstructing an incident from that.
Full Explanation
The security best practices describe token passthrough as an anti-pattern in which an MCP server accepts tokens without validating that they were issued to it and forwards them to a downstream API; the authorization specification forbids it. Under accountability and audit trail issues, the guidance explains that the MCP server cannot identify or distinguish between clients when they call with an upstream-issued token that may be opaque to it, and the downstream resource server's logs may show requests that appear to come from a different source with a different identity rather than from the forwarding MCP server. Together these make incident investigation, controls and auditing much harder, and a stolen token can turn the server into an exfiltration proxy. Double logging per hop is not a described consequence and would not erase identity. The bearer token is not removed from the header; it is forwarded intact, which is the problem. tools/list may vary by the authorization presented but must not vary per connection, and passthrough has no defined effect on list caching. Exam caveat: the fix is for the server to accept only tokens issued for itself and to obtain its own separate token, as an OAuth client, for any upstream API. Operational check: confirm the server validates audience on every inbound token and that downstream logs show the MCP server's own client identity.