Anthropic self-hosted sandboxes and MCP tunnels: how Indian and UK builders deploy the new perimeter primitives

What Anthropic actually shipped on 19 May 2026

At Code with Claude London on 19 May 2026, Anthropic added two production-grade primitives to its Managed Agents offering: self-hosted sandboxes and MCP tunnels. The framing was deliberate. Both let regulated teams keep tool execution and data plane inside their own perimeter while still using the Claude agent loop hosted by Anthropic.

Self-hosted sandboxes are in public beta. MCP tunnels are in research preview. That distinction matters for procurement. Public beta is generally signed off for production with the usual change-control disclaimers. Research preview tells your security team the interface will move, the SLAs are aspirational, and you should pin SDK versions hard.

The headline phrasing from the launch — repeated across coverage from The New Stack, InfoQ and The Decoder — is that "the agent's code, filesystem, and network egress never leave your environment". That single sentence is doing a lot of work for compliance teams in regulated sectors. We unpack what it actually means and how to deploy it below.

The perimeter problem these primitives solve

Until 19 May, hosted Managed Agents had a familiar tradeoff. You got Anthropic's orchestration, error recovery and context management for free, but the tool-execution sandbox lived on Anthropic infrastructure. For any agent that read a private repository, queried an internal database, or called a service behind a firewall, three uncomfortable patterns appeared:

• Egress sprawl — secrets and tokens had to traverse to Anthropic-side workers, then back to your VPC.
• Inbound firewall holes — if Anthropic needed to reach your service, you opened ports on a public IP and added Anthropic's IP ranges to an allowlist.
• Data residency awkwardness — for a Bengaluru fintech under DPDP or a London insurer under the draft UK Frontier AI Bill, the agent's working set briefly left the perimeter, which is exactly the question regulators ask about.

Self-hosted sandboxes close the first problem. MCP tunnels close the second. Together they make the third question much easier to answer.

Self-hosted sandboxes — architecture and the four launch partners

A self-hosted sandbox is an isolated execution environment that runs the actual tool code (Python, shell, browser automation, network calls) inside your infrastructure. Anthropic's orchestrator drives it through a lifecycle interface — create, exec, snapshot, destroy — but never touches the contents.

Four managed sandbox providers are integrated at launch:

Deploy option	Where execution lives	Best for	Trade-off
Anthropic-managed sandbox	Anthropic's data plane	Prototypes, low-sensitivity workloads	Simplest setup, but your data crosses the boundary
Self-hosted via Cloudflare	Cloudflare Workers / Sandbox at the edge	Latency-sensitive global agents, IN + UK edge presence	Edge runtime constraints (no long-running native processes)
Self-hosted via Daytona	Daytona dev environment containers	Coding agents with full Linux toolchain access	Higher cold-start cost than edge options
Self-hosted via Modal	Modal serverless GPUs / CPUs	Agents that mix Python tool calls with GPU-bound steps	Modal's runtime is opinionated — bring Modal patterns
Self-hosted via Vercel	Vercel Sandbox in your Vercel account	Teams already on Vercel for the web app	Tied to Vercel pricing curves; less flexible egress controls

You can also implement the lifecycle interface against your own runtime — Kubernetes jobs, Firecracker microVMs, ECS tasks — but the four managed options cover the common cases. The Agent SDK hosting documentation on platform.claude.com is the canonical reference for the lifecycle contract.

MCP tunnels — outbound-only, no inbound holes

The second primitive solves a different problem. An MCP server is the way you expose tools and data sources to a Claude agent. Before tunnels, exposing a private MCP server meant standing up a publicly reachable endpoint, putting Anthropic's IP allowlist in front of it, and praying nobody else figured out the URL.

MCP tunnels invert that. Your MCP server stays private. It dials out to a tunnel endpoint and the agent loop reaches it through the established outbound connection. There is no inbound port to open, no public-internet exposure, and no Anthropic IP allowlisting to maintain. The pattern will be familiar to anyone who has run Cloudflare Tunnel, ngrok, or Tailscale Funnel for similar reasons.

Primitive	What it moves inside the perimeter	What it does NOT cover	When to use
Self-hosted sandbox	Tool execution — code, filesystem, network egress from the sandbox	The model itself; the agent loop; conversation memory storage	Whenever the tool touches sensitive data or proprietary code
MCP tunnel	Inbound reachability of a private MCP server — replaced with outbound dial-out	Egress from the tool itself; sandbox lifecycle	Whenever an MCP server has to live behind a firewall (most internal systems)
Both together	Full data-plane perimeter for the agent's execution side	Model inference (still Anthropic-hosted)	Regulated workloads — DPDP-aligned IN finance, UK Frontier Bill perimeter shops

Deploy path 1: Cloudflare-backed sandbox (concrete steps)

For a London or Bengaluru team that wants the lowest-latency edge option, Cloudflare is the path of least resistance. The deployment is roughly:

1. Provision a Cloudflare account with Workers and the Sandbox feature enabled.
2. Install the Agent SDK and configure the sandbox provider to Cloudflare via environment variables.
3. Create an MCP tunnel for any private MCP servers your agent needs to reach.
4. Point the orchestrator at your sandbox lifecycle endpoint.

A minimal environment configuration looks like this:

# Self-hosted sandbox config (Cloudflare-backed)
SANDBOX_PROVIDER=cloudflare
SANDBOX_REGION=eu-west
CLOUDFLARE_ACCOUNT_ID=<your account id>
CLOUDFLARE_API_TOKEN=<scoped token, sandbox:write only>

# MCP tunnel for the private MCP server
MCP_TUNNEL_URL=https://your-private-mcp.tunnel.anthropic.com/agent-X
MCP_TUNNEL_TOKEN=<tunnel-side bearer>

# Agent SDK
ANTHROPIC_API_KEY=<your standard key>
ANTHROPIC_MANAGED_AGENT_ID=agent_2026_eu_west_01

Deploy path 2: Modal or Vercel-backed sandbox (concrete steps)

If your agent does heavier lifting — GPU-bound transcription, long-running Python toolchains, browser automation with stateful sessions — Modal is the more sensible pick. Vercel is the obvious choice if your team already runs the front-end and the agent is an extension of an existing Vercel deployment.

Modal in particular shines for two patterns common in IN and UK fintech: PII redaction pipelines and document-parsing tool calls that benefit from a warm GPU. Modal's sandbox snapshots also map cleanly onto Anthropic's lifecycle interface, so the cold-start tax is lower than it first looks.

An equivalent Modal-backed environment block:

# Self-hosted sandbox config (Modal-backed)
SANDBOX_PROVIDER=modal
MODAL_TOKEN_ID=<modal token id>
MODAL_TOKEN_SECRET=<modal token secret>
MODAL_APP_NAME=aitc-agent-sandbox
MODAL_REGION=us-east

# Optional GPU class for tool steps that need it
MODAL_GPU=A10G
MODAL_TIMEOUT_S=300

# Tunnel for the private MCP server (same as Cloudflare path)
MCP_TUNNEL_URL=https://internal-mcp.tunnel.anthropic.com/agent-X
MCP_TUNNEL_TOKEN=<tunnel-side bearer>

What you still cannot do (AWS, memory, on-prem inference)

The launch press was careful to flag three known gaps, and your security review will thank you for knowing them up front:

1. Claude Platform on AWS is not yet supported. If your enterprise procurement insists on the AWS Marketplace route, you are still on the older managed-sandbox model. Anthropic has signalled this is on the roadmap but has not committed to a date.
2. Memory is not yet supported in self-hosted mode. If your agent uses Anthropic's memory feature for cross-session recall, you currently have to choose between memory and self-hosted sandboxes. Most teams we have spoken to pick the perimeter and rebuild memory on their side.
3. Fully on-prem inference is not possible. This is a perimeter feature for the execution side. The model still runs on Anthropic. If your regulator demands the weights live inside your VPC, you are still looking at open-weight models routed through a sovereign inference stack — see our coverage of GLM-4.7 on non-NVIDIA hardware for the open-weight side of that picture.

What this means for DPDP-aligned IN teams and UK Frontier Bill perimeter shops

For Indian teams under the Digital Personal Data Protection Act, the perimeter primitives close a specific class of compliance question. Until 19 May, a Claude-driven agent that read customer KYC records was technically processing personal data on Anthropic infrastructure during the tool call — a defensible but awkward position. With self-hosted sandboxes and MCP tunnels in the path, the agent's view of the KYC record never leaves the regional VPC. Only the structured tool result (and not the raw underlying record) crosses to the orchestrator.

For UK teams watching the draft Frontier AI Bill, the calculus is similar but the framing is different. The Bill's working drafts have circled around perimeter-control language — what leaves your environment, who can audit the data flow, how isolation is enforced. Self-hosted sandboxes plus MCP tunnels give a defensible architectural answer to all three.

Neither solves the harder question of model residency. If your regulator cares about where the model weights live (not just where the tool runs), this launch does not change that picture. That conversation still belongs to the open-weight side of the market — see our MCP 2026 roadmap coverage for where the open MCP ecosystem is heading.

Five gotchas builders are already hitting

1. Snapshot semantics differ by provider. Cloudflare snapshots are cheap and fast but ephemeral; Modal snapshots persist longer but cost more. The orchestrator does not care, but your bill does — model the cost early.
2. Tunnel reconnect storms. If your MCP server restarts during heavy load, the tunnel can take 10–30 seconds to re-establish. Wrap MCP calls in retry-with-backoff or your agent will hand the user a confusing failure during deploy windows.
3. Egress controls are your job. The sandbox runs in your account, which means your egress policy applies. A surprised security team will block legitimate tool calls because the sandbox's egress was not whitelisted. Audit the agent's expected external calls before go-live.
4. Logging is split. Orchestration logs are on Anthropic; tool execution logs are on your sandbox provider. Stitch them with a shared correlation ID at the agent boundary or post-incident analysis becomes painful.
5. Cold-start variance. First sandbox of a session is slow — typically 800ms–3s depending on provider. Pre-warm at session start with a no-op tool call if your UX is sensitive to first-token latency.

For broader context on where Managed Agents fits in the Anthropic ecosystem, see our Claude Managed Agents beta getting-started guide, and for the open-source alternative pattern see Cline's open-sourced agent runtime from earlier this month.