Avoid token passthrough in delegated integrations

Forwarding a user token through an MCP server to another service can give the wrong audience access, obscure responsibility and leak a reusable credential.

Preserve bounded delegation

The MCP contract lab compares inbound and downstream contexts.

from mcp_cases import token_passthrough_case

result = token_passthrough_case()
assert result["raw_token_forwarded"] is False
assert result["exchange_used"] is True
assert result["audience_bound"] is True
print(result["downstream"])

The downstream record references a service credential and bounded on-behalf-of context. These are synthetic strings; no token exchange occurs.

Bind credentials to purpose

Validate issuer, audience, expiry and scopes at each boundary. Use the platform’s approved token-exchange/on-behalf-of pattern or service identity plus explicit user authorization context. Minimize lifetime and downstream scopes.

Keep raw credentials out of prompts, tool descriptions, errors and logs. Do not let a model choose token audience or scopes.

Test misuse

Try replay, wrong audience, expired credentials, cross-tenant scope and service privilege beyond the user. Fail closed and audit identities without token values.

The Generative & Agentic AI course treats delegated authority as an integration contract, not prompt context.

Exercise

Model user→MCP service→downstream API identity. Implement five token validation failures and demonstrate no raw inbound token reaches downstream records.

Continue learning

This article is part of the MCP and integration contracts sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Apply least privilege to an AI tool catalogue.
• Continue with Version a tool contract without breaking callers.

Reference: OAuth 2.0 Token Exchange RFC 8693.