01 / The operating case
What changes in a real workflow?
An MCP server receives a client token for its own resource, then passes that bearer token to a payment API.
- 01Client / task
- 02MCP server
- 03Tool call + arguments
- 04Downstream effect
02 / Decision contract
What the executor must check
Validate the incoming token for the MCP resource; use a separately authorized downstream credential or delegation flow with the payment API as audience.
03 / Failure and evidence
What goes wrong, and what can be proven?
The downstream API mistakes transport access to the server for permission to make payments.
Trace incoming audience, downstream credential source, payment decision and effect without storing either token.
04 / Canonical scope
Why this reference stands alone
Audience validation checks receipt at a server; this page follows the improper forwarding path beyond it.
Protocol or attack trace
Two-audience check
Client token has audience MCP-server. Server uses it as Authorization header for billing-API.
Billing API must reject the MCP audience; server must obtain separate billing-scoped authority before a charge.
Primary references