PROOFGRID
Request a Demo

Avoid MCP token passthrough

An MCP server must not forward a token issued for itself to a downstream API as if its audience covered that API.

01 / The operating case

What changes in a real workflow?

A server receives an MCP token and sends it directly to a cloud billing API.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Use a separate downstream credential or authorized token exchange with billing audience and bounded operation; validate both trust boundaries independently.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

The cloud API accepts a token whose intended recipient was the MCP server.

Evidence to retain

Correlate incoming audience, downstream credential source, decision and billing effect without recording bearer material.

04 / Canonical scope

Why this reference stands alone

Token audience validation covers receipt; this guide owns the outbound token boundary.

Illustrative implementation artifact

Two-audience token flow

client --token(aud=MCP server)--> MCP server
server validates aud=MCP server
server --separate token(aud=downstream API)--> API
API validates own audience and action scope

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation