The decision
Sandboxing is a run-layer decision, not a shopping trip
Agents that execute code, run tools, and touch files need a controlled execution boundary. The question most guides skip: who operates that boundary for every single run?
The current wave of sandboxing content answers a builder's question: which isolation technology, which sandbox provider, which controls to configure. Useful, if assembling an agent runtime is your product. For many product teams it is not, and the honest first question is one level higher: build the execution layer from sandbox primitives, or consume sandboxed execution as a property of a managed harness layer.
Both paths are legitimate, and this article walks both. What they share is the requirement; what separates them is who carries it. A team that picks a path deliberately ends up with isolation either way. A team that never asks inherits sandbox operations as a side effect of wanting finished agent work.
Definition
What an agent sandbox does, and what it does not
Behaviorally, an AI agent sandbox is a constrained environment that separates an agent's execution from the host it runs on, from other workloads, and from resources it was not given. Inside it, the agent can do real work: run commands, edit files, execute code. Outside it, the rest of your infrastructure and other tenants are off limits, and credentials the run was never given stay out of reach.
Keep the promise bounded. Sandboxing reduces blast radius and limits what a compromised or confused agent can persist. It does not make agents safe in any absolute sense, does not eliminate prompt injection, and does not replace product-level authorization. It is one necessary layer of a defense, and the layer this article is about.
The unit
For product workloads, default to per-run isolation
Here is the distinction that does the most work in practice. A long-lived sandbox is an environment you keep: it is reused across tasks, its residual state survives unless you clean it, its capacity must be maintained whether work arrives or not, and its safety depends on recycling discipline. A per-run sandbox is an environment the task brings with it: created for one run, isolated by construction because the task boundary and the execution boundary are the same line, and gone when the run ends.
Long-lived environments have real uses, interactive development among them, and modern sandbox platforms make them genuinely manageable, with snapshots, pause and resume, and reconnection. But product workloads are made of discrete tasks, parallel runs, and reviewable outcomes, and for that shape, per-run isolation is the natural default: no residue crossing between tasks, no cleanup discipline to audit, and capacity that simply follows the work.
The rule that falls out of it: persist the work product, not the worker. Durable state, sessions, checkpoints, files, traces, and finished artifacts, belongs in the product layer, owned and continued. The execution process that produced it can be disposable, and the more disposable it is, the less there is to secure. Running many agents in parallel is where this shape pays off most visibly.
Evaluation
Evaluate any sandbox through three boundaries
Whatever path you take, the run contract is worth interrogating on three boundaries:
- Reach: what can a run touch beyond itself? Which network destinations, and which credentials does this particular run receive, for how long?
- Workspace: what can the agent read and change? How is the run separated from the host and from neighboring workloads?
- Time: when is the environment created, when does it time out, and what guarantees that nothing from this run leaks into the next one?
These are evaluation questions, not a feature checklist to copy. On the build path you will answer them with configuration you own; on the bundled path, expect the platform's per-run behavior to carry them, while what each run is given, files, credentials, and task content, remains your call.
Path one
Assemble the runtime yourself
The build path composes your harness, your orchestration, and your product backend on top of sandbox infrastructure from providers such as E2B, Modal, Daytona, or Cloudflare's Sandbox SDK. These are capable platforms solving a lower-layer problem well, and if owning the runtime is strategic for you, they are the right base. The distinction that matters is not who manages machines; modern sandbox platforms are managed and elastic themselves. It is what you hold at the end: sandbox infrastructure hands you the execution primitive, and a managed harness layer hands you the completed run contract across harnesses.
What the path really prices in is everything above the primitive: policy for reach, workspace, and lifetime; provisioning and teardown per run; mapping runs to sessions, files, and artifacts; concurrency, retries, and failure recovery; per-run observability and cost attribution; and keeping all of it current as harnesses and infrastructure ship. None of that is an argument against building. It is the true bill of materials, and teams that see it up front build better runtimes, or decide the runtime is not their product after all. What a complete backend for AI agents includes is the longer version of that bill.
Path two
Sandboxing bundled into the harness layer
The other path treats sandboxed execution as something the run layer simply has. A unified harness interface accepts a task, runs a complete harness in an isolated environment, and returns sessions, streamed events, files, artifacts, and traces through one product contract. HarnessRouter is the world's first unified interface for agent harnesses.
In practice: each task runs in its own sandbox provisioned on demand, across every supported harness, eight today: Codex, Claude Code, Hermes, Pi, DeepSeek Harness, OpenCode, Qwen Code, and Cline. Send one task and it executes in isolation; send fifty at once through the same integration and fifty isolated runs happen, with serverless sandbox capacity following the workload. Every harness streams the same events and returns the same artifact contracts, with traces recorded, so isolation comes bundled with the rest of the run lifecycle rather than as a system you operate beside it. This is the managed-agents pattern applied to execution isolation.
The comparison
Compare at the level of a completed run
Raw sandbox pricing is the wrong denominator; the useful one is the cost of a completed, reviewable run. On the build path that includes the sandbox compute, any idle or pre-provisioned capacity where applicable, orchestration and storage, retries and failed runs, streaming and artifact delivery, and the engineering time that keeps it all working. On the bundled path most of that collapses into the platform's meter, and what stays on your side is the tasks you send and the application around them.
Neither path is universally cheaper, and workloads differ too much for a general claim. The decision rule that holds: pick sandbox infrastructure when owning and composing the runtime is strategically yours; pick the managed harness layer when what your product needs is completed agent work; and pick the Apache-2.0 Community Edition when you want the same harness and API layer on infrastructure you control, with isolation shaped by how you deploy it.
Still yours
What stays your responsibility either way
Managed sandboxing narrows the operational surface; it does not absorb the application. Your product still owns user identity and authorization, approval rules for actions with external side effects, the choice of what tasks, files, and credentials to send, and judgment on whether returned work is acceptable.
Tenant separation at the product level is your server's job: derive identity from your trusted session, map returned session and file IDs to their owners, and check that mapping before every operation on existing work. A sandbox isolates runs from each other and from the host; only your application knows which user a run belongs to.
The answer
Isolation is required; operating it is optional
If you build the execution layer, sandboxing is infrastructure you select, configure, and operate, and the providers in that market are good at their layer. If you consume a managed harness layer, sandboxing is a property of every run, already there when the task arrives and gone when it ends.
Whichever path you take, hold the line that matters: one run, one sandbox, no execution residue crossing the boundary. Getting sandboxing right is less about assembling the most elaborate isolation stack and more about choosing, deliberately, who operates it.
FAQ
AI agent sandboxing FAQ
What is an AI agent sandbox?
A constrained execution environment that separates an agent's real work, running commands, editing files, executing code, from the host system, other workloads, and resources the run was not given. It limits what a confused or compromised agent can reach and what its actions can persist.
Do AI agents really need sandboxing?
Any agent that executes code, uses tools with side effects, or processes untrusted input should run inside an isolation boundary. Sandboxing reduces blast radius; it does not by itself prevent prompt injection or replace product-level authorization, so treat it as one required layer, not the whole defense.
What is the difference between a per-run sandbox and a long-lived one?
A long-lived sandbox is reused across tasks, so its safety depends on cleanup discipline and its capacity must be maintained. A per-run sandbox is created for a single task and destroyed after it, so the task boundary and the isolation boundary are the same line and no execution-environment state crosses between runs.
Do I need to build my own sandbox infrastructure?
Only if assembling your own agent runtime is deliberate strategy. Teams on that path compose sandbox infrastructure providers with their own orchestration. Teams that need completed agent work can consume sandboxed execution through a managed harness layer, where every task already runs in its own isolated sandbox.
Does HarnessRouter sandbox every run?
On the hosted platform, yes: every task submitted through the API executes in its own sandbox provisioned on demand, for every supported harness, with sessions, streaming, files, artifacts, and traces returned through the same contract. The Apache-2.0 Community Edition preserves the same harness and API layer on your infrastructure, with isolation determined by how you deploy it.
One run. One sandbox. Zero sandbox orchestration.
Send tasks to any supported agent harness through one API and let every run isolate itself on demand.
Start building free