Why does token passthrough create so much risk in MCP integrations?

Why Token Passthrough Is So Dangerous in MCP Integrations

token passthrough looks convenient because it avoids an extra auth layer, but in MCP it often destroys the security boundary between the user, the MCP server, and every downstream tool the server can reach. Once a bearer token is forwarded without strong audience checks, the token can become a reusable credential in places the original caller never intended. That is especially risky in agentic workflows, where tool chaining and delegated execution can amplify a single mistake.

This is not a theoretical edge case. NHIMG research on the 2025 State of NHIs and Secrets in Cybersecurity found that 44% of NHI tokens are exposed in the wild, often through collaboration tools, tickets, or code commits. In other words, token handling failures are already common, and passthrough makes those failures more consequential. The underlying risk is also consistent with the OWASP Top 10 for Agentic Applications 2026, which treats improper delegation and authority confusion as core design problems. In practice, many security teams discover token reuse only after a downstream service has already accepted the wrong identity.

How Token Passthrough Breaks the Trust Model in Practice

MCP integrations typically sit between a caller and multiple tools, APIs, and data sources. In a well-designed flow, the MCP server should authenticate the caller, evaluate what the request is allowed to do, and then obtain credentials that are scoped to the downstream action. Token passthrough skips that separation. The server forwards the original token, so the downstream system sees a credential that may have been issued for a different audience, different policy domain, or different user context.

That creates several concrete problems:

• Audience confusion: the same token may be accepted by multiple services if audience restrictions are weak or absent.

• Audit ambiguity: logs may show a valid token but not clearly identify whether the human, agent, or server initiated the action.

• Overbroad delegation: the server inherits privileges it was never meant to exercise on behalf of the caller.

• Lateral movement risk: if the token is intercepted or replayed, it can be used against any downstream system that trusts it.

The safer pattern is to treat the MCP server as a policy-enforced intermediary, not a token relay. That means validating issuer, audience, token type, and expiry, then exchanging the caller context for a purpose-built downstream credential where appropriate. Current guidance suggests pairing short-lived credentials with runtime authorization rather than relying on static forwarding. Research such as the Guide to the Secret Sprawl Challenge reinforces the point that secrets spread fastest when convenience overrides governance. For implementation, the NIST Cybersecurity Framework 2.0 supports this by emphasizing controlled access and continuous governance, while the emerging OWASP Agentic AI Top 10 stresses runtime control over opaque delegation. These controls tend to break down when MCP servers are wired directly to enterprise SaaS APIs that accept broad bearer tokens because the trust boundary becomes implicit instead of enforced.

When Passthrough Might Seem Acceptable, and Why It Usually Is Not

Tighter delegation controls often increase integration complexity, requiring organisations to balance developer convenience against blast-radius reduction. That tradeoff is real, which is why token passthrough sometimes appears attractive in early prototypes, internal tooling, or tightly controlled lab environments. But best practice is evolving away from blanket passthrough because a “works in dev” shortcut becomes a long-lived production dependency.

There are a few edge cases where passthrough may be less dangerous, such as a single-hop integration with one tightly scoped backend that strictly enforces issuer and audience, but even then the model is fragile. The risk rises sharply when the MCP server brokers access across multiple SaaS platforms, when agents can chain tools autonomously, or when human and machine identities are mixed in the same token format. In those cases, the token is no longer just proof of access; it becomes a portable authority artifact.

Current guidance suggests replacing passthrough with explicit token exchange, per-tool scopes, short TTLs, and policy checks at the point of use. NHIMG coverage of the Salesloft OAuth token breach shows how quickly a valid token can become a cross-system compromise when trust is too broad. For MCP programs, the safer posture is simple: never let transport convenience override audience restriction, and never let a forwarded token become the system’s de facto authorisation model.

Related resources from NHI Mgmt Group

• Why do token reuse and refresh tokens create so much risk in SaaS integrations?
• Why do AI coding agents create a different token risk than normal automation?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?