Anthropic has quietly shipped two new infrastructure features for Claude agents: MCP tunnels and self-hosted sandboxes. Neither is about making Claude smarter. Both are about making it safe to deploy inside a real enterprise security perimeter.
They solve different problems. You might need one, the other, or both.
What actually changed
MCP tunnels let Claude connect to MCP servers running in your private network — without opening inbound firewall ports or exposing services to the public internet.
The mechanism is an outbound-only connection (via Cloudflare as the transport layer) that carries three independent layers of encryption: mutual TLS between Anthropic and the tunnel edge, inner TLS between Anthropic's backend and your proxy, and OAuth authentication on each individual MCP server. Crucially, Cloudflare can see connection metadata — timing, byte volume, your subdomain — but cannot read MCP request or response payloads because the proxy terminates inner TLS using a certificate only you hold.
Each private MCP server you expose gets a hostname under your tunnel domain (e.g. docs.<your-tunnel-domain>). You attach those hostnames to Managed Agent sessions in the Console or pass them to the Messages API via the MCP connector.
"Traffic flows over an outbound-only connection, so you don't need to open inbound firewall ports, expose services to the public internet, or allowlist Anthropic's IP ranges on your origin." — Anthropic docs
Self-hosted sandboxes solve a separate problem: where the agent's code actually runs. By default, Claude Managed Agents execute tools inside Anthropic-managed cloud containers. Self-hosted sandboxes move tool execution into infrastructure you control — but keep the orchestration on Anthropic's side. The agent's code, filesystem, and network egress never leave your environment.
The architecture is a small "environment worker" process you run on your own infrastructure. It polls a work queue maintained by Anthropic, claims sessions, downloads agent skills, executes tool calls locally, and posts results back. Pre-built workers exist for Cloudflare, Daytona, Modal, and Vercel. The CLI and SDK include helpers for both always-on pollers and webhook-triggered architectures.
The design distinction worth understanding
These are independent controls:
- MCP tunnels govern how Anthropic reaches your MCP servers — private network access without open ports
- Self-hosted sandboxes govern where the agent's tools execute — your compute, not Anthropic's containers
A cloud-hosted agent session can use tunnels to reach private MCP servers. A self-hosted session can use either tunnelled or public MCP servers. Use both when you need execution and tool access to stay inside your boundary.
The target audience is obvious: regulated industries (finance, healthcare, government) where data residency, network isolation, and audit controls are non-negotiable — and where "we run your agent in our cloud" simply won't fly with infosec.
What to do
- Running MCP servers on private infrastructure? MCP tunnels are the clean answer. No VPN, no IP allowlisting, no exposed ports. Request Research Preview access via Anthropic's form.
- Building on Claude Managed Agents? If your use case has data-residency requirements or needs access to services that aren't publicly routable, self-hosted sandboxes are now an option.
-
On the Messages API without Managed Agents? MCP tunnels still apply — you pass tunnelled server URLs via the
mcp_serversarray the same way as any other remote MCP server. - On AWS Bedrock / Claude Platform on AWS? Self-hosted sandboxes aren't available there yet. Tunnels are.
Both features are in Research Preview (beta). Access isn't automatic — you'll need to request it.
Source: The New Stack | MCP tunnels docs | Self-hosted sandboxes docs
✏️ Drafted with KewBot (AI), edited and approved by Drew.
Top comments (0)