16 New in Claude Managed Agents: Self-Hosted Sandboxes and MCP Tunnels
16.1 Control Over Execution and Connectivity
On May 19, 2026 — the same announcement as Dreaming, Outcomes, and Multiagent Orchestration (Chapter 13) — Anthropic introduced two infrastructure-focused features for Managed Agents: Self-Hosted Sandboxes and MCP Tunnels. Both addressed a critical concern for enterprise adoption: the need to control where code executes and how agents connect to private systems.
These features reflected a maturing understanding of enterprise requirements. Organizations wanted the power of managed agents but needed to keep execution within their own infrastructure (for security, compliance, or latency reasons) and connect to internal systems without exposing them to the internet. Self-hosted sandboxes and MCP tunnels solved both problems.
This chapter covers each feature, how it works, and when to use it.
16.2 Self-Hosted Sandboxes
16.2.1 The Execution Boundary Problem
When an agent executes code — running a script, testing a change, calling an API — that execution has to happen somewhere. In the original Managed Agents model (Chapter 11), execution happened in Anthropic-managed sandboxes: secure, isolated environments provided as part of the service.
For many use cases, managed sandboxes are ideal — they’re zero-config, automatically secured, and tightly integrated. But for some organizations, they present concerns:
- Data residency: Code execution may process data that must stay within specific infrastructure (regulatory, contractual).
- Network access: The agent may need to access internal systems (databases, internal APIs) that are not reachable from managed sandboxes.
- Compliance: Certain industries require execution within audited, organization-controlled infrastructure.
- Existing infrastructure: Organizations may have existing sandboxing platforms (Cloudflare Workers, Modal, etc.) they want to leverage.
Self-hosted sandboxes address these concerns by letting execution happen on your infrastructure, while the agent loop stays on Anthropic’s.
16.2.2 How It Works
In the self-hosted sandbox model:
- The agent loop (the orchestration, reasoning, and tool-use decisions) runs on Anthropic’s managed infrastructure.
- Tool execution (running code, calling systems, operating on files) happens on your chosen platform.
┌─────────────────────────────┐
│ Anthropic (Agent Loop) │
│ - Reasoning │
│ - Tool selection │
│ - Orchestration │
└──────────┬──────────────────┘
│ (tool execution requests)
▼
┌─────────────────────────────┐
│ Your Infrastructure │
│ (Self-Hosted Sandbox) │
│ - Code execution │
│ - File operations │
│ - Network calls │
└─────────────────────────────┘The agent decides what to do; your infrastructure does it. This split preserves the managed agent’s intelligence and orchestration while giving you control over execution.
The key principle: the agent loop stays on Anthropic; execution stays with you. You get the benefits of managed orchestration (no infrastructure to build for the agent logic) while retaining control over where code runs and what it can access.
16.2.3 Supported Platforms
At launch, self-hosted sandboxes supported several popular execution platforms:
| Platform | Type | Best For |
|---|---|---|
| Cloudflare | Edge/serverless | Low-latency, globally distributed execution |
| Daytona | Development environments | Reproducible dev environments |
| Modal | Serverless compute | Data-heavy, compute-intensive tasks |
| Vercel | Serverless functions | Web-oriented execution, quick deploys |
This range covers the common execution needs: edge execution (Cloudflare), development environments (Daytona), heavy compute (Modal), and web functions (Vercel).
16.2.4 What Applies to Your Infrastructure
When you self-host the sandbox, your infrastructure’s policies apply:
- Network policies: Your firewalls, VPC rules, and network controls govern what the sandbox can access.
- Audit logging: Your audit systems capture execution activity.
- Security tooling: Your security scanners, IAM, and monitoring apply.
- Data governance: Your data residency and handling policies are enforced.
This means the agent’s execution is subject to the same controls as any other workload in your environment — no special-casing, no shadow infrastructure.
16.3 MCP Tunnels
16.3.1 The Private MCP Server Problem
The Model Context Protocol (MCP) is the standard for connecting agents to external tools and data sources. An MCP server exposes capabilities (read a database, query an internal API, access a document store) that an agent can use. Many organizations run private MCP servers — connected to internal systems, behind firewalls, not accessible from the public internet.
The problem: how does a managed agent (running on Anthropic’s infrastructure) connect to a private MCP server (running on yours) without exposing the server to the internet?
The traditional answer is to expose the MCP server publicly (with authentication), but that’s undesirable for security reasons — every public endpoint is an attack surface. Organizations want their MCP servers to remain fully private.
16.3.2 How MCP Tunnels Solve It
MCP tunnels establish a connection between the managed agent and a private MCP server without exposing the server to the internet. The mechanism:
- The private MCP server makes a single outbound connection to Anthropic.
- The managed agent communicates with the MCP server through this tunnel.
- No inbound firewall rules are needed — the server initiates the connection outward.
┌─────────────────────┐ ┌─────────────────────┐
│ Private MCP Server │ ─── outbound ───> │ Anthropic │
│ (your network) │ <── connection ── │ (managed agent) │
└─────────────────────┘ └─────────────────────┘
│ │
│ No inbound ports open │ Agent accesses MCP
│ No public exposure │ via the tunnel
▼ ▼
[Internal Systems] [Agent Tool Calls]The beauty of MCP tunnels is their network simplicity. The MCP server makes one outbound connection — the kind of connection that firewalls allow by default (like a browser connecting to a website). No inbound ports need to be opened, no public endpoints are created, and the MCP server remains fully private. This is the same pattern used by tools like ngrok or SSH reverse tunnels, applied to the agent connectivity problem.
16.3.3 Benefits of MCP Tunnels
| Benefit | Description |
|---|---|
| No public exposure | The MCP server is never accessible from the internet |
| No inbound firewall rules | Only an outbound connection is needed |
| Simple network requirements | Works in restrictive network environments |
| Secure by default | The connection is authenticated and encrypted |
MCP tunnels make it practical to connect managed agents to any private system — internal databases, private APIs, document stores, knowledge bases — without compromising security posture.
16.4 Combined: Self-Hosted Execution + Private Connectivity
Self-hosted sandboxes and MCP tunnels are designed to work together. An agent can:
- Execute code in a self-hosted sandbox (on your infrastructure, under your policies).
- Access private tools and data via MCP tunnels (connected to your internal systems).
Together, they enable a fully controlled agent deployment: the intelligence runs on Anthropic, but all execution and data access happen within your perimeter, governed by your policies.
┌─────────────────────────┐
│ Anthropic │
│ (Agent Loop) │
└──┬──────────────────┬───┘
│ │
tool exec│ MCP tool│
▼ ▼
┌─────────────────┐ ┌──────────────────┐
│ Self-Hosted │ │ MCP Tunnel │
│ Sandbox │ │ │
│ (your infra) │ │ (to your private │
│ │ │ MCP servers) │
└─────────────────┘ └──────────────────┘
│ │
▼ ▼
[Your Network] [Internal Systems]
[Your Policies] [Private APIs/Data]16.5 Availability
At launch, both features were available as beta or preview:
| Feature | Status |
|---|---|
| Self-hosted sandboxes | Beta |
| MCP tunnels | Preview |
Beta/preview status meant the APIs were available for use but might change before general availability, and some edge cases might not be fully polished. Organizations were encouraged to test and provide feedback.
16.6 When to Use Each
16.6.1 Use Self-Hosted Sandboxes When
- Data residency requires execution within specific infrastructure.
- Network access to internal systems is needed from the sandbox.
- Compliance requires organization-controlled execution environments.
- You have existing sandboxing infrastructure you want to leverage.
16.6.2 Use Managed Sandboxes (Default) When
- You want zero-config execution.
- Internal network access isn’t required.
- The default security and isolation are sufficient.
- You want to minimize infrastructure management.
16.6.3 Use MCP Tunnels When
- You have private MCP servers the agent needs to access.
- You don’t want to expose internal systems to the internet.
- You’re in a restrictive network environment where only outbound connections are allowed.
16.7 Self-Hosted Sandboxes in Depth
The decision to use managed vs. self-hosted sandboxes is one of the most important architectural choices in a Managed Agents deployment. Let’s examine the tradeoffs in detail.
16.7.1 Managed Sandboxes: The Default
Managed sandboxes are the zero-friction option. Anthropic provides and manages the execution environment:
Advantages: - Zero configuration: No infrastructure to set up or maintain. - Automatic security: Anthropic manages isolation, network policies, and resource limits. - Tight integration: Works seamlessly with the managed agent harness. - No operational overhead: Scaling, updates, and maintenance are handled.
Limitations: - Network isolation: Managed sandboxes may not be able to reach internal systems behind your firewall. - Compliance constraints: Some regulated environments require execution within specific boundaries. - Customization limits: You work within the managed sandbox’s capabilities.
Managed sandboxes are the right default for most use cases. Choose them unless you have a specific reason to self-host.
16.7.2 Self-Hosted Sandboxes: When You Need Control
Self-hosted sandboxes give you control over the execution environment while keeping the agent loop managed.
When to choose self-hosted:
Internal network access: Your agent needs to reach internal databases, APIs, or services that aren’t exposed to the internet.
Data residency: Regulatory or contractual requirements mandate that certain data processing happens within your infrastructure.
Existing infrastructure investment: You already have sandboxing platforms (Cloudflare Workers, Modal functions) and want to leverage them rather than paying for managed equivalents.
Custom execution environments: Your agent needs specific runtime environments (custom Docker images, specialized hardware, specific OS configurations) that managed sandboxes don’t provide.
Audit and compliance: Your organization’s audit and compliance tooling must apply to agent execution, and that tooling is integrated with your infrastructure.
The decision between managed and self-hosted sandboxes is not all-or-nothing. You can use managed sandboxes for most agents and self-hosted sandboxes for specific agents that need internal access or custom environments. The composable API design supports this mixed approach.
16.7.3 Platform-Specific Considerations
Each supported platform has distinct characteristics:
| Platform | Execution Model | Latency | Best For |
|---|---|---|---|
| Cloudflare Workers | Edge serverless | Very low | Globally distributed, lightweight execution |
| Daytona | Development environments | Medium | Reproducible dev environments with specific toolchains |
| Modal | Serverless compute | Variable | Compute-intensive tasks, data processing |
| Vercel | Serverless functions | Low | Web-oriented execution, API integrations |
Choose the platform that matches your execution needs. A coding agent that needs a full development environment might use Daytona; a data-processing agent might use Modal; a web-interaction agent might use Cloudflare or Vercel.
16.7.4 Security Model for Self-Hosted Sandboxes
When you self-host the sandbox, your security controls apply:
- Network policies: Your firewalls, security groups, and network ACLs govern what the sandbox can access. The sandbox is within your network perimeter, subject to your rules.
- IAM: Your identity and access management controls apply. The sandbox runs with the permissions you grant it — no more.
- Audit logging: Your audit systems capture execution activity. Every command the sandbox runs is logged by your infrastructure.
- Resource limits: You control CPU, memory, and time limits for sandbox execution.
- Data governance: Your data classification, retention, and handling policies apply to data processed in the sandbox.
This means self-hosted sandboxes are at least as secure as your existing infrastructure — they’re subject to the same controls as any other workload you run.
16.8 MCP Tunnels in Depth
MCP tunnels solve a specific but important problem: connecting managed agents to private MCP servers without internet exposure.
16.8.1 The Connectivity Problem
MCP (Model Context Protocol) servers expose tools and data sources to agents. An MCP server might provide:
- Access to an internal database
- Queries against a private API
- Reads from a document management system
- Operations on an internal ticketing system
These MCP servers are typically private — they run on internal networks, behind firewalls, not accessible from the internet. This is by design: the systems they connect to are sensitive.
The problem: a managed agent (running on Anthropic’s infrastructure) needs to reach these private MCP servers. The traditional solution — expose the MCP server publicly with authentication — is undesirable because every public endpoint is attack surface.
16.8.2 How MCP Tunnels Work
MCP tunnels use an outbound-only connection model:
- The private MCP server initiates an outbound connection to Anthropic’s MCP tunnel service.
- The connection is authenticated and encrypted.
- The managed agent communicates with the MCP server through this established tunnel.
- No inbound ports are opened on the MCP server’s network.
Private Network Internet Anthropic
┌──────────────┐ ┌──────────────┐
│ MCP Server │ ────── outbound connection ─────────────────> │ Tunnel │
│ (internal) │ <────── agent requests ────────────────────── │ Service │
│ │ │ │
│ No open │ │ Managed │
│ inbound ports│ │ Agent │
└──────────────┘ └──────────────┘This is the same pattern used by:
- SSH reverse tunnels: Connect to a remote server without opening inbound ports.
- ngrok and similar tools: Expose local services via outbound connections.
- Cloud IoT platforms: Devices connect to the cloud via outbound connections.
The pattern is battle-tested and secure: the server initiates the connection outward (which firewalls typically allow, like a browser connecting to a website), and no inbound exposure is needed.
16.8.3 Security Properties of MCP Tunnels
| Property | How It’s Achieved |
|---|---|
| No public exposure | The MCP server is never reachable from the internet; only the tunnel endpoint at Anthropic is. |
| Authenticated | The outbound connection is authenticated, preventing unauthorized tunnel establishment. |
| Encrypted | All traffic through the tunnel is encrypted. |
| No inbound firewall rules | Only an outbound connection is needed; no ports are opened. |
| Revocable | The tunnel can be closed at any time by either end. |
16.8.4 Use Cases for MCP Tunnels
MCP tunnels enable managed agents to access a wide range of private systems:
- Internal databases: An agent queries an internal PostgreSQL database via an MCP server, without exposing the database.
- Private APIs: An agent calls internal microservice APIs that aren’t publicly exposed.
- Document management: An agent reads from and writes to an internal document system.
- Ticketing systems: An agent creates and updates tickets in an internal Jira or similar system.
- Monitoring systems: An agent queries internal monitoring and alerting systems.
Without MCP tunnels, these use cases would require either exposing internal systems publicly (bad) or running the entire agent on-premises (expensive and complex). MCP tunnels provide a third option: managed agent intelligence with private system access.
16.9 Combined Architecture Example
Let’s walk through a complete production architecture using both self-hosted sandboxes and MCP tunnels:
Scenario: A financial services company deploys a compliance-checking agent that:
- Runs on a schedule (every night).
- Executes compliance checks against transaction data.
- Queries an internal transaction database.
- Generates compliance reports and files them in an internal document system.
Architecture:
┌────────────────────────────────────────────────────────────┐
│ Anthropic (Managed) │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌───────────────┐ │
│ │ Schedule │───>│ Agent Loop │───>│ Results │ │
│ │ (nightly) │ │ (compliance │ │ (reports) │ │
│ └─────────────┘ │ checking) │ └───────────────┘ │
│ └──────┬───────┘ │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ │ │ │ │
│ tool exec MCP tunnel MCP tunnel │
│ │ │ │ │
└──────────────┼─────────────┼─────────────┼─────────────────┘
│ │ │
┌──────────▼──┐ ┌──────▼──────┐ ┌──▼──────────────┐
│ Self-Hosted │ │ MCP Server │ │ MCP Server │
│ Sandbox │ │ (database) │ │ (doc system) │
│ (Cloudflare)│ │ │ │ │
└─────────────┘ └──────┬──────┘ └──────┬──────────┘
│ │
┌──────▼──────┐ ┌──────▼──────────┐
│ Transaction │ │ Document │
│ Database │ │ Management │
└─────────────┘ └─────────────────┘In this architecture: - The agent loop runs on Anthropic (managed). - Code execution happens in a self-hosted Cloudflare sandbox (under the company’s controls). - Database access flows through an MCP tunnel to a private MCP server connected to the transaction database. - Document filing flows through another MCP tunnel to the document management system. - Credentials for all systems are stored in vaults (the agent never sees them).
This is a fully controlled, secure, production-grade deployment — with the intelligence managed by Anthropic and everything else under the company’s control.
16.10 Key Takeaways
- Two infrastructure features announced May 19, 2026: Self-Hosted Sandboxes and MCP Tunnels — both for enterprise control over execution and connectivity.
- Self-hosted sandboxes let tool execution happen on your infrastructure (Cloudflare, Daytona, Modal, Vercel) while the agent loop stays on Anthropic.
- The agent loop stays on Anthropic; execution stays with you — managed orchestration with controlled execution.
- Your policies apply to self-hosted sandboxes: network policies, audit logging, security tooling, data governance.
- MCP tunnels connect managed agents to private MCP servers without exposing them to the internet.
- Single outbound connection, no inbound firewall rules — MCP tunnels work in restrictive network environments with minimal network configuration.
- Both available as beta/preview at launch.
- The two features compose: self-hosted execution + private connectivity = a fully controlled agent deployment where intelligence is managed but execution and data access stay within your perimeter.
- Use managed sandboxes by default; choose self-hosted when data residency, internal access, or compliance requires it.
- Use MCP tunnels whenever the agent needs to access private systems without internet exposure.