Anthropic is moving Claude Managed Agents closer to the deployment model security teams have been asking for: hosted agent orchestration without forcing every tool call, filesystem operation, and private system connection into a vendor-controlled runtime.
On May 19, 2026, Anthropic announced two additions to Claude Managed Agents: self-hosted sandboxes, available in public beta, and MCP tunnels, available in research preview. The short version is that Claude can keep the agent loop on Anthropic’s side while moving execution and private tool access closer to the customer’s own infrastructure.
That distinction matters.
For builders, the question is no longer only “can an agent run a long task?” The sharper question is: where does the agent execute, which private systems can it reach, and what evidence proves it stayed inside the boundary?
This is independent Open-TechStack analysis. It is not official Anthropic guidance, legal advice, procurement advice, or a sponsored post.
Who this is for
This is for platform teams, security engineers, AI infrastructure leads, and developer-experience teams evaluating managed AI agents for real internal work.
It is especially relevant if your agents need to:
- read private repositories, documents, or datasets
- run builds, tests, data transforms, or code generation in a controlled environment
- call MCP servers that sit behind a firewall
- operate under existing network policy, logging, and compliance controls
- use Cloudflare, Daytona, Modal, Vercel, Kubernetes, or containerized worker infrastructure as an execution layer
The practical goal is not to adopt the newest agent feature quickly. It is to decide whether this architecture gives your team a cleaner boundary between agent orchestration, tool execution, and private system access.
TL;DR
Anthropic’s May 19 update matters because it separates two parts of the agent problem that teams often mix together.
- Self-hosted sandboxes control where code and tools execute.
- MCP tunnels control how Claude reaches private MCP servers without exposing them publicly.
- Anthropic says self-hosted sandboxes are in public beta.
- Anthropic says MCP tunnels are in research preview, which is a weaker maturity signal than beta or general availability.
- The agent loop still runs on Anthropic infrastructure.
- Tool execution can move into infrastructure you control or into supported managed sandbox providers.
- MCP tunnels are outbound-only from your network and do not require opening inbound firewall ports.
- Teams should pilot this with read-only tools, strict network policy, queue monitoring, log review, and a rollback plan.
The recommendation: treat this as a serious enterprise-agent architecture option, but do not treat it as production default until your own worker, tunnel, identity, logging, and incident-response model are tested.
What changed
Anthropic’s announcement says Claude Managed Agents can now operate in a sandbox controlled by the customer and connect to private Model Context Protocol servers. The company lists Cloudflare, Daytona, Modal, and Vercel as supported managed sandbox providers, while the docs also describe how to build a generic self-hosted environment worker.
The key split is:
| Layer | What it does | Where it lives in this model |
|---|---|---|
| Agent loop | Orchestration, context management, error recovery, session state | Anthropic infrastructure |
| Tool execution | Shell work, code execution, file operations, skill execution | Customer-controlled sandbox or supported provider |
| Private MCP access | Calls to internal tools, APIs, databases, knowledge bases, ticketing systems | Routed through an outbound tunnel from the customer’s network |
| Security controls | Network policy, runtime image, audit logs, secrets handling, resource limits | Customer or sandbox-provider control plane |
That is a meaningful architecture shift because many organizations want managed agents but do not want agent execution to happen in an opaque shared environment. A self-hosted sandbox lets the customer define runtime images, compute sizing, filesystem mounts, network egress, and audit hooks.
MCP tunnels solve a different problem. They let Claude reach private MCP servers without asking the customer to expose those servers to the public internet. Anthropic’s docs describe a tunnel stack that runs inside the customer’s network and makes outbound-only connections. Each private MCP server can then be routed through a hostname under the tunnel domain.
The architecture in plain English
Think of the new model as three boxes instead of one.
Claude still plans and manages the work from Anthropic’s infrastructure. The sandbox runs the actions. The tunnel connects to internal tools.
That gives teams a cleaner control model:
- Claude decides what to do next inside the managed agent loop.
- The self-hosted worker claims the work item from Anthropic’s queue.
- The worker runs tool calls in the configured local environment.
- Private tools are reached through MCP servers inside the customer’s network.
- Logs, network policy, filesystem access, and resource constraints can be enforced near the execution layer.
The important limitation is that this does not make the whole agent fully self-hosted. The control loop remains managed by Anthropic. For many teams, that is the point: keep the difficult orchestration managed while moving sensitive execution closer to existing controls. For stricter environments, that may still be too much external dependency.
Why MCP tunnels matter
Before tunnels, a private MCP server usually required one of three uncomfortable choices:
- expose the server publicly and protect it with auth
- route through a custom VPN, proxy, or allowlist pattern
- keep the MCP server local and lose managed-agent reach
MCP tunnels offer a more explicit path. Anthropic’s docs say the tunnel uses a small stack inside the customer network, including cloudflared and a proxy. The tunnel makes outbound connections to the tunnel edge, while the proxy routes requests to the correct upstream MCP server.
The security claim to evaluate is not “Claude can reach private tools.” The stronger operational claim is: Claude can reach private tools without inbound firewall openings or public endpoints.
That is useful for internal systems such as:
- documentation search
- ticket triage
- internal API discovery
- private database query tools
- compliance evidence retrieval
- repo or build-system helpers
But the tunnel does not remove normal MCP risk. It routes traffic. It does not magically solve authorization, prompt injection, tool overreach, or bad server design. If an upstream MCP server exposes a dangerous write operation, the tunnel gives the agent a path to that operation. The approval model still has to live in your MCP server, agent instructions, identity layer, and review workflow.
Self-hosted sandbox rollout checklist
Use this before giving a managed agent access to real internal data.
| Check | Minimum standard |
|---|---|
| Environment boundary | Run sessions in an isolated workspace, preferably one container or VM per session for sensitive work. |
| Runtime image | Pin the base image, package versions, shell tools, and language runtimes. |
| Filesystem | Mount only the files the task needs; avoid broad home-directory or repository access. |
| Network policy | Default deny egress, then allow only package registries, APIs, and private services required by the workflow. |
| Secrets | Inject secrets at the boundary and keep them out of prompts, logs, outputs, and mounted files. |
| Queue monitoring | Track depth, pending work, oldest queued item, and active workers. |
| Output handling | Store final artifacts in a known output path and scan them before downstream use. |
| Stop controls | Test graceful stop and forced stop before the first real rollout. |
| Audit logs | Capture session ID, worker ID, tool calls, network destinations, auth method, and output location. |
The strongest pilot is narrow: one read-only or low-risk workflow, one sandbox image, one MCP server, one team owner, and a measurable success criterion.
MCP tunnel rollout checklist
For MCP tunnels, start with the network and identity model before the agent prompt.
| Check | Minimum standard |
|---|---|
| Feature maturity | Treat MCP tunnels as research preview, not guaranteed production infrastructure. |
| Deployment target | Decide Kubernetes, Docker Compose on a VM, or a local test environment. |
| Authentication | Prefer short-lived programmatic access where possible; document any static tunnel token use. |
| Upstream allowlist | Limit which internal MCP servers and IP ranges the proxy can reach. |
| MCP auth | Keep OAuth or bearer-token authentication separate from the tunnel itself. |
| Tool permissions | Start read-only and require explicit approval for write actions. |
| Logging | Log hostname, MCP server name, request category, session ID, and response status. |
| Abuse handling | Rate-limit high-risk tools and create a manual kill path. |
| Data handling | Define which internal data can be returned to Claude and which must be summarized, redacted, or blocked. |
The tunnel should not become a blanket bridge from Claude to the internal network. It should be a governed route to specific MCP servers with clear ownership.
What not to do
Do not read this launch as permission to connect every internal tool to a managed agent.
Bad rollout patterns:
- connecting production write tools before testing read-only workflows
- exposing one broad MCP server that wraps too many systems
- running all sessions in one long-lived shared filesystem
- putting organization API keys on the worker host where tool calls can read them
- allowing unrestricted outbound network access from the sandbox
- skipping logs because “the agent is still in beta”
- treating a research preview tunnel as if it has production availability guarantees
The better approach is staged:
- Create a single self-hosted environment for a non-critical workflow.
- Run the worker with a pinned runtime and tight filesystem access.
- Add one private MCP server with read-only tools.
- Review the logs after every session for the first week.
- Add write tools only after you have approval gates and rollback paths.
- Reassess whether the managed orchestration boundary fits your compliance model.
Decision matrix
| Scenario | Use self-hosted sandboxes? | Use MCP tunnels? | Reason |
|---|---|---|---|
| Agent needs to run builds on private source code | Yes | Maybe | Execution boundary matters; tunnel only matters if tools are private MCP servers. |
| Agent only needs public docs and public APIs | Usually no | No | A cloud-managed environment is simpler. |
| Agent needs an internal knowledge-base MCP server | Maybe | Yes | Tunnel solves private tool reach; sandbox depends on data sensitivity. |
| Regulated workflow with private data and internal tools | Yes | Yes, carefully | Use both, but pilot with strict read-only boundaries first. |
| Short-lived experimentation | Maybe | No | Avoid preview infrastructure unless private access is the point. |
| High-availability production automation | Not yet by default | Not yet by default | Beta and research preview maturity should trigger extra review. |
The practical read: self-hosted sandboxes are about where work happens. MCP tunnels are about what private tools the agent can reach. They can be used together, but they are not the same control.
How this fits the agent stack
This launch fits a bigger pattern in agent infrastructure.
Why MCP Is Becoming the Default Standard for AI Tools in 2026 explains why the protocol layer is becoming common across AI clients. Cloud MCP Servers Compared: AWS vs Azure vs Cloudflare vs GitHub vs Google covers the managed cloud side of that tool-access market. AI Agent Observability Stack 2026 explains why traces, cost, latency, and review evidence become mandatory once agents start touching real systems.
Anthropic’s current move sits between those layers. It does not just add another connector. It gives teams a more explicit split between managed reasoning and controlled execution.
It also lands one day after Anthropic announced its acquisition of Stainless, which we covered in Anthropic Acquires Stainless: Why SDKs and MCP Servers Are Agent Infrastructure Now. Taken together, the signal is clear: the next phase of agent competition is not only model quality. It is connector quality, runtime control, sandboxing, auditability, and enterprise deployment shape.
FAQ
What are Claude Managed Agents self-hosted sandboxes?
Self-hosted sandboxes let Claude Managed Agents run tool execution in infrastructure controlled by the customer or a supported sandbox provider, while Anthropic continues to run the agent orchestration loop.
What are MCP tunnels?
MCP tunnels let Claude reach Model Context Protocol servers inside a private network through an outbound-only tunnel, so teams do not need to expose those MCP servers as public endpoints.
Are self-hosted sandboxes and MCP tunnels the same feature?
No. Self-hosted sandboxes control where tool execution happens. MCP tunnels control how Claude reaches private MCP servers. A team can use one without the other, or combine both for stricter execution and tool-access boundaries.
Is this production-ready?
Not automatically. Anthropic describes self-hosted sandboxes as public beta and MCP tunnels as research preview. Teams should pilot with low-risk workflows, explicit owners, logs, network restrictions, and rollback plans before relying on them for production automation.
Do MCP tunnels replace authentication?
No. The tunnel provides a private route to MCP servers. Upstream MCP authentication, authorization, scopes, approval gates, and audit logs still need to be designed and enforced separately.
Bottom line
Claude Managed Agents self-hosted sandboxes and MCP tunnels are important because they move the enterprise-agent conversation from “can the model use tools?” to “can the agent use tools inside a boundary we can operate?”
That is the right conversation.
The safest next step is a focused pilot: one self-hosted worker, one private read-only MCP server, one agent workflow, strict logs, and a written expansion rule. If the pilot proves that execution, private access, and audit evidence are clean, expand deliberately. If the boundary is still unclear, keep the workflow out of production.
Sources
- Claude Blog: New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels
- Claude API Docs: Self-hosted sandboxes
- Claude API Docs: MCP tunnels
- Anthropic Engineering: Scaling Managed Agents: Decoupling the brain from the hands
- InfoQ: Anthropic Introduces MCP Tunnels for Private Agent Access to Internal Systems
- Anthropic News: Anthropic acquires Stainless
