Claude Managed Agents now support self-hosted sandboxes: enterprise agents are moving behind the firewall
A practical look at why Anthropic's self-hosted sandboxes and MCP tunnels matter for enterprise agent architecture, trust boundaries, and controlled tool execution.
Anthropic's latest Claude Managed Agents update is not really about a new model capability.
It is about where the agent is allowed to act.
On May 19, 2026, Anthropic announced that Claude Managed Agents can now use self-hosted sandboxes in public beta. It also introduced MCP tunnels in research preview. The short version: Anthropic still runs the agent orchestration, context management, and recovery loop, but the place where tools execute can now sit inside infrastructure the customer controls.
That split matters.
Most enterprise agent conversations still get stuck on model quality. Which model reasons better? Which model writes better code? Which model handles long context better?
Those questions matter, but they are no longer the only blocker.
For many companies, the bigger question is much more basic: where does the agent run when it touches files, repositories, internal APIs, databases, packages, credentials, and network egress?
That is where self-hosted sandboxes become interesting.
With the new setup, the model and orchestration layer stay on Anthropic's side. The execution environment can run on customer infrastructure, or through supported sandbox providers such as Cloudflare, Daytona, Modal, or Vercel. Anthropic describes this as a way to keep sensitive files, packages, and services inside the enterprise perimeter while still using Claude Managed Agents for the agent loop.
In practical terms, this gives teams more control over the part of the agent that can cause damage.
The sandbox is where commands run. It is where files are read and written. It is where packages get installed. It is where network calls leave the environment. It is where logs, runtime images, resource limits, secrets, and policies can be enforced.
That is the piece security teams care about.
An agent that can reason well but cannot safely touch internal systems is still a demo. An agent that can reach production-adjacent systems without strong boundaries is worse than a demo. It is an incident waiting for a calendar invite.
The enterprise version needs a different shape:
- the model provider handles orchestration and model quality
- the customer controls tool execution
- internal services stay behind private network boundaries
- network egress can be logged, proxied, blocked, or inspected
- filesystem access can follow enterprise policy
- secrets can be injected and scoped at the infrastructure layer
That architecture is not pure self-hosting. It is hosted orchestration plus customer-controlled execution.
That distinction is important because the word "self-hosted" can hide more than it explains.
The model context still flows through the provider. The agent loop still depends on Anthropic's infrastructure. The provider still sees enough of the task to run the model and manage the agent's state. If a company needs the model itself, context handling, and orchestration fully inside its own environment, this does not appear to be that.
But it does move a meaningful boundary.
Instead of sending every tool action through a provider-managed runtime, a company can put the runtime closer to its own security controls. That means existing network policies, audit logging, runtime images, identity controls, and incident-response practices can become part of the agent system.
MCP tunnels point in the same direction.
MCP is the standard many AI tools use to connect models and agents to external systems. It gives agents a common way to call tools, read data, and interact with services. The problem for enterprise teams is obvious: many useful MCP servers should not be exposed to the public internet.
Anthropic's MCP tunnels are meant to let agents reach MCP servers inside a private network without creating public endpoints. According to Anthropic, a gateway deployed by the customer makes an outbound connection, and the agent can reach private services through that tunnel.
That sounds like a small infrastructure detail. It is not.
Private network access is one of the places where enterprise AI stops being a chatbot and starts becoming part of the operating system of a company. Internal databases, ticketing systems, code repositories, knowledge bases, analytics tools, deployment systems, and support workflows can become callable tools.
That is also where the risk goes up.
Once an agent can call real tools, the question is not only "is the answer good?" The question becomes:
- What can this agent touch?
- Which identity does it use?
- Can it exfiltrate data through network egress?
- Can it mutate internal systems?
- Are tool calls logged in a way humans can audit?
- Can a bad prompt, poisoned tool description, or compromised integration widen the blast radius?
Self-hosted execution helps with some of those questions. It does not remove them.
The real enterprise pattern is going to be boring in the best way.
Agents will need runtime isolation. They will need permission boundaries. They will need scoped credentials, egress controls, durable logs, replayable traces, approval gates, and boring integration with the systems companies already use to manage risk.
That is why this update feels bigger than a feature release.
It shows where enterprise agents are heading. Not toward one giant cloud assistant that gets access to everything. Not toward every company hand-rolling its own full agent stack either.
The likely middle path is hybrid:
Claude, or another provider, runs the model and orchestration layer. The enterprise runs the execution environment, connects private tools through controlled channels, and uses its own infrastructure to contain the agent's actions.
This is also the market signal.
The first wave of agents was about demos. Can the model use a browser? Can it edit code? Can it call a tool? Can it run a workflow?
The next wave is about boundaries.
Where does execution happen? What data leaves? What can the agent reach? How is the session logged? What happens when the model is wrong? What happens when a tool lies? What happens when a prompt tries to turn a helpful integration into a data leak?
That is the work enterprises actually have to solve.
The interesting part of Anthropic's update is not that it answers every security question. It does not.
The interesting part is that the agent stack is starting to split into clearer layers:
- model and orchestration
- execution sandbox
- private tool connectivity
- identity and permissions
- logging and audit
- policy and governance
Once the stack splits that way, teams can reason about risk more concretely.
That is when agents start to move from impressive demos into enterprise infrastructure.