The blocker for Claude in most enterprises has not been the model. It has been the network. The interesting data lives inside a VPC, behind a corporate firewall, in databases that are not on the public internet and never will be. Until last week, the way to give Claude an MCP server inside that perimeter was to either reverse-proxy it through something public, build a thin shim service in front of it, or pull the data out into a Claude-reachable store and accept the duplication. None of those options are clean.
Claude MCP tunnels, announced on May 19, 2026 as part of a broader Claude Managed Agents update, change that. A lightweight gateway you deploy inside your network opens a single outbound connection to Anthropic's tunnel edge. Your agents reach internal MCP servers through that gateway. No inbound firewall rules, no public endpoints, no shimming. This article walks through what is actually happening on the wire, the IAM model, the companion self-hosted sandboxes feature, and the decisions you should be making before you wire any of it up.
What Claude MCP tunnels actually do
The Model Context Protocol gives Claude a typed interface to tools. An MCP server is whatever sits behind that interface. In production, that "whatever" is usually an internal database, a ticketing system, a knowledge base, a private API. Things you do not want exposed to the public internet.
Before MCP tunnels, the options for connecting Claude Managed Agents to private MCP servers ranged from inconvenient to dangerous. Public reverse proxies with API-key gating were workable but added an internet-facing attack surface for systems that had none. Pulling data out into a Claude-reachable mirror solved the access problem and created a sync problem. Building a bespoke gateway service worked but every team rebuilt the same gateway.
MCP tunnels replace the bespoke gateway with a managed one. You deploy a lightweight tunnel agent inside your private network. It opens an outbound, end-to-end encrypted connection to Anthropic's tunnel edge. Anthropic routes requests from your agents through that tunnel to your internal MCP server. The MCP server itself never gets a public endpoint and never accepts an inbound connection from the outside world.
The mental model is the same as cloudflared or ngrok for HTTP. It is, in fact, cloudflared underneath, which is worth knowing because the operational characteristics carry over: a process you run, a single outbound TLS connection, no inbound rules to manage.
The architecture in detail
The data path has three pieces.
A tunnel agent runs inside your network, typically as a container or sidecar. It opens an outbound-only connection to Anthropic's tunnel edge. Because the connection is outbound, no firewall changes are needed. The agent connects out, the tunnel stays open, and traffic flows over it in both directions on top of that connection.
A proxy sits between the tunnel agent and your MCP server, also inside your network. The proxy terminates inner TLS using a certificate you own and never share. It validates that the upstream IP for each request falls within an allowed range. It then routes the request to the correct MCP server based on the hostname.
Anthropic operates the tunnel edge. Requests from the agent loop hit the edge, the edge forwards them to the tunnel, the tunnel forwards them to your proxy, the proxy forwards them to your MCP server. Responses go back along the same path.
The piece worth dwelling on: Cloudflare carries the traffic but cannot read it. Anthropic explicitly says they do not connect to a tunnel until a CA certificate is registered, and the inner TLS terminates on your proxy with a certificate only you hold. The payload is encrypted end to end across the tunnel. Cloudflare moves bytes; it does not see them.
That is a meaningful guarantee. If you compare it to running a public MCP server behind an API key, the bytes were always plaintext to whatever load balancer you ran. MCP tunnels keep the data path encrypted between your proxy and Anthropic's infrastructure, not just on the wire.
The IAM model
Static API keys for service-to-service auth are a habit nobody has managed to fully break. MCP tunnels lean against that habit.
The tunnel supports Workload Identity Federation through OIDC identity providers. If your workloads already have identities (a Kubernetes service account, an AWS IAM role assumed via OIDC, a SPIFFE/SPIRE identity), the tunnel can accept those tokens and exchange them for tunnel access. Manual credentials are supported for testing, but the default path Anthropic is pushing is federated identity.
Why this matters: rotating a static key every 90 days is the kind of work that gets put off until an audit forces it. Federated tokens are short-lived by default and rotate automatically because the identity provider does the work. The number of long-lived secrets in your infrastructure goes down. The blast radius of any one compromise goes down with it.
There is a real operational change involved. If your existing setup is "we generated an API key and stuck it in a secret manager", moving to OIDC federation is a project, not a config flag. You need an identity provider, a trust relationship with the tunnel, and workloads that can request tokens. Teams with mature workload identity already have all of that. Teams without it will feel the gap.
The same identity discipline shows up in my piece on AI rebooking agents and the orchestration patterns airlines actually run in production. The agent is interesting; the auth around the agent is what keeps the whole thing out of trouble.
Self-hosted sandboxes: the companion feature
MCP tunnels did not ship alone. The same May 19 release also moved self-hosted sandboxes to public beta. The two features address adjacent problems.
A sandbox is where the agent's tool execution actually happens. By default, that runs on Anthropic's infrastructure. Self-hosted sandboxes let you move tool execution into an environment you control. The agent loop (orchestration, context management, error recovery) stays on Anthropic's infrastructure. The tool execution moves to your sandbox.
The combination matters. With both features on, the picture looks like this: orchestration on Anthropic's side, tools and data on your side, encrypted traffic between them. Your sensitive systems never sit in someone else's tenancy. Anthropic's orchestrator never gets direct access to your network; it gets a tunnel-mediated path to specific tools.
Anthropic supports four managed sandbox providers out of the box. Cloudflare runs microVMs with customizable proxies and zero-trust secret handling. Daytona offers full composable computers that are long-running and stateful, useful for agents that hold state across a session. Modal optimizes for sub-second startup and scales to hundreds of thousands of concurrent sandboxes, which is the shape you want for fan-out work. Vercel provides VM-level security with VPC peering and millisecond startup, which fits if your existing infrastructure already lives on Vercel.
The provider choice has real architecture consequences. Long-running stateful workloads on Modal's ephemeral model end badly. Fan-out fan-in workloads on Daytona's long-running model burn capacity unnecessarily. Match the provider to the workload shape. The same kind of fit-matters decision I walked through for building production-ready autonomous agents with LangChain shows up here, just with managed primitives instead of frameworks.
When you actually need this
Not every Claude integration needs a tunnel. A public MCP server fronted by API keys works fine for plenty of tools, and reaching for tunnels when you do not need them is overhead.
The cases where MCP tunnels earn their keep:
Internal-only data. Databases, knowledge bases, internal APIs that have no business being on the public internet. The cost of exposing them publicly is high enough that even a well-protected endpoint feels like a step backwards.
Regulated environments. Anywhere your security team has a strong opinion about inbound connections to systems carrying customer data. Even if a public proxy in front of the MCP server is technically secure, "we do not accept inbound connections" is a much shorter audit conversation than "we accept inbound connections, here is how they are filtered, here is the API-key rotation policy, here is the WAF config."
Existing private-network architecture. If your entire infrastructure already lives behind VPC peering and Workload Identity Federation, MCP tunnels match the topology you already have. Anything else would be an exception in your network model.
The cases where you do not need tunnels:
Public-data MCP servers. A weather API. A documentation lookup. A public ticket search. If the data is already public, paying tunnel overhead to keep it private is silly.
Prototypes. You are not yet sure the agent is valuable. Stand it up against a public-data MCP server first, prove the loop, then move data behind a tunnel when the project graduates.
Existing reverse-proxy investments. If you already run a hardened public gateway in front of internal APIs for other reasons, fronting an MCP server with the same gateway may be the lower-friction path. Tunnels are a clean architecture; clean architectures still take time to roll out.
Production considerations
A handful of things worth thinking about before tunnels touch a live system.
The gateway is a new single point of failure. The tunnel agent is a process that has to stay up. If it goes down, your Claude agents lose access to that MCP server. Run it like any other critical infra component: health checks, multiple replicas if the tunnel implementation supports it, alerting on the outbound connection state.
Observability is now split across two systems. The tunnel sees one half of the request; your MCP server sees the other half. Correlate them. The cleanest pattern is a request ID injected by the agent, propagated through the tunnel, and logged at both ends. Without that, debugging a "the agent says it called the tool but my MCP server saw nothing" issue gets painful.
The trust boundary moved but did not disappear. Anthropic's orchestrator now talks to your proxy. Your proxy now talks to your MCP server. Each of those hops is a place to enforce policy. Rate limits, allow-lists of tools, scoped credentials per tool. The tunnel does not absolve you of doing the per-tool authorization work; it just gives you a clean place to do it.
Treat tool definitions as code. The MCP server defines what tools the agent can call. Changes to that surface are changes to what Claude can do inside your network. Code-review them, version them, deploy them with the same care you would use for an external API.
Watch for cross-agent context leaks. If you also run the Dreaming feature I covered last week, memory consolidation across agent sessions means a finding from one session can land in shared memory and influence another session. With MCP tunnels in play, that finding may be tied to internal data. Sanitize at the session boundary, not the dream boundary, because by the time consolidation runs the data is already in the memory store.
Where this leaves you
Self-hosted sandboxes are in public beta. MCP tunnels are still research preview and gated by access request. Most teams reading this will be designing for the pattern now and running against the existing setup until access lands.
That is fine. The pattern is the part worth investing in. Workload Identity Federation for service-to-service auth. Outbound-only connections for any new integration with a third-party service. A clean separation between orchestration and tool execution. None of that is specific to Claude. All of it is the right shape regardless of which vendor you pick.
What changes with tunnels is that Anthropic is now offering this shape as a managed primitive rather than as a deployment guide you read once and then implement yourself. The same shift played out in my walkthrough of /goal and the new Claude Code agent view from earlier this week. The surface area developers manage by hand keeps shrinking. The interesting decisions move further up the stack: which agents to run, where they sit in the network, what tools they can call, who they answer to.
That last one is where MCP tunnels really matter. The model is impressive. The agent loop is impressive. The bit that decides whether enterprise teams can ship it is whether the integration matches the network and security posture they already have. With tunnels, the answer can finally be yes.