Anthropic Adds Self-Hosted Sandboxes and MCP Tunnels to Claude Managed Agents
Anthropic now lets teams run Claude agents on their own infrastructure with self-hosted sandboxes and MCP tunnels. Here's what changed and why it matters.
Anthropic has updated Claude Managed Agents to support self-hosted sandboxes and MCP tunnels, giving companies the ability to run agent tooling on their own infrastructure instead of Anthropic's. This is a meaningful shift in how teams can deploy and control agents in production — with implications for security, compliance, and how MCP servers get wired into agent workflows.
What Changed With Claude Managed Agents
Until recently, if you wanted to use Claude's managed agent features, the tooling ran on Anthropic's infrastructure. That was fine for early experimentation but a blocker for any team with data residency requirements, internal tooling behind firewalls, or compliance constraints that prevent data leaving their environment.
The self-hosted sandbox option removes that blocker. Companies can now run the agent execution environment on their own infrastructure — whether that's a private cloud, an on-prem server, or an air-gapped environment — while still using Claude as the model powering the agents.
The MCP tunnel feature is the other half of this. It lets agent workloads connect to Model Context Protocol servers that live inside a private network without exposing those servers to the public internet. The tunnel handles the connection handshake, so your internal MCP servers stay internal.
Why MCP Tunnels Matter for Production Agent Stacks
MCP is how agents get tools — databases, APIs, file systems, internal services. The problem was that if your MCP servers were behind a VPN or inside a private network, you had to either open firewall rules or run a separate proxy to make them reachable from Anthropic's hosted infrastructure.
MCP tunnels solve this cleanly. The agent workload in your sandbox initiates an outbound connection through the tunnel, and the MCP server on the other end never has to be publicly addressable. This is the architecture you'd want anyway for anything production-grade.
For teams already managing MCP server collections — discovery, versioning, access control — this makes the full stack more coherent. The servers stay internal. The agents reach them. Nothing has to be punched through a firewall.
The Stainless Acquisition and What It Signals
On May 19, Anthropic acquired Stainless, the company that built tooling for generating official SDKs and MCP server implementations. This is not an unrelated event.
Stainless built tooling that makes it faster to generate well-structured SDKs and MCP servers from API specs. Bringing that capability in-house puts Anthropic in a position to standardize and accelerate how MCP servers get built, distributed, and maintained — which matters a lot if MCP is going to be the connective tissue for the broader agent ecosystem.
The practical read: expect MCP server tooling to get more opinionated and better integrated with Claude's own infrastructure over the next several months.
Cloudflare as a Distribution Layer for Agents
Also in this week's orbit: Cloudflare announced a collaboration with Anthropic around an AI agent platform. Cloudflare's network is already where a lot of MCP servers are being deployed because Workers and Durable Objects give you a globally distributed, low-latency execution environment with built-in state management.
Combining Cloudflare's edge infrastructure with Claude's managed agent capabilities creates a plausible path to deploying agents that run close to where requests originate, with MCP servers distributed across regions and the Claude model handling the reasoning. This is an architecture worth paying attention to if your agents need to serve users across geographies without centralizing all execution in one region.
How to Think About Self-Hosted Sandbox Architecture
If you're evaluating whether self-hosted sandboxes are worth setting up, here's a breakdown of the tradeoffs:
| Factor | Anthropic-hosted | Self-hosted sandbox |
|---|---|---|
| Setup time | Near zero | Requires infrastructure work |
| Data residency | Anthropic's environment | Your environment |
| Internal tool access | Requires exposure or proxy | Native via MCP tunnel |
| Compliance fit | Depends on Anthropic's certifications | You control the environment |
| Operational overhead | Low | Higher — you own the infra |
| Cost model | Usage-based, Anthropic manages | Your infra costs plus API usage |
The self-hosted path makes sense when your internal tooling is too sensitive to expose externally, when your compliance requirements specify where data is processed, or when you need predictable latency connecting agents to internal systems.
What This Means for Teams Managing Agent Stacks
If you're a Staff+ engineer or tech lead responsible for an agent stack — multiple agents, multiple MCP servers, different teams consuming them — this update changes the architecture options available to you.
A few concrete implications:
- Agent isolation becomes cleaner. Running sandboxes on your own infra lets you scope what each agent can reach at the network level, not just the permission level.
- MCP server management stays internal. Your server registry, versioning, and access control don't have to be designed around the assumption that servers are publicly reachable.
- Team workflows get more structured. When the execution environment is something your team owns, you can apply the same CI/CD, logging, and observability practices you'd apply to any other production service.
- Compliance reviews get simpler. Answering "where does this data go" becomes easier when the sandbox is in your own account.
The organizational pattern that works here is treating your agent infrastructure like any other internal platform: documented, versioned, with clear ownership and runbooks. The tools now exist to support that level of rigor.
Where LiteLLM Fits
Worth mentioning separately: LiteLLM has been building toward a similar self-hosted infrastructure story with their agent platform — Kubernetes-based, with isolated agent sandboxes and persistent session management. The patterns there are similar: isolation at the execution level, persistent state, infrastructure you control.
What's different with Anthropic's approach is the native MCP integration and the tunnel mechanism. LiteLLM is model-agnostic by design. If you're running a multi-model stack, LiteLLM's platform might be the layer that abstracts across providers. If Claude is your primary model and MCP is your tool protocol, Anthropic's managed agent infrastructure starts to look like the more natural home.
These are not mutually exclusive. Some teams will run LiteLLM in front of Claude, use Anthropic's managed agent infrastructure for execution, and connect to internal MCP servers via tunnels. That's a coherent stack.
The Direction This Is All Heading
Anthropic acquiring Stainless, adding self-hosted execution, shipping MCP tunnels, and working with Cloudflare on agent distribution — these are not isolated features. They're pieces of an infrastructure story where the goal is making Claude-powered agents something teams can run with production-level control, not just prototype-level convenience.
For developers building on top of this, the immediate value is practical: you can now wire up agents to internal tooling without architectural compromises. The longer-term value is that the tooling for building, deploying, and managing agents is maturing fast enough to support real engineering practices around it — not just one-off experiments.
If you're managing agent workflows across a team and haven't revisited your MCP server organization since these updates landed, now is a reasonable time to do that.
Store your agents, skills, prompts, MCPs, and more in one place.
Get Started Free