Claude Managed Agents, Self-Hosted Sandboxes, and MCP Tunnels: What Anthropic Just Shipped

Anthropic split the agent loop from tool execution. Self-hosted sandboxes (public beta) and MCP tunnels (research preview) explained, with what they enable.

Claude Managed Agents, Self-Hosted Sandboxes, and MCP Tunnels: What Anthropic Just Shipped

Anthropic recently expanded Claude Managed Agents with two pieces that change what enterprise AI agents can actually do safely. Self-hosted sandboxes (now in public beta) move tool execution out of Anthropic's infrastructure and onto yours, so the agent's code, files, and network calls stay inside your perimeter. MCP tunnels (research preview) let those agents reach private Model Context Protocol servers running on your internal network, without you opening a single inbound firewall rule. The combination matters because it is the first time a major AI provider has cleanly split the agent brain from the agent hands, with the data path through your own systems.

This piece explains what each piece is, the architecture that makes it work, what kinds of work it makes possible, and what to consider before using either. If you are still mapping out which AI provider fits your stack, our practical comparison of Anthropic, OpenAI, and Google for marketing teams covers the broader picture before you commit to this depth of integration.

A quick recap of what Claude Managed Agents are

Claude Managed Agents is Anthropic's hosted offering for running long-running, multi-step agents. Instead of writing your own orchestration loop on top of the Messages API, you describe an agent (a model, a system prompt, a set of tools, guardrails) and Anthropic runs the loop. The platform handles context management, error recovery, retries, parallel tool calls, and the rest of the boilerplate that comes with building an agent harness yourself.

The primitives are simple. An agent is a configuration. An environment is the execution context (the sandbox container, the network rules, the preinstalled packages). A session is one run of an agent inside an environment.

When Managed Agents shipped earlier this year, every session ran in Anthropic's cloud sandbox. That worked for plenty of use cases, but it locked out anyone whose tools needed to touch data that could not leave a private network. The two new pieces fix that.

What self-hosted sandboxes do

The simplest way to describe self-hosted sandboxes: Anthropic still runs the agent loop, but you run the box where the agent executes its tools.

!Anthropic's diagram of the Claude Managed Agents self-hosted sandbox architecture, with the agent loop on Anthropic's infrastructure and tool execution inside the customer perimeter.png)

*Self-hosted sandbox architecture. Image: Anthropic.*

The split looks like this. Anthropic keeps responsibility for orchestration, context window management, tool routing, retries, and recovery. Your infrastructure becomes the place where the actual code runs, where files are read and written, and where outbound network calls originate. The agent's working memory, code, and traffic stay inside your environment for as long as the session runs. Anthropic's engineering team walks through the architectural reasoning in their post on scaling Managed Agents by decoupling the brain from the hands.

The mechanism is an environment worker. It is a small process you run on your own boxes. When a session is assigned to the self-hosted environment, Anthropic enqueues the work item, and the environment worker picks it up, runs the requested tool calls, and returns the results. Tool execution happens entirely on your side. Anthropic sees the tool inputs and outputs as they flow through the orchestration loop, but the side effects (filesystem writes, database queries, API calls) happen in your environment.

Where you can run the sandbox

You have two options. You can run the environment worker on your own infrastructure (bare metal, your own Kubernetes cluster, a VM, whatever) or you can hand the compute and isolation to a managed provider. Cloudflare, Daytona, Modal, and Vercel were named at launch as supported managed sandbox providers, with platform-specific guides for AWS Lambda MicroVMs, Blaxel, E2B, GKE Agent Sandbox, Namespace, Superserve, and others.

The difference matters. Running the sandbox yourself gives you maximum control over packages, network rules, and isolation. Running it through a managed provider gives you the same architectural benefits with less setup. For most teams, a managed provider is the right starting point.

Credential handling

One detail worth calling out. Credentials for tools (MCP server tokens, CLI tokens, GitHub access) are kept outside the sandbox. They live in a separate vault. When a tool call needs a credential, a proxy fetches it from the vault, decrypts it, and uses it for that call. The sandbox itself never holds the long-lived token in plaintext.

This is a real improvement over the typical pattern of injecting secrets into a container at startup, because a compromised sandbox process does not equal a compromised token vault.

What MCP tunnels do

MCP tunnels solve the related problem of reaching private MCP servers from a hosted agent. Model Context Protocol is the standard Anthropic uses for connecting tools to Claude. Public MCP servers are easy. Anthropic's infrastructure can reach them over the internet. Private MCP servers (the kind that wrap your internal database, your ticketing system, your knowledge base, or your CRM) are the hard case. Until tunnels, you either exposed them to the public internet behind authentication, ran the whole agent inside your network, or did not connect them at all.

MCP tunnels make the private case work without exposing anything. You deploy a small gateway inside your network. That gateway opens a single outbound connection to Anthropic's tunnel edge. All traffic for your private MCP servers flows through that connection. No inbound firewall rules. No public endpoints on your MCP servers.

!Anthropic's diagram of an MCP tunnel connecting Claude Managed Agents to private MCP servers behind a customer firewall through a single outbound connection.png)

*MCP tunnel architecture. Image: Anthropic.*

The architecture in plain terms

The transport runs on Cloudflare's network using cloudflared, Cloudflare's open-source tunnel connector. Anthropic operates a routing proxy that sits between Cloudflare and your MCP servers. Inner TLS is terminated by Anthropic's proxy using a certificate you provide and only you hold, which means Cloudflare cannot read the actual request or response payloads. They handle transport. Anthropic handles routing and TLS termination on certificates you control.

A few specific properties fall out of that design:

What this looks like in practice

The pieces you deploy on your side are small. A cloudflared connector. A gateway process. A TLS certificate. That is it. Anthropic handles the rest. From the agent's perspective, a tool call to a private MCP server looks the same as a tool call to a public one. The difference is invisible to the model.

What this combination makes possible

The interesting work is what these two pieces let you do together. Three categories of agent application get easier or become possible for the first time:

1. Agents that touch regulated or sensitive data

Healthcare, finance, legal, and any company under data residency requirements (GDPR, HIPAA, PCI, SOC 2 boundaries) can now run hosted Claude agents without the data ever leaving their environment. The agent loop runs on Anthropic. The data does not. That changes the procurement conversation for anyone who has been blocked from running hosted AI agents because of where the data lives.

2. Agents over internal systems

Most real enterprise work happens against internal systems that are not on the public internet. Internal CRMs, ticketing systems, custom databases, knowledge bases behind a VPN, legacy SaaS deployments. MCP tunnels make these reachable from a hosted agent without rebuilding the network around them. The agent reaches your private MCP server the same way a developer on your VPN would reach it, except the connection is initiated from the inside.

3. Production-grade automation that runs in a known environment

If you have ever debugged a hosted-sandbox agent that worked in development but failed in production because the runtime environment was slightly different, self-hosted sandboxes are the fix. The environment is the environment you specify. Packages, system tools, network rules, all of it. The sandbox is reproducible because it is yours. This is the same lesson the broader ecosystem keeps learning every time a hosted dev tool gets pulled, including the recent Gemini CLI shutdown: if you cannot reproduce the environment, you cannot rely on it.

What you give up

Nothing comes for free. The tradeoffs:

Operational responsibility. Anthropic runs the sandbox in the hosted version. You run it in the self-hosted version. That means you handle scaling, monitoring, and the failure modes of the environment worker process. Managed sandbox providers absorb most of this, but you still own the configuration.

Setup cost. The first deployment of a self-hosted sandbox or an MCP tunnel takes more than the hosted equivalent. Cloudflared, certificates, network configuration, environment worker process. Plan for a half-day of setup, not a five-minute toggle.

Beta status. Self-hosted sandboxes are in public beta. MCP tunnels are in research preview, which means you have to request access and the behavior may shift before general availability. Not appropriate for anything you cannot afford to debug during a behavior change.

When to use each

A simple decision tree:

Your tools only call public APIs and read or write data that can live in a third-party cloud sandbox: stick with the standard Managed Agents setup. Self-hosted is unnecessary overhead.

Your tools touch internal data or systems that cannot leave your network, but you can reach the data over a public API protected by auth: self-hosted sandbox alone is enough. Run the environment worker in your VPC, give it the credentials it needs through the vault, and you are done.

Your tools need to talk to private MCP servers behind your firewall: you need both. Self-hosted sandboxes for the tool execution, MCP tunnels for the connection to your internal MCP infrastructure.

You are under data residency or compliance constraints: both, with the sandbox in the relevant region.

Frequently asked questions

What are Claude Managed Agents?

Claude Managed Agents is Anthropic's hosted platform for running long-running, multi-step AI agents on Claude. You configure an agent (model, prompt, tools, guardrails), and Anthropic runs the orchestration loop including context management, error recovery, and retries. It removes most of the work of building an agent harness yourself. See Anthropic's overview docs for the full setup.

What is a self-hosted sandbox in Claude Managed Agents?

A self-hosted sandbox is an execution environment for an agent's tool calls that runs on your own infrastructure or a managed provider you choose, rather than on Anthropic's cloud. The agent loop still runs on Anthropic. The tool execution, filesystem, and network traffic run in your environment. It is in public beta as of 2026. Full docs are at platform.claude.com.

What is an MCP tunnel?

An MCP tunnel is a connection mechanism that lets a Claude agent reach private Model Context Protocol servers running inside your network without exposing them to the public internet. You deploy a small gateway that opens an outbound connection to Anthropic's tunnel edge. Traffic to your MCP servers flows through that connection. It is in research preview as of 2026.

Which managed providers support Claude self-hosted sandboxes?

Cloudflare, Daytona, Modal, and Vercel were named at launch. Additional platform-specific guides cover AWS Lambda MicroVMs, Blaxel, E2B, GKE Agent Sandbox, Namespace, and Superserve. You can also run the sandbox on your own infrastructure without a managed provider.

Can Anthropic or Cloudflare read traffic through an MCP tunnel?

No. The tunnel uses Cloudflare's transport, but inner TLS is terminated by Anthropic's proxy using a certificate that only you control. Cloudflare cannot decrypt payloads. Anthropic does not connect to a tunnel until your certificate is registered, so traffic is encrypted any time it crosses the network.

Do credentials live in the sandbox?

No. Credentials for tools live in a separate vault. A proxy fetches and decrypts them only when a tool call needs them. The sandbox process never holds the long-lived token. This is a meaningful improvement over the common pattern of injecting secrets into a container at startup.

Bottom line

Self-hosted sandboxes and MCP tunnels are the missing pieces for running hosted AI agents against real enterprise systems. If your data has been the reason you have not run a Claude agent in production, the answer changes now. The agent loop runs at Anthropic. The execution and the data path run inside your perimeter. Setup is non-trivial but the architecture is clean, and the cleanest test is to wire up one internal MCP server and one self-hosted sandbox against a non-critical workflow before you commit anything to production.

*Want help designing a Claude agent against your internal systems? Book a call with us.*

Related articles