Most enterprise agent projects don't die because the model hallucinated. They die in a meeting between engineering and security, six weeks into a pilot, when someone asks: "But where exactly does our data go when the agent calls a tool?"
Until recently, the honest answer for Claude Managed Agents was: Anthropic's infrastructure. The agent loop, the tool execution, the files it touched - all of it happened outside the customer's perimeter. For a startup, that's fine. For a bank, a hospital, or any company operating under data residency rules, it's a blocker that no amount of contractual language fully resolves.
On May 19, 2026, at the Code with Claude developer conference in London, Anthropic announced two new capabilities for Claude Managed Agents: self-hosted sandboxes, now in public beta, and MCP tunnels, in research preview. The release lets enterprise customers run the tool-execution layer of an agent on their own infrastructure - or with managed providers like Cloudflare, Daytona, Modal, and Vercel - while the agent loop itself, including orchestration, context management, and error recovery, continues to run on Anthropic's servers.
The architectural line Anthropic drew here is deliberate. The agent loop stays on Anthropic infrastructure. Tool execution and private MCP server access move inside the customer perimeter. You get the benefit of Anthropic running a highly available, managed agent runtime without giving up data residency, audit logging, or network policy enforcement.
That split matters more than it might look on a product announcement.
Why compliance was the actual bottleneck
Compliance, risk, and infrastructure teams at banks, insurers, healthcare providers, and regulated industrials have routinely held up agent pilots for six to twelve weeks while they assess where code executes, where files land, and which networks an agent traverses. The standard Managed Agents architecture, where tool calls executed inside Anthropic-managed containers, was operationally simple but politically difficult inside heavily regulated environments.
Self-hosted sandboxes address the execution side directly. Shifting the execution layer into infrastructure the customer already controls means existing network policies, audit logging pipelines, data loss prevention controls, and identity systems automatically apply. Files, repositories, and runtime packages never leave the customer's perimeter.
MCP tunnels solve a different but adjacent problem. Enterprises with internal MCP servers - wrapping a private database, a proprietary ticketing system, or a knowledge base - previously had only two options: expose those servers through a public endpoint, which security teams resist, or skip MCP integration entirely. The tunnel architecture sidesteps both. A lightweight gateway deployed inside the customer's network establishes a single outbound encrypted connection to Anthropic's routing infrastructure, and the agent reaches the private MCP server through that channel. No inbound firewall rules need to be opened, no public DNS entries need to be created, and traffic remains end-to-end encrypted.
The conversation was never "should we use agents?" It was always "who owns the perimeter when the agent runs?"
That framing shift - from capability question to infrastructure question - is why so many enterprise pilots stalled. The tools worked well enough. The governance scaffolding around them didn't.
What teams should actually do with this
The announcement doesn't mean regulated enterprises can deploy tomorrow without review. This is not a full on-premise deployment, and Anthropic is not pretending otherwise. Customers whose compliance posture requires that no telemetry or orchestration metadata touch external infrastructure will still find this insufficient. But for the much larger population of enterprises whose actual constraint is data residency and execution-environment control, the model is well-calibrated.
For most teams, the practical value is political as much as technical. When your security team asks "where does the data go," you now have a specific, architectural answer rather than a vendor assurance. That's a different kind of conversation.
There's a useful parallel happening at the protocol level too. The headline change in the MCP specification release candidate, locked on May 21, is that MCP is now stateless at the protocol layer, the result of six Specification Enhancement Proposals working together.
The Mcp-Session-Id header and the protocol-level session that came with it are removed. With both gone, any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer. That makes MCP servers far easier to run behind a load balancer, inside a VPC, without the sticky-session gymnastics that made private deployments awkward. The tunnel feature and the stateless spec are solving different layers of the same problem.
What this means for teams who aren't in regulated industries
Even if your company doesn't have a compliance team breathing down your neck, the self-hosted sandbox model is worth understanding. It's a sign that the serious deployment work is moving from "can the agent do the task" to "can we operate the agent like any other piece of infrastructure." That means audit trails, compute ownership, network policy, and the ability to swap out the sandbox provider without rebuilding the agent.
A teammate like Beagle, living in Slack and Teams, already operates inside the communication perimeter rather than asking data to leave it. The same instinct is now shaping how the more powerful, long-running agents get deployed - bring the agent to the data, not the data to the agent.
The question teams should be asking their security and infrastructure leads is not "can we use this." It's "what would we need to have in place to make this a yes." Those are different conversations, and the second one is one you can actually finish.