Why Claude MCP Tunnel Matters

May 26, 2026

Introducing Claude MCP Tunnel

In May 2026, Anthropic introduced two new enterprise capabilities for Claude Managed Agents:

Self-hosted sandboxes (public beta)
MCP tunnels (research preview)

Claude MCP Tunnel solves one of the hardest and most important problems in enterprise agentic AI: how a cloud-hosted AI agent can safely use private enterprise resources (tools, APIs, databases) without requiring inbound firewall exposure, public MCP servers, or brittle IP allowlists.

The moment an enterprise AI agent needs to act on real data, not just reason about it, the agent must reach inside the corporate perimeter, and every traditional method for doing that either creates an unacceptable security hole or requires so much IT overhead that AI projects stall before they ever reach production. And the urgency is only accelerating: adversaries are now weaponizing AI to scan, probe, and exploit exposed attack surfaces in hours rather than weeks, collapsing the window between vulnerability disclosure and active breach to the point where any externally reachable endpoint is essentially a ticking clock.

Claude MCP Tunnels enable zero trust connections between Anthropic and MCP servers inside the enterprise’s network – without the enterprise exposing their perimeter. Claude Managed Agents and the Messages API can access enterprise resources without the enterprise exposing those resources to the Internet.

This actually is not completely new. The pattern started pre-AI so that enterprises could avoid exposing public endpoints or nailing up S2S VPNs when their vendors need inbound access to their enterprise network. Examples:

ServiceNow MID and SAP Cloud Connector are deployed in their enterprise customers’ networks to open outbound towards ServiceNow and SAP.
NetFoundry democratized this with its Customer Connect architecture, enabling any provider to solve the problem without the provider needing to build a solution (like ServiceNow and SAP had to).

Claude MCP Tunnel mirrors these solutions – software runs inside the customer network and establishes a single outbound, encrypted connection to Anthropic. The enterprise MCP server’s address is never published to the public internet.

Claude MCP Tunnel – Why Now?

Enterprises are now moving from copilots and coding assistants to agents. The agent needs tools to do their jobs which means two things:

The agent needs a standard interface to the tools – hence the birth of MCP
The agent need connectivity to the tools but they live behind firewalls and in private VPCs and VNets – hence this zero trust MCP tunnel architecture..

Both of these enable agents to be realistic to deploy to production – they help operations manage the agents and resources, while providing visibility, controls and governance. That’s why the outbound-only, identity-bound, no perimeter exposure pattern is becoming the default way agentic platforms reach data inside an enterprise.

Operations impact of Claude MCP Tunnel

The zero trust tunnel architecture helps operations, but it is not a panacea.

What Claude Tunnel Makes Easier

One firewall rule per tunnel target, outbound only. The perimeter management job shrinks from approving inbound rules per MCP server to approving a single outbound TLS connection per LLM provider. Many enterprises already allow outbound TLS to *.anthropic.com and *.openai.com generally, which makes this rule a no-op.
No public DNS, no NAT, no DMZ hardening overhead for the MCP server fleet. The MCP servers can live on the same internal network as the data they wrap, behind whatever access controls already protect those systems.
No coupling to LLM-provider egress IP ranges. Reverse-proxy and ACL-based patterns break every time the provider rotates IPs. Tunnels don’t.
Simplification. Single point to apply egress data-loss-prevention (DLP) inspection on the gateway, before traffic leaves the perimeter.
Per-call observability. Because all agent-to-MCP traffic flows through a known gateway, the enterprise gets clean logs at the gateway.

What Claude Tunnel Adds to the Operations Plate, or Doesn’t Address

Gateway lifecycle. The gateway is now a piece of infrastructure the enterprise has to deploy, patch, upgrade, monitor, and certify.
Certificate and identity lifecycle. Gateway authentication adds another device to the rotation, revocation, and incident response. A leaked gateway credential can expose many MCP servers.
Capacity planning at the gateway. A single tunnel multiplexes potentially thousands of MCP calls per agent session. Tunnel client and gateway must be sized for peak agent concurrency.
Multiple LLM and SaaS providers. Claude Tunnel doesn’t secure connectivity required by other LLM or SaaS providers so operations may still need to expose public endpoints or manage VPNs.

What Should be in Place Around the Tunnel

The tunnel solves the network-reach problem. It does not, by itself, solve any of the following:

Identity. Who is the agent acting as? Is delegated human identity ok? Can the enterprise IdP integration be done in a simple manner?
Authorization. On each tool invocation, the MCP server should still check whether the calling identity is allowed to use that tool with those arguments in an auditable and viable manner.
Secret and credential management. The MCP servers themselves typically hold credentials for downstream systems (CRM, ERP, EHR). Those credentials should be in a secrets manager, short-lived, and rotated. Ideally, the MCP Server or MCP Gateway enables the agents to never have access to those credentials.
Audit and SIEM integration. Tunnel events, MCP-call logs, and authorization decisions all need to land in the SIEM with consistent correlation IDs so an incident responder can replay an agent session end-to-end.

Security and Compliance Impact of Claude Tunnel

What it Makes Better

No public exposure of MCP servers. The single largest attack-surface reduction the architecture delivers. The enterprise never publishes the MCP server’s hostname or IP to the internet, so the scanner population that drives most opportunistic exploitation traffic can’t see it.
No inbound firewall holes. Eliminates the class of pre-auth-RCE-in-edge-appliance breaches that produced Fortinet, Citrix Netscaler, Ivanti, and SonicWall incidents over the past three years.
Strong, identity-bound transport. The tunnel typically presents a client X.509 to the provider control plane and another to the MCP server — mTLS at both ends, which is what most regulatory frameworks (PCI-DSS 4.0.1 control 4.2, FFIEC authentication guidance, HHS HIPAA Security Rule §164.312) now prefer for system-to-system auth.
Outbound DLP inspection point. Because all agent-to-MCP traffic flows through the gateway, the enterprise has a deterministic place to put data-loss-prevention controls on what the agent is allowed to send out (or pull in). This is impossible when the LLM provider reaches MCP servers via public DNS.
Smaller blast radius. If the LLM provider’s environment is compromised, the attacker can call MCP servers the agent was authorized to call — they cannot pivot to anything else on the enterprise network, because there is no inbound network path. Network-reachability is bounded by tunnel grant, not by L3 routing.

What Claude Tunnel Doesn’t Address

Prompt injection is unchanged. A tool call invoked by an injected prompt still goes through the tunnel exactly like a legitimate one. The tunnel is at the wrong layer to detect or block this — the detection has to happen at the agent loop and at the MCP server’s authorization layer.
Over-broad tool authorization is unchanged. If the MCP server lets the agent call any row in the CRM and the authorization is ‘agent service account has full read’, a compromised agent leaks everything the service account can see. The tunnel reduced the inbound attack surface but did not constrain the agent’s blast radius once it is inside.
Multiple LLM and SaaS providers. Attackers find the weakest point. Claude Tunnel doesn’t secure connectivity required by other LLM or SaaS providers.
Data residency and sovereignty. The tunnel pattern moves the conversation about where the data lives. The MCP server stays on-prem, but the model and the prompt context don’t. This may be ok for some enterprises and not for others.
Insider misuse or insider attacks. A tunnel doesn’t tell you whether a user invoking an agent is doing so for a legitimate business purpose.

Summary

Claude MCP Tunnel is important because it helps solve one of the most important problems in AI when the context is an enterprise deploying agentic AI. Meaning this helps shine a light on the next era of enterprise AI adoption – beyond chatbots and the simplest code assistants.

Claude MCP Tunnels show how a cloud-hosted AI agent can safely use private enterprise resources without creating operational and security headaches for the enterprise – without requiring inbound firewall exposure, public MCP servers, VPNs or brittle IP allowlists. Anthropic is quite busy with many customer requests – this shows the importance of this zero trust security model.

Every other LLM provider, every traditional SaaS adding agentic features, and every AI-native company selling into enterprise will be measured against this bar. The ones that provide a solution or help integrate into an enterprise-deployed MCP gateway (across all their providers) will close enterprise deals faster. The ones that will try to argue that their reverse proxy and IP allow-list are ‘good enough’ will often not win the deal.

For the enterprise reading this post: Claude MCP Tunnel is a great solution for Claude. Use it. At the same time, evaluate LLM model independent MCP gateways which use the same zero trust principles so you can apply it to all LLM providers, AI-enabled SaaS and AI native applications. And if you’re interested in removing the same firewall exposure that’s associated with your non-AI attack surface, such as other APIs and site-to-site connections, the team and I at NetFoundry would welcome the opportunity to share how 5,000 organizations use NetFoundry to do this across numerous different use cases.