This week Anthropic's developer account announced new integration guides for running Claude Managed Agents in sandboxes you control — adding Blaxel, E2B, Google Cloud, Namespace, and Superserve to a roster that now spans nine providers. On the surface it reads like a routine docs update. Underneath it is one of the more interesting architectural patterns in agent infrastructure right now: a clean split between the part of an AI agent that thinks and the part that acts, with the acting half running on your own machines.
For any team weighing how to deploy autonomous agents without handing a model unrestricted access to their environment, the design is worth understanding regardless of which vendor you use. Here's what Claude Managed Agents are, how the self-hosted sandbox architecture works, and the engineering lesson that outlives the announcement.
What Claude Managed Agents Actually Are
Anthropic exposes two very different ways to build on its models. The Messages API gives you direct model access — you write the agent loop, manage context, handle tool calls, and own every retry. Claude Managed Agents is the opposite trade: a pre-built, configurable agent harness that runs in managed infrastructure. As Anthropic's docs put it, "instead of building your own agent loop, tool execution, and runtime, you get a fully managed environment where Claude can read files, run commands, browse the web, and execute code securely."
In other words, Anthropic runs the orchestration: the model, the agent loop, context management, and error recovery. You configure the agent and point it at work. The platform organizes everything around four concepts — the Agent (its configuration and skills), the Environment (where execution happens), the Session (a single run), and Events (the stream of what occurred). This is the "long-horizon agent work" tier: tasks that run for many steps, where managing the loop yourself is the expensive part.
That framing matters because it's easy to confuse this with the Claude Agent SDK, which is a distinct product for running the loop in your own code. Managed Agents is the hosted version — Anthropic holds the reins.
Brain and Hands: The Core Split
The architectural idea at the center of all this, described in Anthropic's own engineering write-up, is the decoupling of "the brain (Claude and its harness) from the hands (sandboxes and tools that perform actions)." The harness lives outside the sandbox and calls into it the way it would call any other tool — conceptually, execute(name, input) -> string, with containers provisioned on demand. In their words, "the container became cattle": disposable, replaceable, owning none of the intelligence.
This is a familiar separation of concerns dressed in new clothes. The reasoning is stateful, valuable, and central; the execution environment is ephemeral and treated as fungible. Once you draw that line cleanly, a useful question follows: if the hands are just a sandbox the brain calls into, does that sandbox have to live on Anthropic's infrastructure? The answer the new guides deliver is no.
How Self-Hosted Sandboxes Work
A standard Managed Agent runs its tool execution in an Anthropic-managed cloud sandbox. The self-hosted option moves only that execution onto infrastructure you control — "so the agent's code, filesystem, and network egress never leave your environment." The mechanism is an environment worker: a process you run on your own machines that receives tool-execution requests and runs them locally.
The flow is a work queue, and it's worth tracing because the security model falls directly out of it:
- A session is assigned to your
self_hostedenvironment, and Anthropic enqueues it as a work item. - Your worker — authenticating with an
ANTHROPIC_ENVIRONMENT_KEYservice key — claims work items from that queue. - For each item, the worker spawns an execution context, downloads the agent's skills, runs the tool calls, and posts the results back.
Crucially, the queue is polled by your worker outbound; Anthropic doesn't reach into your network. Tooling supports this directly — an EnvironmentWorker SDK helper and an ant beta:worker run / poll CLI — and the org API key you use to create sessions and read stats is deliberately separate from the environment service key the worker uses.
The honest caveat: self-hosted does not mean air-gapped. Tool inputs and outputs still flow to Anthropic's control plane, because that's where Claude runs and reasons about what to do next. Anthropic's docs are explicit that orchestration metadata transits their side and that Managed Agents is not ZDR- or HIPAA-BAA-eligible. What you gain is that the code execution, filesystem, and egress stay home — which is the part that matters most for running untrusted code and for data-residency posture.
The Security Model Is the Point
The reason to care about any of this is captured in one line from Anthropic's engineering post: the fix was "to make sure the tokens are never reachable from the sandbox where Claude's generated code runs." That sentence is the whole motivation for sandboxing AI agents.
An autonomous agent writes and runs code. That code is, by definition, not code you reviewed. If it executes in the same context that holds your Git tokens, cloud credentials, and database passwords, a prompt injection or a model mistake becomes a credential leak. The Managed Agents design routes around this structurally: Git access tokens get wired into the sandbox's local git remote at init without the harness ever seeing them, and MCP OAuth tokens live in a vault reached through a dedicated proxy keyed to the session. The agent can use a credential's capability without ever being able to read the credential.
Self-hosting extends that into a shared-responsibility model. Anthropic secures the control plane — session and work-queue integrity, multi-tenant isolation, minimizing what context the agent carries. You secure the sandbox: hardening the image, controlling network egress, storing and rotating the service key, isolating untrusted workloads, limiting the blast radius of any single tool call, and managing log retention. Anthropic's docs are blunt about the division — once session content reaches your worker, they have "no visibility into what your worker does with" it, and they cannot verify your worker build, isolate tools inside your sandbox, or instantly invalidate a leaked key for you. That's your job. This is the same instinct we've argued for in deciding when automation should ask for approval: the more autonomous the actor, the more the guardrails have to be structural rather than hopeful.
The Provider Lineup
Anthropic's docs now list nine self-hosted sandbox guides, and the appeal is bring-your-own-infrastructure choice — pick the runtime that matches your isolation, latency, and operational needs:
- E2B — isolated sandbox infrastructure with a ready-made webhooks template; the guide states plainly that "Claude runs the agentic loop and reasoning process" while E2B "provides isolated sandbox infrastructure for the environment where tool calls execute."
- Google GKE Agent Sandbox — an official reference implementation deploying gVisor-isolated worker pods on GKE, with a dispatcher that polls the work queue, warm pools for low cold-start latency, locked-down egress, and queue-depth-driven autoscaling.
- Namespace — ephemeral per-task Devboxes: each agent task gets a fresh box provisioned on demand and torn down on completion, so "no state carried over, no credentials left behind, no filesystem noise from prior work."
- Superserve — Firecracker microVMs with persistent state and versioned filesystems, aimed at agents that need durable workspaces rather than throwaway ones.
- Blaxel — sandboxes that expose a Model Context Protocol server, letting the agent drive process management and filesystem operations through tool calls.
- Cloudflare, Daytona, Modal, and Vercel round out the list, each mapping the same worker pattern onto its own container runtime.
The shape is consistent across all of them: same brain, same work-queue protocol, your choice of hands. Two contrasts worth noting for your own selection — Namespace's ephemeral-per-task model versus Superserve's persistent versioned filesystems is a real fork in the road, and GKE's gVisor-on-Kubernetes approach is the heaviest but most controllable option.
The Lesson Beyond the Announcement
You don't have to adopt Claude Managed Agents to take something from its design. The durable idea is that an AI agent should be built as two separable systems — a reasoning plane and an execution plane — with a hard, auditable boundary between them, and credentials parked entirely on the far side of that boundary from any model-generated code.
That principle generalizes to any agent you build, on any stack:
- Treat model-generated code as untrusted input. It belongs in a sandbox with a defined blast radius, not in the process holding your secrets. This is the agent-era version of the fragility discipline we wrote about in using AI features without making the product fragile.
- Give capabilities, not credentials. A proxy that injects a token the agent can never read beats handing the token to the agent and hoping. Capability-not-credential is the structural fix, and it's reusable far outside agents.
- Make the execution environment disposable. Cattle, not pets. Fresh sandbox per task, torn down after, removes a whole class of cross-session leakage — and keeps you from over-engineering durable state you don't need, in the spirit of building reliable systems without overengineering.
Claude Managed Agents is in public beta as of June 2026, the API surfaces carry beta headers and will shift, and "self-hosted" still routes orchestration through Anthropic — so read the fine print before betting compliance on it. But the architecture it ships is a clear, well-reasoned answer to the central question of the agent era: how do you let a model act in the world without giving it the keys to everything? Separate the brain from the hands, and keep the keys where the hands can't reach.
Reporting based on Anthropic's Managed Agents documentation, its self-hosted sandboxes and security guides, its engineering write-up, and the E2B, Google Cloud, Namespace, Superserve, and Cloudflare provider guides. Feature in public beta; details current as of June 13, 2026.
