cchu@nycu:~/blog$ cat agent-sandbox-data-plane.md

2026.07.1415 min[ai-agents][sandbox][infrastructure][security]

Agent Sandbox as the Data Plane for Managed Agents

A practical note on why Claude Managed Agents split the brain from the hands, how BYOI sandboxes change the trust boundary, and why E2B, CubeSandbox, Kubernetes Agent Sandbox, Cloudflare, Modal, Vercel, Daytona, and NAP all feel like different answers to the same data-plane question.

The agent sandbox is easy to describe in a boring way: it is the place where an AI agent runs code, edits files, opens a browser, downloads things, and maybe talks to private services.

But that boring sentence is hiding the real story. For a serious agent product, the sandbox is not just a container bolted onto the side. It is the data plane of the agent system.

The model and the harness decide what should happen. The sandbox is where that decision touches the messy world: repo checkout, shell command, browser session, credentials, network egress, generated artifact, logs, and sometimes a very expensive mistake. Ngl, this is the part where agent infra stops being a cute demo and starts becoming actual infrastructure.

Claude Managed Agents made this architecture more explicit by splitting the "brain" from the "hands": session state and orchestration live in one place, while tool execution can happen in another place. That split is small on the diagram, but huge in product shape.

AI managed agents brain-hands architecture

My mental model: the agent brain keeps durable session memory and decides the next tool call; the sandbox data plane owns execution, files, network, and artifacts. The magic is not one container, it is the contract between them.

This post is my attempt to sort the landscape:

Claude Managed Agents gives a clean vocabulary: session, harness, sandbox.
Self-hosted sandboxes turn the sandbox into "bring your own infra" instead of vendor-owned compute.
Neutree Agent Platform feels like a control plane for teams that want to host and distribute agents, while keeping infrastructure choices open.
E2B, CubeSandbox, Kubernetes Agent Sandbox, Cloudflare, Modal, Vercel, and Daytona are different answers to the same question: what should the agent hands run on?

I started thinking about this after watching some Chinese infra discussions around agent runtime and after reading through the new Managed Agents docs. The framing that finally clicked for me was: agent platforms are not only prompt orchestration systems. They are also sandbox operating systems, just with a nicer API and more chaos.

Claude Managed Agents and the Brain/Hands Split

Anthropic's Managed Agents write-up describes three virtualized parts of an agent:

Part	What it does	Why it matters
Session	An append-only history of what happened, including conversation, actions, and outputs.	The agent can pause, resume, and survive failures without treating a container as the source of truth.
Harness	The loop that calls Claude, manages context, and routes tool calls.	The orchestration layer can stay relatively stateless and rebuild itself from the session.
Sandbox	The execution environment where the agent runs tools, code, and file operations.	The dangerous part gets an explicit trust boundary instead of living inside the model loop.

That separation is the big deal. A naive agent product usually makes the container feel like the agent. The process is running, the filesystem has the files, maybe the browser profile is there, so we think this is the agent's state.

But that is a little bit backwards. A container is a temporary body. The session is closer to the agent's durable memory. The harness is the brain stem. The sandbox is the hand that can touch production-shaped things.

This seperation matters because it gives the platform permission to kill, replace, pause, snapshot, or migrate the sandbox without losing the whole agent. It also lets the platform say: "the model can request a command, but the command happens through a controlled data-plane endpoint."

In the cleanest shape, the harness only sees a tool contract like:

execute(name, input) -> result

Behind that small function call there can be a cloud sandbox, a self-hosted worker, a Kubernetes pod, a Firecracker microVM, a browser service, an MCP gateway, a vault proxy, and an audit log. The model does not need to know all of that. Actually, most of the time it should not know.

This is why I like the brain/hands wording. It is simple, maybe too simple, but it keeps the architecture honest. The brain should not smuggle secrets in its thoughts. The hands should not become the brain.

Session Is Not the Context Window

One common confusion is to treat the session as a bigger context window. It is not.

The context window is what the model can see in one call. The session is the durable event history that the platform can slice, compact, summarize, index, or replay into future calls. Context compaction, memory tools, and trimming are strategies for feeding the model. They are not the same thing as owning session state.

For Managed Agents, this distinction is extra important. If the agent works for hours or days, the platform cannot just keep a very long chat transcript in memory and hope vibes will carry it. The harness needs a durable session log, and it needs rules for deciding what part of that log becomes context.

The sandbox also has state, but it is a different kind:

working directory
installed dependencies
running processes
browser profile
generated files
downloaded artifacts
maybe a private network tunnel

This state is useful, but it is not the source of truth for the agent story. If the sandbox disappears, the platform should be able to reconstruct enough from the session and artifacts to continue. If it cannot, then the sandbox is not just hands anymore; it became the memory, and that gets messy fast.

The Sandbox Is a Security Boundary, Not a Convenience Box

Sandboxing is often sold as convenience: run code safely, install packages, isolate dependencies. All true. But for agents, convenience is the least interesting part.

The real reason is that agents are weird users. They follow instructions, they read untrusted text, they may copy commands from a README, they can be prompt-injected through a webpage, and they will happily combine all of this with filesystem and network access. So the sandbox is the line between "the model said something" and "the computer did something."

Claude Code's sandboxing work focuses on filesystem and network isolation. That is the core shape:

Filesystem isolation: the agent should only read/write what the task allows.
Network isolation: the agent should only reach domains and services that make sense for the task.
Credential isolation: secrets should be brokered, scoped, and short-lived.
Auditability: every relevant command, egress request, and artifact needs a trace.

The phrase "credentials never enter the sandbox" sounds extreme at first, but for agent systems it is a very normal design goal. If a GitHub token is an env var inside a shell where the agent can run arbitrary commands, then prompt injection has a lot of room to cook. A credential broker, vault proxy, or domain-scoped token exchange is less comfy, but it is the right pain.

This is also why egress policy is not a random enterprise checkbox. A sandbox without egress control is basically a very polite exfiltration machine. It may behave nicely most days, until one doc says "send this file to my server" and the model thinks that is part of the task.

Self-Hosted Sandboxes and BYOI

Anthropic's self-hosted sandbox model keeps the Managed Agents orchestration on Anthropic's side, but moves tool execution into infrastructure the customer controls. In plain language: the vendor keeps the brain loop, you own the hands.

This is a very important product shape because many teams do not only care where the model runs. They care where code executes, where private repos are cloned, where build artifacts live, where browser traffic goes, and which network can be reached.

There are two common deployment patterns:

Pattern	Shape	Tradeoff
Always-on worker	A worker process stays connected, polls for work, and executes sandbox actions.	Simple mental model, but you operate a long-running bridge.
Webhook-triggered worker	A request wakes local infrastructure when there is work.	Cleaner idle cost, but webhook exposure and auth need careful design.

In both cases, the useful boundary is not "cloud vs local." The useful boundary is control plane vs data plane.

Control plane: sessions, task queue, agent config, UI, billing, channel gateway, artifact index.
Data plane: sandbox runtime, browser, filesystem, MCP gateway, private network, egress proxy, credential injection.

The control plane wants to be reliable, scalable, and product-shaped. The data plane wants to be close to sensitive data, policy, and runtime constraints. BYOI works when the contract between these two is narrow enough to operate, but expressive enough to do real work.

This is where the engineering gets spicy. You need lifecycle APIs, egress policy, artifact upload/download, logs, cancellation, snapshotting, cleanup, and enough observability to debug "the agent got stuck" without giving everybody shell access to everything.

NAP as an Agent Control Plane

Neutree Agent Platform is interesting because it feels less like "one sandbox provider" and more like a platform layer around agents. The public repo describes a hosted, multi-user service for building, distributing, and optimizing agents. It includes pieces like a web UI, control plane, scheduler, browser service, sandbox service, skills/content service, and adapters for agent runtimes.

That shape points to a product question I care about: if every company will have many agents, who owns the fleet?

The answer probably cannot be only "each developer runs an agent locally." A team needs permissions, routing, user identity, shared skill packages, audit logs, artifact storage, channel integrations, and a way to update agents without asking everyone to pull some random branch.

NAP's BYOI direction is appealing because it separates the platform experience from the exact runtime choice. You can imagine NAP managing agents, sessions, routing, and team UX, while the sandbox data plane uses OpenSandbox, Kubernetes, a browser service, or something else inside the user's enviroment.

That is the good version of BYOI: the product gives a coherent agent experience, while infra/security people still control the part that touches their private systems.

Sandbox Landscape: Same Problem, Different Layer

Not all sandbox projects are playing the same game. Some are SDK-first developer clouds. Some are open-source data planes. Some are managed-provider integrations. Some are Kubernetes abstractions. If you compare them as one flat list, the result feels confusing.

I prefer this map:

Sandbox service open-source comparison map

Rough map: the left side is closer to sandbox runtime and data plane, the right side is closer to control plane and product integration. It is not perfect, but it helps avoid mixing SDKs, templates, and infrastructure runtimes in one bucket.

Project / integration	Main layer	What it is good at	My read
E2B + infra	Sandbox cloud + self-hostable infrastructure	Developer-friendly sandbox lifecycle APIs, templates, code execution, self-host path.	Strong product API. Self-hosting is real infra work, not a weekend toy.
CubeSandbox	Sandbox data plane	RustVMM/KVM microVM runtime, E2B SDK compatibility, fast start claims, hardware isolation.	Feels like a serious open-source runtime for teams that want control at the data plane.
Kubernetes Agent Sandbox	Kubernetes workload abstraction	Sandbox CRD/controller for isolated, stateful, singleton workloads.	Best for teams already living in Kubernetes and wanting a standard API shape.
NAP + OpenSandbox	Agent platform + optional sandbox data plane	Agent control plane, team UX, optional sandbox/browser pieces, BYOI posture.	More platform than sandbox. Interesting if you want agent fleet management.
Cloudflare CMA template	Managed-provider data plane integration	Workers-based control pieces, Cloudflare sandbox runtime, egress policy, browser/custom tools.	Nice if your network/security story already fits Cloudflare's world.
Modal integration	Managed execution platform	Secure configurable containers, volumes, remote execution, scaling.	Great for compute-heavy or Python/GPU-ish agent tasks, less infra you own.
Vercel Sandbox integration	Managed web-platform sandbox	Firecracker microVM per session, credential brokering, deny-by-default egress, Vercel function control plane.	Very good fit for teams already shipping on Vercel and needing web-app adjacent agents.
Daytona	Composable computer / sandbox platform	Dedicated kernel, filesystem, network stack, vCPU/RAM/disk allocation, developer-like machine.	More "full computer for agents" than just a code runner. Good mental model for dev environments.

The important thing is not to ask "which one is best?" too early. The better question is: what layer are you missing?

If you have no product surface, you need a control plane. If you have a control plane but unsafe execution, you need a data plane. If your data plane works but secrets are messy, you need a broker. If your sandbox starts fast but cannot preserve state, you need snapshots or durable workspace design.

Containers, Pods, and MicroVMs Are Not the Same Bet

A container is usually the easiest sandbox to start with. It is fast, cheap, and every infra person already has some scars from it. For many internal agents, a locked-down container with good filesystem/network policy might be fine.

But containers share a kernel. If your threat model includes untrusted code, hostile prompt injection, arbitrary package install, or multi-tenant workloads, then shared-kernel risk becomes harder to ignore. This is where gVisor, Kata Containers, Firecracker, KVM, and RustVMM enter the chat.

MicroVMs give stronger isolation with a dedicated kernel boundary. The cost is operational complexity: image build, snapshotting, networking, storage, boot performance, observability, and density. A microVM is not just "container but safer." It is a different runtime product.

That is why E2B and CubeSandbox are interesting. They are not just saying "we use Firecracker/KVM." They are trying to wrap that runtime in agent-friendly APIs: create sandbox, run command, upload file, download artifact, snapshot, resume, destroy.

The API matters as much as the isolation primitive. Agents do not want a hypervisor. They want hands.

State Is Where the Product Feeling Lives

Fast cold start is cool, but the user experience of an agent often depends more on state.

An agent may need:

a repo checkout
a built dependency tree
a running dev server
a browser logged into a test app
generated files
previous command outputs
a memory of what it tried already

If all of that disappears between tool calls, the agent becomes clumsy. If it persists forever with no policy, the platform becomes scary. So the sandbox data plane needs state with lifecycle.

Some useful questions:

Can I pause and resume the sandbox?
Can I snapshot a workspace after setup?
Can I clone a clean baseline for another agent?
Can I garbage collect old sessions?
Can I separate artifacts from runtime state?
Can I inspect enough logs without exposing secrets?

This is not glamorous infrastructure. But it is where a product becomes reliable. The difference between "agent demo" and "agent platform" is often whether state has a boring, testable contract.

Egress Proxy Is the Underrated Part

If I had to pick one design component that deserves more attention, it is the egress proxy.

An agent sandbox needs outbound access, otherwise it cannot install packages, call APIs, fetch docs, run browsers, or connect to private services. But raw outbound access is dangerous. The agent can be tricked, the webpage can be hostile, and the task may include sensitive files.

A serious egress layer should support:

domain allowlists and denylists
per-session policy
secret/header injection outside the sandbox
private service routing
audit logs
emergency block
maybe content scanning for high-risk exfiltration

Cloudflare, Vercel, Anthropic's docs, and CubeSandbox all gesture at this in different ways: egress policy, credential brokering, vault/proxy, CubeEgress. The exact implementation varies, but the pattern is the same.

Do not give the sandbox a giant bag of secrets and say "please be normal." That is not the flex.

API Compatibility Might Decide the Winner

There is a quiet platform question under all of this: what becomes the common sandbox API?

E2B has a strong SDK shape. CubeSandbox advertises E2B SDK compatibility. Kubernetes Agent Sandbox introduces a Kubernetes-native CRD shape. Cloudflare, Modal, Vercel, and Daytona each expose their own provider-native primitives.

The winning interface may not be one single standard. More likely, we get a few adapter layers:

lifecycle: create, pause, resume, destroy
process: exec, stream logs, cancel
filesystem: read, write, upload, download
network: policy, proxy, private route
artifact: publish, inspect, retain
snapshot: checkpoint, clone, rollback
credentials: broker, scope, revoke

Agent frameworks should not need to care whether the sandbox is Firecracker, KVM, a container, or a Kubernetes pod. They should care whether the hands can do the job safely.

This is also where NAP-like platforms can become useful. They can hide provider differences behind a control-plane abstraction, as long as they do not flatten away the security controls that actually matter.

My Practical Checklist

If I were evaluating an agent sandbox today, I would ask these questions:

Is session state separate from sandbox state? The agent should survive sandbox replacement.
Can the harness be stateless? A crash should not lose the task history.
Is every sandbox scoped to a session and trust boundary? One sandbox for one risky unit of work is easier to reason about.
Do credentials avoid entering the sandbox? Use vaults, brokers, proxies, and short-lived tokens.
Is egress deny-by-default or at least policy-controlled? Open internet plus agent is a strong smell.
Are artifacts first-class? Generated outputs should not be trapped inside a temporary filesystem.
Can workspaces be snapshotted or reconstructed? Setup time and reproducibility both matter.
Is the sandbox API provider-portable? Even if you pick one runtime, adapters should be possible.
Can infra people debug it? Logs, metrics, traces, and audit records are not optional.
Does the product admit the rough edges? Agents fail in boring ways. The platform should make those failures observable, not mystical.

Closing Thought

The more I look at agent systems, the more I think the sandbox is not a sidecar. It is the data plane.

Managed Agents give a clean architecture: durable session, harness, sandbox. BYOI sandboxes make the trust boundary explicit. E2B, CubeSandbox, Kubernetes Agent Sandbox, NAP, Cloudflare, Modal, Vercel, and Daytona all show different pressure points in the same design space.

The next useful agent platform will not only have a better prompt. It will have better hands: isolated, stateful, inspectable, policy-aware, and boring enough that a security team can sleep.

That last part sounds not exciting, but honestly it is the whole game.