Agent sandboxes - where unvetted code runs

An agent that writes code needs somewhere to run it that no human reviewed first - and that is the entire case for the sandbox layer. The question “is this environment isolated” sounds binary and is not: a shared process, a container, a sandboxed runtime and a microVM are four different boundaries, and the platforms sell all of them under the same word.

What a sandbox actually provides

Strip the vendor surface away and the interface is always the same shape: create an environment on demand, run code in it, get the output, destroy it. Around that core sits a lifecycle that decides whether the product fits an agent at all.

The isolation ladder

The primitives differ most in what stands between the agent’s code and your host:

• A shared process offers no boundary at all - fine for code you already trust, not for code a model just wrote.
• An OCI container uses namespaces and cgroups on a shared host kernel. A kernel-level escape reaches the host, which is why “container” alone is not a security answer.
• A sandboxed runtime - gVisor interposing a userspace kernel, or Kata running each container as a light virtual machine - puts a real boundary up without a full VM’s cost.
• A microVM such as Firecracker boots a genuine guest kernel on KVM with a deliberately minimal device surface - the same isolation AWS Lambda and Fargate run on.
• A dedicated host is the strongest rung and the most expensive: nothing on the machine is shared, reserved for the least-trusted workloads.

The vendor question to ask is not “is it sandboxed” but “which rung does the default configuration sit on” - because several platforms let you pick, and the default is not always the strong one.

The three platforms as they actually differ

The three names that recur are not interchangeable; each optimises a different axis of the same job, and the differences that matter are the ones below the feature table.

The cold-start numbers are worth a pinch of scepticism - LogRocket’s independent measurements put creation around 700 ms for E2B and Daytona and roughly 2.4 s for Modal, against vendor claims that are uniformly rosier - but the relative order holds: a coding agent that opens a sandbox per edit cares about the first number, a batch agent that runs a job does not.

What actually decides the choice

Five dimensions, and no platform wins all of them:

• Cold start - a coding assistant that spins an environment per edit lives or dies on it; a nightly batch agent does not notice.
• Isolation model - the rung on the ladder above, which sets the floor for the worst case.
• Session persistence - whether the environment survives between an agent’s turns. A research agent holding a dataset across twenty tool calls needs this; a one-shot script does not.
• SDK ergonomics - how close the API sits to the way an agent actually calls it.
• Pricing model - per-second billing, session-scoped versus persistent, a floor versus scale-to-zero. Modal scales to zero when idle; persistent workspaces bill like a dev machine.

Match the platform to the dimension where a wrong choice breaks the agent, the security model, or the budget - that is the shortlist, and everything else is a filter. The practical takeaway is that “isolated enough” depends on what the agent is allowed to do, which is the harness’s permission model - the sandbox enforces it, but does not set it.

Where it breaks

• The default is not always the strong isolation. A platform that offers a container as the default and a stronger primitive as opt-in is a different product from one whose default is a microVM - read the rung, not the marketing.
• A sandbox with no egress policy is a sandbox that leaks. The isolation protects the host, not the network; an agent that can exfiltrate over HTTP from inside the sandbox is still an exfiltration path.
• Persistence is a liability as much as a feature. A sandbox that survives between sessions also survives with whatever the agent left in it, and a leaked or poisoned state is reused on the next run.
• The SDK is a new dependency with its own attack surface. These platforms are young - E2B’s Series A was July 2025, Daytona’s February 2026 - and their SDKs move fast enough that pinning a version is doing real work.

What this is not for

• Running code you already trust - the overhead of a managed sandbox buys nothing when the code is reviewed; run it in your own infrastructure.
• Anything that needs a real user environment - a sandbox is a clean room, not a workstation, and an agent that needs an actual desktop wants the computer-use pattern, not a code sandbox.
• A substitute for the permission model - the sandbox bounds where code can run, not what the agent is allowed to ask it to do.