Why do bearer tokens create risk in MCP if they are reused across systems?

Why This Matters for Security Teams

Bearer tokens are convenient because they let one component act on behalf of another, but that convenience becomes dangerous when the same token crosses multiple trust boundaries. In MCP, a token meant to authorize a single server session can quietly turn into reusable authority if it is forwarded to GitHub, a database, or an upstream API. That collapses delegation boundaries and makes incident response harder because the original scope is no longer visible.

This is not just a theory problem. NHIMG’s Salesloft OAuth token breach shows how portable tokens can be abused once they leave their intended boundary, and the Guide to the Secret Sprawl Challenge explains how credential reuse expands blast radius across systems. The security issue is not only token theft, but token replay in places the issuer never intended.

Current guidance from the OWASP Agentic AI Top 10 and the NIST Cybersecurity Framework 2.0 both push teams toward least privilege, but bearer tokens weaken that principle when they are treated as universal pass-through credentials. In practice, many teams discover the problem only after a token used for one service has already been replayed into several others.

How It Works in Practice

The safer model is to treat MCP tokens as narrow, bounded credentials rather than transferable session keys. A server should validate what the token can do, for which audience, and for how long, then stop there. If a downstream system needs access, the MCP server should exchange its own identity for a new, purpose-built credential instead of forwarding the original bearer token. That preserves delegation boundaries and makes each hop independently accountable.

Practitioners usually reduce risk through four controls:

• Bind tokens to a specific audience so they cannot be replayed against a different system.
• Use short TTLs and revoke tokens automatically when the MCP task ends.
• Exchange tokens at each boundary instead of forwarding the same secret downstream.
• Log every hop so investigators can reconstruct which component used which credential.

For agentic or automated workflows, this is especially important because the calling pattern is dynamic. An agent may chain tools in ways that were not predicted at design time, so static pass-through tokens can become de facto super-user credentials. NHIMG’s AI Agents: The New Attack Surface report highlights how often AI agents move beyond intended scope, and the OWASP Agentic Applications Top 10 reinforces the need for runtime authorization rather than assumptions about fixed paths. Where possible, use workload identity and policy checks at each hop, not just a single bearer token at the front door.

These controls tend to break down when legacy APIs only accept opaque bearer tokens and cannot mint downstream-scoped credentials, because teams then fall back to forwarding the same token across systems.

Common Variations and Edge Cases

Tighter token scoping often increases integration overhead, so organisations must balance security against how much protocol translation their stack can support. That tradeoff is especially sharp in mcp environment that sit between modern identity systems and older APIs that were never designed for delegation-aware access.

There is no universal standard for this yet, but current guidance suggests a few patterns. For trusted internal services, an access token may be acceptable if it is audience-bound, short-lived, and never exposed to the client layer. For cross-domain calls, token exchange is usually safer than forwarding. For highly sensitive actions, teams should prefer per-task credentials and explicit approval steps over long-lived bearer reuse.

Edge cases often appear in multi-tenant platforms, service meshes, and automation pipelines where one component legitimately needs to call another on behalf of a user or agent. In those environments, the real risk is confusion between authentication and authorization: a token may prove that a caller is valid, but not that it should be allowed to act everywhere the token can reach. NHIMG’s Guide to the Secret Sprawl Challenge and Salesloft OAuth token breach both show how quickly scope drift turns convenience into exposure. The pattern becomes especially fragile when downstream systems trust the token without re-checking audience, purpose, and session context.

Related resources from NHI Mgmt Group

• Why do bearer tokens create replay risk in distributed systems?
• When do MCP profiles reduce risk, and when do they create false confidence?
• Why do service accounts and API tokens create more risk when they are long-lived?
• Why do JWTs create risk when used as bearer tokens?