Why MCP Tunnels Could Be a Big Unlock for Enterprise Claude Adoption

Most enterprise AI projects do not stall because the model is too weak. They stall in the security review.

The pattern is easy to recognise. A team builds a strong pilot on Claude, the use case is obvious, the early numbers look good. Then the platform or security lead asks one plain question: how, exactly, does the vendor's cloud reach our internal systems? For the past two years the honest answer was uncomfortable. To let a hosted model use your tools through the Model Context Protocol (MCP), you usually had to expose those tools to the public internet. That meant opening an inbound firewall port, standing up a reverse proxy in a DMZ, and allowlisting a vendor's IP ranges. For a bank, a hospital, or a manufacturer with decades of data behind the firewall, that is where the conversation ends.

Anthropic's MCP tunnels remove that requirement. They are not a headline feature, and they will not trend on launch day. What they do is quieter and more useful: they fix the single most common reason enterprise Claude pilots never make it to production. The network.

The blocker was never the model

What makes enterprise AI valuable is also what makes it hard to wire up. The systems that matter sit inside private networks. Your order management system, your claims database, the MES on the factory floor, the knowledge base your support team lives in. None of them have a public endpoint, and that is by design.

MCP solved the interface problem well. It gave models a common way to discover and call tools, much as USB-C gave devices a common port. But a universal plug is no help if you cannot safely run a cable to the socket. A remote MCP server still had to be reachable from Anthropic's cloud, and “reachable from the public internet” is exactly the property your security team has spent years trying to remove. So the work got stuck. Not in the demo. In the review.

Where remote MCP runs out of road

It is worth being honest about the “before” picture. Connecting a hosted model to a private MCP server the conventional way forces a series of concessions that any competent security architect will push back on.

Every item on the left of that diagram is a real approval someone has to sign off: a new inbound rule, a publicly resolvable hostname, an IP allowlist that breaks the moment the vendor re-architects. Now multiply it by each tool you want Claude to reach. The integration cost quickly outweighs the cost of the model itself. The column on the right is what a tunnel offers instead, and the gap between them is not cosmetic. It is a different security posture.

What an MCP tunnel actually is

A tunnel lets Claude reach MCP servers inside your private network over a connection that only ever goes outbound. You do not open inbound ports. You do not put a service on the public internet. You do not allowlist Anthropic's IP ranges at your edge. That one decision is what makes everything after it acceptable to a security team.

The deployment is small. Two components run inside your network.

The first is cloudflared, the tunnel agent. It dials out to an Anthropic-operated tunnel edge and carries encrypted traffic. Because the connection is started from your side, outbound, on TCP/UDP port 7844, there is nothing on the public internet for an attacker to find or knock on.

The second is the proxy, Anthropic's routing component, which also runs on your side. It terminates the inner TLS connection, checks that upstream addresses fall inside an allowed range, and routes each request to the right internal server by hostname. Every server you expose gets a name under your tunnel domain, something like docs.<your-tunnel-domain>. You attach those names to a Managed Agent session in the Console, or pass them to the Messages API through the MCP connector.

The mental model is worth stating plainly: traffic flows in, but the connection reaches out. Your network establishes the link, on your terms, using infrastructure you run. For the developer, calling a tunneled server looks like calling any other remote MCP server. Only the URL changes.

mcp_servers: [ { type: 'url', url: 'https://docs.YOUR_TUNNEL_DOMAIN/mcp', name: 'docs' } ]

The hard part, the secure path into your network, is handled underneath. The day-to-day experience stays the same as the public connector your team already knows.

Why this is the unlock: a security model that survives review

Outbound-only connectivity is necessary, but on its own it is not enough. What makes tunnels genuinely enterprise-grade is that three separate layers protect every request. No single failure hands an attacker your data or your tools.

The layer that tends to win the room is the middle one. The transport runs on Cloudflare's network, but the proxy terminates the inner TLS session with a certificate that only you hold. Cloudflare cannot read your requests or responses. In fact, Anthropic will not connect to a tunnel at all until you have registered a CA certificate, so there is no setup in which your payloads cross the transport in the clear. Cloudflare sees connection metadata, the egress IP, a host fingerprint, timing and byte volume, and the subdomain assigned to your tunnel, and it acts as a subprocessor for this preview. It does not see the contents.

Two more points matter when compliance is in the room. Tunneled deployments can qualify for Zero Data Retention and for HIPAA BAA coverage. And the responsibilities are written down rather than assumed. Anthropic handles tunnel access control, validates your CA certificate before connecting, and makes sure Claude only sends requests to tunnels your organisation owns. You handle what only you can: protecting tunnel tokens and TLS private keys, renewing certificates, putting OAuth on each server, and limiting what the proxy and the servers behind it can reach.

One caveat belongs in any honest write-up. If an attacker gets hold of both your tunnel token and one of your TLS private keys, they could impersonate your proxy and read traffic. Treat both as top-tier secrets. That is not a weakness in the design. It is the same key-custody discipline you already apply to your most sensitive systems.

What changes once the network objection disappears

Step back from the packets and the shift is strategic. The conversation moves from “are we even allowed to do this” to “which use case goes first.” Three things tend to follow.

The security review gets shorter. “No inbound ports, nothing on the public internet, payloads encrypted with our own keys” is something an architect can reason about in an afternoon, not a quarter. You are working inside policy instead of asking for an exception to it.

Regulated data comes back on the table. The systems that were off-limits to hosted AI, which are usually the high-value ones, become candidates again. A claims system, a pricing engine, a shop-floor historian. That is where most of the real productivity sits.

Each new integration costs less than the last. Once the pattern is repeatable and pre-approved, the second and the tenth tool you connect take a fraction of the effort of the first. Adoption starts to compound instead of restarting the review every time.

A practical path for teams evaluating tunnels

If you are weighing this up, a few recommendations from the field.

Prove it locally, then move to Helm. Start with the Docker Compose quickstart and a sample server before you touch anything in production. For real Kubernetes deployments, use the Helm chart. Keep Docker Compose for a single host or for testing.

Prefer Workload Identity Federation over static credentials. If you already run an OIDC identity provider, whether that is a Kubernetes cluster, cloud IAM, or SPIFFE, let your stack mint short-lived tokens and register certificates automatically. Manual tokens and hand-managed certificates are fine for a pilot. Programmatic access is the production answer.

Put OAuth on every server, no exceptions. The tunnel carries encrypted traffic to your server but it does not authenticate to it. Authentication at the server is the independent layer that stops a compromised tunnel from becoming a compromised toolset. Do not skip it just because the network already feels private.

Guard the secrets like crown jewels. Vault your tunnel tokens and TLS keys, rotate them, scope what the proxy and the servers can reach, and write down a breach-response plan before you need one.

Plan around the beta. MCP tunnels are a research preview today, offered as-is, with no uptime or support commitment, and they depend on a third-party transport provider. They are also not yet available as connectors in claude.ai; you reach them from Managed Agents and the Messages API. So pilot the high-value but non-critical workflows first, and design for graceful failure.

Where this leaves you

For most enterprises the question was never whether Claude is capable enough. It was whether the data and tools that make it useful could be reached without cutting a hole in the network. MCP gave agents a common way to use tools. Tunnels give you a safe way to connect those tools without rewriting your security posture. Together they remove the objection that quietly kills more pilots than any model limitation does.

An agent that can read your order system, reconcile against your ERP, and act inside your private network, without a single inbound port, is worth more than a cleverer model that can only see the public web. That is usually the part that decides whether an AI initiative ships. It rarely makes the headline. It is almost always where the value is.