Every serious use of the Model Context Protocol runs into the same wall, and it is a literal one. Your most valuable tools — the production database, the internal ticketing system, the knowledge base — live inside your network on purpose. A hosted agent like Claude lives outside it, on Anthropic's infrastructure. MCP tells the two how to talk, but it says nothing about how a request crosses the firewall between them. For a year the only answers were bad: deploy your internal tool to a public URL and inherit the entire attack surface of the open internet, or don't use a hosted agent with private data at all.
Anthropic's MCP tunnels, announced at Code with Claude London on May 19, 2026 and shipping in research preview, are the third answer. And the interesting thing about them is not that they are encrypted. It's the direction they point.
The trick is which way the connection is dialed#
A tunnel works by inverting who initiates the connection. Instead of Claude reaching in to your network — which would require you to open an inbound port and let the outside dial you — a small gateway inside your perimeter dials out to Anthropic and holds that connection open. Every request to your internal MCP server then travels back down a channel your side opened. No inbound firewall rule. Nothing published to the public internet. You don't even allowlist Anthropic's IP ranges on your origin, because your origin never accepts an inbound connection at all.
This is the load-bearing insight, and it is older than agents: the security primitive is the direction of initiation, not the cryptography. A firewall's whole job is to refuse unsolicited inbound connections while permitting outbound ones, so a connection your side started is one your existing policy already trusts. It is the same move as ngrok, as Tailscale Funnel, as ssh -R, as Cloudflare Tunnel — and Anthropic doesn't pretend otherwise. The stack is literally built on cloudflared, Cloudflare's open-source connector, paired with a routing proxy you run yourself. It is reverse-tunnel-as-a-service wearing an MCP badge, and that lineage is a compliment: the pattern is proven.
A firewall refuses the connection it didn't ask for. A tunnel just makes sure your side is the one asking.
The design also takes the obvious next question — can the tunnel provider read my data? — seriously. Traffic rides three independent layers: a mutual-TLS session out to the tunnel edge, an inner TLS session that terminates at the proxy you host using a certificate only you hold, and OAuth on each individual MCP server. Cloudflare moves the bytes but cannot decrypt the MCP payloads, because the key that would let it lives inside your perimeter. Someone thought hard about not trusting the middle of the pipe. This connects to the same discipline the spec pushed with audience-bound tokens for remote servers: assume the transport is hostile and bind trust to the endpoints.
What the tunnel does not fix#
Here is the part the launch framing skips. An outbound tunnel eliminates network exposure. It does not shrink the blast radius.
Think about what you have actually built: a persistent, authenticated, always-on path from a third-party language model straight into your internal systems. The firewall is now irrelevant to the threat that matters, because the tunnel is supposed to carry Claude's traffic. If a prompt-injected model decides to enumerate your customer table and hand it to an attacker, it is not breaching the tunnel — it is using the tunnel exactly as designed. This is precisely the confused-deputy problem: a trusted component, holding real authority, acting on instructions it did not originate. Three TLS layers protect the channel. Nothing in the tunnel protects against the authorized user of the channel being manipulated, and the authorized user is a model that a paragraph of adversarial text can steer.
So read the feature for what it is. Against network-level threats — an exposed port, a scan, an unsolicited inbound connection — a tunnel is a real and elegant improvement, and it is the honest way to let a hosted agent touch private data. Against the threat that actually characterizes agents — a confusable model with legitimate credentials — it is a no-op, and arguably a mild regression, because it makes reaching your crown jewels more convenient without making the reach safer.
The move that does help is the unglamorous one the tunnel can't do for you: narrow what each internal MCP server is allowed to do, scope every tool to the least authority it needs, and never expose a "run arbitrary query" tool just because the transport finally made it easy. MCP tunnels solved the boundary. The transport story that got us here — local stdio to remote HTTP and now back through a private pipe — was never the hard problem. The hard problem is standing on the other end of a very well-encrypted wire, holding your credentials, and deciding what a stranger's instructions are worth.
