How to Sandbox AI Agent Code: Firecracker, OpenSandbox, Docker, SmolVM and nono Compared

Once an AI agent can write and run code, someone has to decide where that code runs. A coding agent that refactors your repository, a research agent that executes generated Python, a customer-facing assistant that runs SQL — each of them, at some point, executes instructions that no human reviewed line by line. If that execution happens on a machine with access to your source code, your cloud credentials and your production network, the isolation boundary around it is not a detail. It is the control.

The market has responded quickly. In March 2026 Alibaba Cloud open-sourced OpenSandbox; AWS has been hardening Firecracker since 2018; and a cluster of smaller projects — SmolVM, nono, Docker's own Sandboxes feature — now offer to isolate agent code in a few commands. The brief for this piece was to compare five of them as "microVM options".

That framing is where the confusion starts. Only two of the five were built from the ground up as microVMs. The others each take a different approach — a shared-kernel container, a user-space kernel, and an operating-system process sandbox. And the ground is shifting under the labels: Docker, whose Sandboxes feature began as a container, has since moved it onto microVMs, which is a data point worth holding onto. Comparing these tools as if they were interchangeable is how organisations end up either over-engineering a problem they do not have or under-protecting one they do.

What you are really choosing between

The stated question — "which sandbox?" — conceals a more fundamental one: how strong an isolation boundary does your workload actually need, and how much operational weight are you willing to carry to get it. Those two move in opposite directions. A stronger boundary almost always costs more to run.

Every option in this comparison sits on a spectrum with four points. Understanding the point is more durable than memorising the product, because the products change monthly and the four models do not.

Read the table top to bottom and the boundary gets stronger with every row. Read it bottom to top and the workload gets lighter and quicker to start. The whole decision lives in that trade. A microVM gives an attacker who breaks out of the code nothing but a stripped-down guest kernel to attack next; a process sandbox gives them your kernel, weakened only by the permissions you remembered to remove.

For enterprise technology leaders, the practical consequence is that "we sandbox our agents" is not a security posture. The model you chose is the security posture. A team running untrusted, model-generated code inside a plain container and a team running it inside a microVM have made materially different bets, even though both would tick the same box on a questionnaire.

The case for each option

Below, each tool with the model it represents, what it is genuinely good at, and where it stops. None of the five is wrong. Each is wrong for the workloads it was not built for.

nono — the process sandbox

nono, built by Luke Hinds, is the lightest option here and the one most often miscategorised. It is not a virtual machine and not a container. It is a capability-based security shell that wraps an existing command using kernel primitives — Landlock on Linux, Seatbelt on macOS — to restrict what that process can touch. Once the restrictions are applied they cannot be widened: there is no API to escape them, not even for nono itself.

What it does well is protect your own machine from your own agent. Point it at Claude Code or a terminal-based assistant and you can declare, in a JSON profile, exactly which directories and network destinations the agent may reach. Credentials are injected at the boundary and zeroised on exit, so the agent never sees your SSH keys or cloud tokens even while using them. It runs anywhere the agent already runs, with near-zero overhead and no images to build. Its Show HN debut drew a warm reception from developers with exactly this worry, and the practitioners who have written it up tend to reach the same verdict: for running agents during day-to-day development, it strikes a sensible balance between safety and staying out of the way.

The limit is inherent to the model. nono still shares your kernel and runs on your host. It is an excellent answer to "my trusted coding agent might read a file or reach a server it should not", and a poor answer to "I am about to execute code written by an untrusted model for an untrusted user". It hardens the blast radius; it does not virtualise it away.

Docker Sandboxes — the familiar tool that changed its mind

Docker Sandboxes, an experimental feature aimed at running coding agents such as Claude Code, Codex and Gemini unattended, gives an agent a disposable, isolated environment without leaving the tooling every developer already knows. Its appeal is almost entirely about developer experience — "the best DX of any local AI coding sandbox I have tried", in the words of educator Matt Pocock, quoted on Docker's own launch blog — and about the ability to run agents without a stream of permission prompts, then delete the environment and start fresh in seconds if one goes off the rails.

What makes it the most interesting entry here is that it changed isolation model mid-flight. The experimental preview used ordinary container isolation: namespaces and cgroups over one shared host kernel, which is reasonable for code you wrote and weak for code an AI generates on behalf of strangers. Docker evidently reached the same conclusion the rest of the industry did, because recent releases run each sandbox inside a dedicated microVM on macOS and Windows — "a hard security boundary", in Docker's phrasing — with Linux support still on the roadmap. In other words, the tool most people reach for because it is already installed has itself concluded that a shared kernel was not enough for unsupervised agents. That migration is the clearest single piece of evidence for this whole comparison: the isolation model is not a fixed property of the product, and it is the thing you actually have to check.

OpenSandbox — the user-space kernel

OpenSandbox, open-sourced by Alibaba Cloud in March 2026 under the Apache 2.0 licence, sits one rung up. Run with Google's gVisor runtime, it places a software kernel between the sandboxed process and the host: every system call the agent makes is intercepted and handled in user space rather than passed straight to the host kernel. That shrinks the attack surface considerably compared with a plain container, at some performance cost. Concretely, gVisor's user-space kernel implements roughly 200 of the Linux kernel's roughly 400 system calls, so it narrows what an escape could reach — but code that depends on an unimplemented low-level call will fail, which is the compatibility tax you pay for the smaller surface. Independent testing puts its overhead at roughly 10 to 30 percent on I/O-heavy work and close to nothing on compute-bound tasks.

Its real strength is that it is built as production infrastructure rather than a single-machine tool. It runs on both Docker and Kubernetes, so the same sandbox scales from a laptop to a cluster; it ships SDKs for Python, TypeScript, Go and Java on day one; and it exposes a unified API for the things agents actually do — run a code interpreter, drive a browser, manage files and processes, stream output back. Its secure runtime is also pluggable — gVisor, Kata Containers or Firecracker microVM — on top of its core Docker and Kubernetes runtimes. For an organisation standardising agent execution across many teams, that breadth matters more than any single benchmark. The trade is operational: you are adopting and running a platform, not calling a library.

One consequence of that design is that OpenSandbox publishes no fixed storage or memory footprint, because it does not have one of its own — the resource cost is whatever the backend you choose imposes, from a lightweight gVisor container up to a full Firecracker microVM. Persistent data is handled through the underlying platform, using Docker volumes or Kubernetes persistent volume claims rather than any store OpenSandbox provides itself.

Firecracker — the microVM primitive

Firecracker is the reference point everything else is measured against. AWS built it in Rust, open-sourced it in November 2018 under Apache 2.0, and runs Lambda and Fargate on it at a scale of trillions of executions. It creates true microVMs on top of KVM: each workload gets its own guest kernel behind a hardware virtualisation boundary, yet boots in under 125 milliseconds, adds less than 5 MiB of memory overhead per microVM, and a single host can launch up to 150 of them per second. That combination — a real VM boundary at close to container speed — is why it underpins so much of the managed sandbox market: the agent-sandbox providers E2B and Vercel Sandbox both build on Firecracker, while Modal took the gVisor route instead. When AWS, Google and Microsoft each built ephemeral agent sandboxes, every one of them reached for a hardware or user-space isolation primitive rather than a plain container.

The honest limitation is that Firecracker is a primitive, not a product. It gives you the virtual machine monitor and very little else: you assemble the guest kernel, the root filesystem, the networking and the lifecycle management yourself. Its host requirements are also firm. It runs only on Linux, on x86_64 or 64-bit ARM, and needs the KVM module with read and write access to /dev/kvm; the current support policy covers host kernels 5.10, 6.1 and 6.18, with guest kernels 5.10 and 6.1. It does not support nested virtualisation, so it must run on bare metal — on AWS that means a .metal instance type rather than an ordinary VM. Each guest starts from a default of 128 MiB of RAM, configurable upward. That is the correct choice if you are building a platform other teams will consume. It is a large amount of undifferentiated engineering if you simply want to run some agent code safely this quarter — which is exactly the gap the managed services built on Firecracker, and the tools below it, exist to fill.

SmolVM — the microVM made approachable

SmolVM takes the microVM boundary and wraps it in developer ergonomics. It runs on the hypervisor each platform already has — KVM (via libkrun) on Linux, Hypervisor.framework on macOS, the Windows Hypervisor Platform on Windows — so one workflow gives you a real per-workload kernel across all three operating systems. Boot times land in the low hundreds of milliseconds, and, importantly, its images use the OCI format, so anything already on Docker Hub or a container registry can be pulled and booted as a microVM.

This is the microVM for people who do not want to become hypervisor engineers. It suits a developer who wants strong isolation on a Mac laptop, a team distributing a locked-down environment, or a workload that needs a genuine VM boundary without the assembly work Firecracker demands. Its clearest advantage over Firecracker is reach: Firecracker does not run on macOS at all, whereas SmolVM reaches an equivalent boundary there through Apple's Hypervisor.framework — which is part of why its launch drew heavy attention on Hacker News. Early community comparisons have been favourable; a widely-shared thread on the r/LangChain subreddit claimed it beats E2B and OpenSandbox on snapshotting, fork speed and computer-use support, though head-to-head claims of that kind are worth testing against your own workload rather than taking on trust. It is younger and less battle-tested than the AWS lineage, and running microVMs at fleet scale still carries real operational weight — but it closes most of the distance between "I want a microVM" and "I have one running".

Footprint and setup effort, the factors that decide it in practice

Isolation strength is the headline, but two quieter factors often settle the choice before security does: how much memory and disk each running workload consumes, and how long it takes to get the first one running. These track the same spectrum as the boundary — a stronger boundary generally costs more resource and more setup — but the ranges are wide enough to matter on their own. Time to first useful sandbox runs from minutes to days across these five.

Two readings of that table are worth drawing out. The first is that the lightest boundary is also the lightest to run: nono adds a binary of a few megabytes and effectively no memory, because it is not virtualising anything — it is fencing a process you were going to run anyway. The heaviest to operate is Firecracker, and not because a microVM is large — the running overhead is tiny — but because you are responsible for building and maintaining everything around it. The effort in Firecracker is engineering time, not gigabytes.

The second is that raw defaults mislead. SmolVM advertises 8 GiB and a 20 GiB disk, which sounds heavy next to a container, but its memory is elastic: the host only commits what the guest touches. A configured-down SmolVM and a gVisor sandbox can end up in a similar place, while giving you a stronger boundary. In practice, judge these on the resource a workload actually consumes and the days of setup it demands, not on the numbers in the quickstart.

In practice, this means the resource question and the security question are rarely in tension for a single workload — the tension is with your team's time. Firecracker's boundary is the strongest and its per-VM footprint is among the smallest; what makes it expensive is the platform you have to build to use it. That is why most organisations reach it through a managed service or a friendlier microVM tool such as SmolVM, and why "how quickly can one engineer get this running" belongs in the decision alongside "how strong is the boundary".

The factors that should drive your decision

There is no ranking here, because the right answer is a function of your workload, not the software. Four questions settle it.

1. Whose code is running? If the agent executes code your own team wrote, on infrastructure you control, a process sandbox (nono) or a container (Docker) protects against accident and mistake at almost no cost. If it executes code a model generated — especially on behalf of external users — you want a kernel boundary the code cannot see past: gVisor at minimum, a microVM for the highest stakes.
2. Who shares the host? Single-tenant, single-machine work tolerates a weaker boundary because a breakout harms only the person who launched it. The moment multiple customers' code runs on shared hardware, the blast radius of one escape includes everyone else on that host, and the calculus moves decisively towards user-space kernels or microVMs.
3. One machine or a fleet? nono and SmolVM are strongest on a developer's machine. OpenSandbox and Firecracker are built for clusters. Choosing a laptop tool for a platform problem, or a platform for a laptop problem, is the most common source of wasted effort in this space.
4. Build or consume? Firecracker is a foundation to build on. Most organisations should build on it only indirectly — through a managed service or a higher-level tool such as SmolVM or OpenSandbox — unless running sandbox infrastructure is itself part of the product they sell.

Whose code, whose host, how many machines, build or buy. Answer those four and the field of five narrows to one or two on its own.

Common mistakes

Three errors recur often enough to name.

Treating a container as isolation for untrusted code. Docker is the reflex because it is already installed. But a shared-kernel container was designed to package software that trusts the host, not to contain software the host cannot trust. Running model-generated code for external users inside a plain container is the single most common over-estimate of a boundary in this list — a point Docker itself conceded when it moved Sandboxes onto microVMs.

Reaching for a microVM when a process sandbox would do. The opposite mistake is real too. Standing up Firecracker to contain a trusted internal coding agent is engineering effort spent on a threat you do not have. If the code is yours and the machine is yours, nono or a container answers the question at a fraction of the cost.

Isolating the filesystem and forgetting the network and the secrets. A sandbox that stops an agent writing to disk but lets it open outbound connections, or hands it live credentials in an environment variable, has isolated the wrong thing. Data exfiltration does not need filesystem access; it needs a network socket and something worth sending. Whatever model you choose, network egress control and credential handling are part of the decision, not an afterthought to it — which is precisely why nono treats them as first-class and why they are worth checking in every other option.

Frequently asked questions

Are all of these microVM options actually microVMs?

No. Only Firecracker and SmolVM are hardware microVMs. OpenSandbox uses a user-space kernel (typically gVisor), nono is an operating-system process sandbox using Landlock on Linux and Seatbelt on macOS, and Docker Sandboxes began as a shared-kernel container — though recent versions run each sandbox in a dedicated microVM on macOS and Windows.

Which option gives the strongest isolation boundary?

A hardware microVM — Firecracker or SmolVM — because each workload gets its own guest kernel behind a hypervisor. It is the safest place to run untrusted, model-generated code, at the cost of more setup and operational weight than a container or a process sandbox.

What does Firecracker require to run?

Linux on x86_64 or 64-bit ARM, the KVM module with read and write access to /dev/kvm, and bare metal — it does not support nested virtualisation, so on AWS it needs a .metal instance rather than an ordinary VM. Each microVM adds under 5 MiB of overhead, boots in under 125 ms, and starts from a default of 128 MiB of guest RAM.

When is a lightweight tool like nono enough?

When the agent runs code your own team wrote, on infrastructure you control. nono fences an existing process with near-zero overhead and no images to build. For untrusted code — especially code generated on behalf of external users — you want a user-space kernel such as gVisor at minimum, or a microVM for the highest stakes.

Should we build on Firecracker directly?

Usually only if running sandbox infrastructure is itself part of your product. Firecracker is a primitive: you assemble the guest kernel, root filesystem, networking and lifecycle management yourself. Most organisations reach it indirectly through a managed service or a higher-level tool such as SmolVM or OpenSandbox.

New posts land here first. Sign up for email updates.