MCP SSRF and token passthrough expose hidden trust boundary failures

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Bishop Fox's blog post: SSRF and token passthrough in MCP servers let unsafe outbound requests and credential forwarding break trust boundaries.

Why it matters: It matters because IAM, NHI, and platform teams need to treat MCP servers as security boundaries, not just integration glue, when they handle credentials and outbound access.

Context

MCP servers often accept user- or system-supplied URLs and credentials, then make outbound requests on the caller's behalf. In that pattern, the security problem is not the protocol itself but the absence of strong destination validation and audience checks at the point where trust is transferred.

For identity governance, this is an NHI problem as much as an application security problem. MCP servers can expose service credentials, cloud metadata access, and downstream API authority in ways that bypass the intended boundary between the caller, the server, and the target service.

The article uses recent disclosures to show that this failure mode is not theoretical. When content retrieval and API calling are core MCP functions, weak validation can turn ordinary tool use into access to internal services and privileged data.

Key questions

Q: What breaks when localhost redirect URIs are used for MCP clients?

A: Localhost flows can still be intercepted if another process can claim the callback path or reuse the expected port pattern. That means the browser approval step may complete against a malicious listener instead of the intended client. Teams should treat localhost callbacks as a weaker trust pattern and require explicit consent plus stronger attestation where possible.

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

A: Because it erases the audience boundary that keeps one credential from being reusable everywhere. When an MCP server forwards a caller token without validation, downstream systems may accept access that was never meant for them, and audit trails become ambiguous about who actually authorised the action.

Q: How should security teams handle SSRF risk in MCP servers?

A: Treat SSRF in MCP as an outbound identity control problem, not only an input validation problem. Validate destinations after DNS resolution, block private and reserved ranges, and re-check every redirect hop. Then segment the service so a validation miss cannot reach metadata endpoints or internal systems.

Q: When should teams allow credential forwarding from an MCP server?

A: Only when the receiving service explicitly expects and validates that exact token format and the integration has been narrowly approved. In most cases, forwarding should be avoided because it breaks audience boundaries and creates unnecessary trust coupling between services. The default posture should be token exchange or server-owned authentication, not passthrough.

Technical breakdown

How SSRF works in MCP servers

Server-side request forgery in MCP appears when a tool accepts a URL or redirect target and the server then performs the request from its own network position. That shifts the trust decision from the caller to the server, which may have access to cloud metadata, internal admin panels, localhost services, or segmented networks. In the article's examples, missing destination validation allowed attacker-controlled inputs to redirect outbound requests to unintended targets. The key mechanism is not exotic exploitation but the server acting as a high-trust proxy for arbitrary destinations.

Practical implication: Validate destinations after DNS resolution and after each redirect hop, then block private and reserved ranges.

Why token passthrough breaks the audience boundary

Token passthrough occurs when an MCP server forwards a caller's token to a downstream API without checking whether that token was issued for that audience. OAuth and related federation patterns assume a token is scoped to a specific relying party, so forwarding it unchanged creates a confused deputy problem. The downstream service may accept the token even though the user never intended that credential to authorize access there. The result is control circumvention, weak auditability, and a broken accountability trail across services.

Practical implication: Use the server's own service credential or exchange the token for a scoped downstream token instead of forwarding it unchanged.

Why MCP capability design widens the attack surface

MCP often combines content retrieval and downstream API access inside the same server, which means the server holds both network reach and credential handling logic. That pairing makes SSRF and token forwarding especially dangerous because one flaw can expose both data and authority. The article shows how a single mishandled URL can lead to file disclosure, cloud credential exposure, or later-stage compromise when those credentials are reused. The architectural issue is that the control plane and data retrieval plane are too closely coupled for trust-sensitive workloads.

Practical implication: Separate outbound-fetch functionality from privileged network segments and keep forwardable credentials out of generic retrieval tools.

Threat narrative

Attacker objective: The attacker aims to turn an ordinary MCP integration into access to internal systems, cloud credentials, and, in some cases, remote code execution.

1. Entry occurs when an attacker supplies a malicious URL, redirect target, or header value to an MCP server that fails destination validation.
2. Credential access follows when the server reaches metadata services, local files, or downstream APIs and exposes cloud credentials, SSH keys, or other secrets.
3. Escalation and impact occur when those credentials are reused to access internal services, pivot inside a cloud account, or chain into remote code execution and broader compromise.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSRF in MCP is a trust-boundary failure, not a novel exploit class. The underlying flaw is the assumption that a server can safely fetch whatever URL a caller supplies. In MCP, that assumption collapses because the server itself often sits closer to internal services and credentials than the caller ever should. The practitioner conclusion is that destination trust must be treated as a security decision, not a convenience feature.

Token passthrough creates a confused deputy risk that IAM teams should recognise immediately. The caller's token was issued for a specific audience, but the MCP server can forward it into a different trust domain if no audience validation exists. That breaks the accountability model behind federated access and makes downstream audit trails misleading. The practitioner conclusion is that forwarding credentials without audience checks is a governance failure, not a transport detail.

Audience validation and destination validation are now first-order controls for MCP governance. Old web patterns are being repackaged inside agent-facing infrastructure, which means traditional assumptions about trusted integrations no longer hold. MCP tooling can simultaneously expose data, carry identity, and cross network boundaries, so security teams need to classify it as privileged integration infrastructure. The practitioner conclusion is to govern MCP servers like access brokers, not like ordinary application endpoints.

Hidden trust boundary failures are the real issue here. The article shows that many implementations treat internal destination choice and credential forwarding as implementation details, when they are actually security boundaries. Once those boundaries are implicit, developers make unsafe defaults look normal. The practitioner conclusion is to surface every implicit trust transfer in design reviews and identity controls.

Reusable trust assumptions are now the named risk. MCP makes it easy to reuse old integration patterns in new contexts, but the security model does not automatically travel with them. A URL fetcher, a token forwarder, and a content converter can each look harmless alone, yet together they create a path from input control to privileged access. The practitioner conclusion is to review MCP capabilities as chained trust transfers, not isolated features.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Hidden trust boundaries now deserve the same scrutiny as exposed APIs. MCP servers can look like simple glue code while silently combining outbound network reach, file access, and credential handling. Programme owners should map every place where a server can both fetch content and forward identity, because that combination creates a high-value control gap.

Destination validation is becoming an identity control, not just an input-control problem. When a server can reach metadata services or internal hosts, a bad URL turns into privileged access pathing. Teams should treat outbound destination checks as part of NHI governance and cloud segmentation, not as a minor application hardening task.

For practitioners

• Enforce destination allowlists Resolve targets after DNS, check the resulting IPs against private and reserved ranges, and reject requests that resolve to internal or localhost addresses.
• Remove token passthrough by default Give MCP servers their own service credentials or exchange caller tokens for scoped downstream tokens instead of forwarding the original credential.
• Isolate retrieval tools from internal network reach Run fetch-capable MCP services in network segments or containers that cannot reach metadata services, admin panels, or other internal endpoints.
• Audit audience validation at every handoff Check that every forwarded or exchanged token is validated for the exact downstream service that receives it, especially where multiple integrations share one server.
• Treat MCP servers as privileged integration points Review each tool for the trust it can cross, the data it can expose, and the identity it can forward before allowing it into production.

Key takeaways

• MCP SSRF and token passthrough show how ordinary integration features can become privilege transfer points when trust checks are missing.
• The article's cases demonstrate that unvalidated destinations can expose cloud credentials, local files, and internal services before defenders notice the boundary has been crossed.
• The practical lesson is to validate outbound destinations, eliminate default token forwarding, and constrain where MCP servers can reach by network design.

Key terms

• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• Token Passthrough: Token passthrough is the practice of forwarding an authentication token through intermediaries instead of validating it at each trust boundary. In MCP this is prohibited because it prevents the server from proving who is actually authorised to act. The result is weaker accountability and a larger attack surface for stolen or replayed credentials.
• Audience Validation: Audience validation checks that a token was issued for the exact service receiving it. In MCP, this prevents a valid token for one server from being reused elsewhere, which is critical because agent-driven workflows often move across multiple tools and trust domains.
• Origin Allowlist: An origin allowlist is a controlled list of trusted website origins that are permitted to access a resource. It is safer than wildcard approval because it ties browser access to specific, known application hosts, which is essential when credentials or sensitive data are involved.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.