How should security teams handle SSRF risk in MCP servers?

Why This Matters for Security Teams

SSRF in an MCP server is not just a web application bug. It is an identity and routing failure that can let a tool call reach internal services, cloud metadata endpoints, or other control planes the server was never meant to touch. That matters because MCP often sits between an AI-driven workflow and sensitive back-end systems, so one missed allowlist decision can become a broad trust break.

Security teams should treat this as an egress control problem with identity context, not only as input sanitisation. The OWASP Agentic AI Top 10 aligns with this risk shift: the dangerous step is often the server making a request on behalf of a higher-trust workflow. NHIMG research on OWASP NHI Top 10 also shows how quickly a weak trust boundary becomes a credential and access issue, not merely a malformed URL issue.

In practice, many security teams encounter SSRF only after an MCP tool has already probed internal hosts or touched metadata endpoints, rather than through intentional testing of outbound trust boundaries.

How It Works in Practice

The safe pattern is to validate where the MCP server is allowed to connect, then enforce that decision at the network and runtime layers. URL parsing alone is not enough because attackers can exploit DNS rebinding, redirect chains, alternate IP literals, and proxy behaviour to change the effective destination after the initial check. The decision needs to happen on the resolved destination, not only on the string the client supplied.

Practical controls usually include:

• Resolving DNS first, then checking the final IP against private, loopback, link-local, multicast, and reserved ranges.
• Re-validating every redirect hop, including scheme changes and host changes.
• Blocking direct access to cloud metadata services and internal control planes at the network layer, even if application validation fails.
• Restricting outbound traffic to explicit destinations or service classes whenever the tool has a narrow use case.
• Logging destination, resolution result, redirect chain, and caller identity for each request.

This lines up with the broader guidance in NIST Cybersecurity Framework 2.0, which treats protective technology and logging as complementary, and with NHIMG’s Top 10 NHI Issues, where over-permissioned machine identities and weak service boundaries repeatedly amplify small logic errors into platform-wide exposure.

For MCP specifically, the server should run with a tightly scoped workload identity and a network policy that denies all egress by default. If a tool truly needs external fetches, current guidance suggests using a brokered fetch service or an egress proxy that applies policy, not giving the MCP server unconstrained internet access. These controls tend to break down when the server sits behind permissive outbound proxies or shared NAT gateways because destination enforcement becomes invisible at the point of decision.

Common Variations and Edge Cases

Tighter egress control often increases engineering overhead, requiring organisations to balance developer convenience against the need to stop hidden outbound paths. That tradeoff becomes sharper when MCP servers must fetch documentation, call SaaS APIs, or follow user-supplied links as part of normal workflows.

There is no universal standard for this yet, but best practice is evolving toward layered trust checks rather than a single URL filter. For example, a documentation-fetching tool may be allowed to reach a narrow set of vendor hosts, while a general-purpose tool should be forced through a controlled retrieval gateway. Redirect handling is especially important because a benign first hop can still lead to an internal address later in the chain.

Teams should also account for non-obvious failure modes such as IPv6 representations, DNS caching, split-horizon DNS, and service meshes that rewrite destinations after application validation. If the MCP server can reach a metadata endpoint through any path, the application layer alone is not enough. The real objective is to ensure that a validation miss cannot become a reachable internal request, even when the server behaves unexpectedly.

NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now is useful context here: machine identities often fail where access assumptions are too broad and too static. In MCP environments, that usually means the safest design is deny by default, allow by exception, and verify at every boundary.

Related resources from NHI Mgmt Group

• How do security teams know if AI-assisted reverse engineering is becoming a risk in their environment?
• How should teams log MCP server activity for security investigations?
• How do security teams reduce risk from AI-assisted exploit research?
• What are the risks of using static credentials in MCP servers?