ARTICLES ·2026-05-31 ·BY EFFLOOW CONTENT FACTORY

Anthropic Self-Hosted Sandboxes: Worker Pattern PoC

A local sandbox PoC for Claude Managed Agents self-hosted sandboxes, covering the worker loop, security boundary, and deployment tradeoffs.

anthropic claude-managed-agents self-hosted-sandboxes agent-infrastructure sandbox-security ai-agents developer-tools

Anthropic Self-Hosted Sandboxes: Worker Pattern PoC

Anthropic's self-hosted sandboxes for Claude Managed Agents are easy to misread. They do not make Claude fully self-hosted. They do not move model inference into your cluster. They move the tool-execution environment: the filesystem, shell, code execution, network egress, and runtime image that an agent uses while working.

That distinction matters for engineering teams. The managed agent loop still lives on Anthropic's side. The execution boundary can live on your side.

Effloow Lab ran a small local sandbox PoC for this article. The PoC did not call Anthropic's API, did not use credentials, and did not test a production provider. It simulated the worker pattern described in Anthropic's documentation: claim work from an environment queue, keep it alive, run tool execution in a per-session workspace, and post results back. The lab note is saved at data/lab-runs/anthropic-self-hosted-sandboxes-managed-agents-poc-2026.md.

What Anthropic Announced

Anthropic announced self-hosted sandboxes and MCP tunnels for Claude Managed Agents on May 19, 2026. In that announcement, self-hosted sandboxes are listed as a public beta on Claude Platform, while MCP tunnels are a research preview.

The key product claim is a split of responsibility. Claude Managed Agents still handles the model-facing agent loop, orchestration, session state, context management, and recovery behavior. The sandbox where tool calls execute can run on infrastructure controlled by the customer or by supported sandbox providers such as Cloudflare, Daytona, Modal, and Vercel.

Anthropic's self-hosted sandbox docs describe the change in practical terms: cloud environments run tools in Anthropic-managed sandboxes, while self-hosted environments run tools in your infrastructure. Network reach becomes your network policy. File and repository mounting become your job. Runtime lifecycle becomes your job.

This is why self-hosted sandboxes are most relevant for agents that need to touch internal services, private repositories, restricted datasets, or controlled egress routes. It is less relevant for simple public-web research agents where Anthropic-hosted execution is already acceptable.

The Architecture in One Sentence

A self-hosted sandbox is an environment worker plus a sandbox runtime.

Anthropic's control plane creates work. Your worker polls or wakes, claims that work, starts or reuses a per-session execution context, runs local tool calls, and posts structured results back to the managed session.

That means the important production design is not just "run a container." It is a queue-connected lifecycle:

Create a Managed Agents session that targets a self-hosted environment.
Anthropic enqueues work for that environment.
Your worker claims the work item.
Your worker creates or attaches to a per-session sandbox.
The sandbox executes filesystem, shell, and code operations.
The worker sends the result back to the session stream.
Monitoring tracks queue depth, pending work, liveness, failures, and cleanup.

The official docs say the ant CLI supports an always-on worker pattern, while SDK helpers support both always-on and webhook-triggered patterns. They also document a lower-level Environments Work API for teams that need a custom worker. For a regulated production system, that lower-level path is probably where architecture review will spend most of its time.

What Effloow Lab Reproduced Locally

The local PoC was intentionally small. It used Python 3.12.8 and only the standard library. It created a fake environment queue with three work items:

WORK_ITEMS = [
    {"session_id": "sess_local_001", "work_id": "work_001", "tool": "write_file"},
    {"session_id": "sess_local_001", "work_id": "work_002", "tool": "read_file"},
    {"session_id": "sess_local_002", "work_id": "work_003", "tool": "shell"},
]

The worker loop claimed each item, recorded a keepalive, executed it in a temporary per-session workspace, and appended a result payload. The first session wrote report.txt, then read it back. The second session ran a safe python3 -c command in a separate workspace.

The resulting output showed:

claimed_count: 3
keepalive_count: 3
work_001: wrote sess_local_001/workspace/report.txt
work_002: read "hello from a claimed self-hosted work item"
work_003: stdout "sandbox argv ok"

This does not prove Anthropic's beta is production-ready. It does confirm the developer mental model: the worker is the bridge between a managed orchestration plane and local execution contexts. If that bridge is weak, the sandbox feature will not save you.

What the PoC Did Not Test

The PoC did not create a real Anthropic environment, did not generate an environment key, did not start a real Claude Managed Agents session, and did not use the ant CLI or SDK worker helpers. It also did not test any managed sandbox provider.

It did not validate:

Linux isolation strength
container image hardening
egress policy enforcement
environment key rotation
queue latency or throughput
billing behavior
hosted provider limits
live model behavior
MCP tunnel connectivity
Anthropic vault behavior
Claude Platform on AWS differences

Those limitations are not footnotes. They are the actual production checklist. A local queue simulation can help developers understand the control flow, but security and operations still need a real provider-level evaluation.

The Security Boundary Is Shared, Not Outsourced

Anthropic's self-hosted sandbox security model is direct about the split. Anthropic secures the control plane, including session and work-queue integrity. When you self-host, you own the sandbox image, network egress, environment key handling, workload isolation, tool-execution permissions, and data retention for content your worker processes.

That is the right model, but it means teams should avoid a false sense of safety. Moving tool execution into your infrastructure gives you more control. It also gives you more responsibility.

In practice, a production self-hosted sandbox should start from a deny-by-default posture:

run the worker without an organization-scoped API key on the sandbox host unless there is a hard reason
store ANTHROPIC_ENVIRONMENT_KEY in a secrets manager, not in a repository or image layer
run tool processes as a non-root user
mount only the directories the agent needs
restrict outbound traffic to explicit destinations
preserve enough logs to debug tool actions without leaking unnecessary session content
separate trust boundaries with separate environments, not just naming conventions

If an agent can execute arbitrary commands in a broad internal network, the security conversation has not been solved. It has been relocated.

Self-Hosted Sandboxes vs MCP Tunnels

Self-hosted sandboxes and MCP tunnels are related, but they solve different problems.

Self-hosted sandboxes answer: where does the agent's code and shell execution run?

MCP tunnels answer: how does Claude reach private MCP servers without exposing those servers publicly?

Anthropic's docs describe them as independent. A cloud-hosted sandbox can still use an MCP tunnel. A self-hosted sandbox can use public or tunneled MCP servers. The strongest enterprise pattern may use both: local execution for code and filesystem work, tunneled MCP access for private business systems.

For developers, the trap is treating "private MCP access" and "private code execution" as the same control. They are not. If the agent needs to run npm test against a private repository, sandbox placement matters. If it needs to call an internal ticketing MCP server, tunnel placement matters. If it needs both, you need both controls.

The earlier Effloow article on Claude MCP tunnels covers that tunnel side in more detail. This article focuses on the execution side.

Provider Patterns: Cloudflare, Daytona, Vercel, Modal

The provider ecosystem is already shaping how teams will evaluate self-hosted sandboxes.

Cloudflare's integration emphasizes sandbox control, observability, customizable outbound proxies, private-service connectivity, browser tooling, and lightweight V8-isolate-based execution for workloads that do not need a full microVM.

Daytona's guide is useful because it states the split cleanly: Anthropic runs the API, agent loop, and per-environment work queue; the customer runs the application and orchestrator; Daytona provides sandbox containers. It also notes that filesystem and shell tools dispatch inside the Daytona sandbox, while web tools and MCP server tools are dispatched server-side by Anthropic.

Vercel's changelog frames its Sandbox integration around per-session Firecracker microVMs, credential brokering at the firewall, deny-by-default egress, and private-network connectivity.

Modal appears in Anthropic's supported provider list, but for this run Effloow Lab did not inspect or execute Modal's reference implementation. Treat Modal-specific runtime details as [DATA NOT AVAILABLE] unless you verify the current provider guide directly.

The practical takeaway: "self-hosted" does not mean one deployment shape. A browser-heavy QA agent, a long-running coding agent, and a data-processing agent may belong on different sandbox primitives.

When Developers Should Care

Self-hosted sandboxes are worth evaluating when an agent needs one or more of these capabilities:

private repository access without cloning code into Anthropic-managed infrastructure
internal package registry access
VPC-only APIs or databases
custom runtime images with pinned build tools
strict egress inspection
session-level file persistence
audit logs tied to existing infrastructure controls
larger or specialized compute than a default managed sandbox allows

They are probably overkill when the agent is only summarizing public URLs, writing public documentation, or calling remote tools that already have scoped credentials.

The best early use case is not "let an agent roam the company network." It is a narrow, high-value execution lane: a single repository family, a controlled build image, a small set of allowed outbound services, and an audit trail that can answer what the agent executed and why.

Implementation Checklist

Before adopting the beta, a team should answer these questions:

Which tools actually run inside the sandbox, and which stay server-side?
What session metadata is allowed to influence mounts, secrets, or network access?
How is the environment key stored, rotated, and scoped?
What prevents one tenant or project from reaching another tenant's workspace?
What is the default outbound network policy?
What logs are retained, redacted, shipped, or deleted?
How are stuck sessions stopped?
What alert fires when queue depth grows or workers stop polling?
Who owns the sandbox image supply chain?
What does rollback look like if the provider integration changes?

Those questions are more important than a demo that successfully runs ls. The value of self-hosted sandboxes is not that agents can execute commands. Agents could already execute commands in managed sandboxes. The value is that your organization can wrap that execution in its own infrastructure controls.

FAQ

Q: Are Anthropic self-hosted sandboxes the same as self-hosting Claude?

No. The model and managed orchestration remain on Anthropic's side. Self-hosted sandboxes move tool execution into infrastructure you control.

Q: Do self-hosted sandboxes replace MCP tunnels?

No. Self-hosted sandboxes control where code and shell execution happen. MCP tunnels control private access to MCP servers. They can be used separately or together.

Q: Can this be used on Claude Platform on AWS?

Anthropic's docs say self-hosted sandboxes are not yet available on Claude Platform on AWS in the same way as Claude Platform. The docs also describe AWS-specific worker authentication differences. Verify the current AWS docs before designing around that path.

Q: Did Effloow Lab test a live Anthropic self-hosted environment?

No. Effloow Lab ran a local stdlib simulation of the worker queue pattern. No Anthropic API calls, credentials, provider sandboxes, MCP tunnels, or live Claude sessions were used.

Bottom Line

Anthropic self-hosted sandboxes are best understood as a runtime-control feature, not a fully self-hosted Claude product. The promising part is the clean queue-worker split; the hard part is everything your team now owns around isolation, egress, secrets, and observability.

For developer teams building serious agents, this is a useful direction. Managed orchestration plus controlled execution is a more realistic enterprise architecture than forcing every team to build agent loops, context recovery, queueing, sandboxing, and audit controls from scratch.

But the beta should be evaluated with production skepticism. Start with a small worker, a narrow tool surface, no broad internal-network access, and a clear incident plan. If the worker can claim work, execute in a constrained session workspace, post results, and leave a useful audit trail, then the architecture becomes worth expanding.

Sources

Need content like this
for your blog?

We run AI-powered technical blogs. Start with a free 3-article pilot.

Learn more →