Originally published at devtoolpicks.com

---

Anthropic held its Code with Claude London event on May 19, 2026, and shipped two new features for Claude Managed Agents: self-hosted sandboxes in public beta and MCP tunnels in research preview. Here is what they actually are and who needs them.

What Is Claude Managed Agents

Before getting into the new features, a quick frame: Claude Managed Agents is Anthropic's hosted infrastructure for running long, tool-heavy agentic sessions. It handles the agent loop, which includes orchestration, context management, and error recovery. Today's updates change where some of that work runs, specifically tool execution and private network access.

What Self-Hosted Sandboxes Actually Do

By default, when Claude Managed Agents runs tools (executes code, browses files, calls external services) that execution happens inside Anthropic-managed cloud containers. Self-hosted sandboxes move that tool execution layer into infrastructure you control.

Your files, code, and network egress stay inside your environment. You keep your own network policies, audit logging, and security tooling applied. You also control the compute: resource sizing, runtime image, and capacity for long builds or intensive tasks.

Supported providers at launch:

• Cloudflare: microVMs and lighter isolates, good for short stateless tasks
• Modal: GPU-ready sandboxes, suited for compute-heavy agentic work
• Vercel: low-latency VM sandboxes with tight network injection
• Daytona: long-lived VMs, better for sessions that run over time
• Your own infrastructure: bring any container environment you control

This is where the important caveat lives: the agent loop itself does not move. Orchestration, context management, and error handling still run on Anthropic's servers. Orchestration metadata still flows through Anthropic even when tool execution stays local. Self-hosted sandboxes are not fully on-premise deployment. If your compliance requirement is that nothing touches external infrastructure at all, this does not fully solve that problem yet.

Two additional limitations to know upfront: self-hosted sandboxes are not yet available on the Claude Platform on AWS, and Memory is not yet supported in self-hosted sessions.

What MCP Tunnels Do

MCP tunnels solve a different but related problem. If you have MCP servers running inside your private network (a private database, an internal API, a knowledge base, a ticketing system) and you want Claude agents to call those servers as tools, the standard approach requires making those servers publicly accessible. Most companies do not want that.

MCP tunnels create a secure path without public exposure. A lightweight gateway runs in your environment and opens a single outbound connection to Anthropic's routing infrastructure. No inbound firewall rules. No public endpoints. Traffic is encrypted end to end. Claude reaches your private MCP server through that tunnel.

The setup is managed through workspace settings in the Claude Console by organization admins. MCP tunnels work with both Claude Managed Agents and the Messages API, so they are not limited to the agentic product.

MCP tunnels are in research preview, not public beta. You need to request access to try them. The documentation uses explicit "as-is" language, so treat it as an early program rather than a production-ready feature.

What This Means for Indie Hackers

For most indie hackers building early-stage SaaS products, neither feature is immediately necessary.

Self-hosted sandboxes become relevant when you start winning enterprise clients who have security review processes, when you handle regulated data that cannot leave a network boundary, or when you build for industries like healthcare, finance, or government where compliance frameworks restrict where code executes.

MCP tunnels are more immediately useful for developers at any stage who want to connect Claude agents to a private development database or internal API without a public endpoint. If you have been avoiding connecting Claude to internal services because of the exposure requirement, MCP tunnels change that calculus.

The practical question to ask: does your product handle data that needs to stay in a specific network boundary, or do you need Claude to reach services you cannot make public? If yes to either, read through the documentation on platform.claude.com. If no, Anthropic-managed execution remains the simpler path.

For context on how this fits with the broader changes Anthropic has been making to how Claude subscriptions and agent usage are billed, we covered the June 15 subscription split and the earlier Claude Platform on AWS launch. The self-hosted sandboxes are part of the same enterprise build-out.

The Honest Take

This is a genuine step toward enterprise readiness for Claude agents. Moving tool execution into a customer's own infrastructure is a meaningful architectural decision that addresses real compliance blockers that have been stopping some companies from adopting Claude agents at all.

The honest limitation is that the agent loop stays on Anthropic. For the strictest compliance requirements, that matters. For most enterprise use cases, tool execution in your perimeter is enough to clear procurement and security review.

For solo founders at early stage, this is worth bookmarking rather than acting on today. If you are building something that will eventually need to pass a security review or handle regulated data, the fact that this option now exists matters for your roadmap. If you are currently using Claude Code or other alternatives and debating the Claude ecosystem, this strengthens the case for building on Claude's platform long-term.