A token should be accepted only by its intended resource and must not become portable authority across an agent workflow.
Why this question matters
The MCP authorization specification requires servers to validate token audience and prohibits accepting or transiting tokens meant for other resources. This prevents a server from turning a credential it received into authority at a downstream system that applies different policy.
Agentic workflows make passthrough tempting because it appears to preserve user context. In reality it hides which service exercised authority, makes least privilege harder, and lets a compromised intermediary replay the token elsewhere.
Signals worth observing
- Identical access tokens appear in logs for multiple resource servers.
- An MCP server cannot name the authorization server for its upstream call.
- Downstream APIs attribute actions directly to the user instead of the agent service.
Practical control direction
- Validate the resource audience on every inbound request.
- Exchange or obtain a separate upstream credential.
- Carry principal and task provenance as bounded metadata, not bearer authority.
AgentCollusion lensDistinct credentials make it possible to identify which agent exercised each portion of a joint plan.Sources and further reading
Next field note: Resource Indicators Bound Agent Credentials
