Sanbox By Sanlabs

Guides

Agent computers explained

Explainer

Container, microVM or VM: which isolation for coding agents?

By the Sanbox team updated

Ask ChatGPT Ask Claude

Containers share the host's kernel, so the kernel is the wall between a coding agent and everything else on the machine. MicroVMs, such as those Firecracker creates, give each workload its own kernel behind hardware virtualisation, with a deliberately small set of emulated devices. Full VMs also have their own kernel but emulate more hardware and take longer to boot. Sanbox runs every Computer as a Firecracker microVM, and its Docker Computer runs Docker inside that microVM.

Why does isolation matter more for coding agents?

A coding agent runs code nobody reviewed line by line: install scripts, test suites, build tools and its own experiments. So the question isn't whether the agent is trustworthy. It's what a bad command, a malicious package or a prompt injection can reach.

What does a container isolate?

A container is a group of ordinary processes on the host, fenced off with Linux kernel features. Namespaces give each container its own view of processes, networking and the filesystem, and cgroups limit its CPU, memory and I/O. Docker's documentation is plain about the trade-off: when several containers run, "they all share the same kernel".

That has three consequences:

  • The kernel is shared attack surface. A kernel bug that lets a process escape its namespaces affects every container on that host.
  • The Docker daemon runs as root unless you use rootless mode, and Docker says only trusted users should control it.
  • Mounts reach the host. A bind-mounted host directory lets the container change those host files without further restriction.

For trusted code, or for keeping an agent out of your home directory on a laptop, a container is a real improvement over nothing. It's a weaker wall for untrusted code on shared machines.

What does a microVM add?

A microVM is a virtual machine stripped down to what a server workload needs. Firecracker, the one Sanbox uses, is open-source, written in Rust and built on Linux KVM. Each microVM boots its own guest kernel, so the workload talks to that kernel, and a hardware virtualisation boundary separates it from the host. Firecracker's documentation also describes:

  • A minimal device model. Five emulated devices: network, block storage, vsock, a serial console and a minimal keyboard controller used only to stop the VM. Fewer devices means less code an attacker can reach.
  • A second line of defence. Firecracker limits its own system calls with seccomp filters, and the jailer adds cgroups, a chroot and dropped privileges around each microVM, in case the virtualisation barrier is ever broken.
  • Low weight. The project quotes boot times under 125 ms and under 5 MiB of memory overhead per microVM.

Is a microVM more secure than a full VM?

Not by itself. Both rely on hardware virtualisation, so they're in the same class of isolation, and both depend on a well-patched host kernel and hypervisor. Firecracker's own production guidance says it can't mitigate the host's hardware vulnerabilities and recommends disabling SMT where tenants must be separated.

What a microVM changes is weight. A smaller device model is a smaller attack surface, and a fast boot makes it practical to give every agent, task or user its own machine. A well-run full VM is also strong isolation; it is heavier, slower to start and usually shared by more of your own software.

How do the options compare?

ContainergVisorMicroVM (Firecracker)Full VM
KernelHost kernel, sharedA user-space application kernel handles system callsOwn guest kernelOwn guest kernel
Main boundaryNamespaces, cgroups, seccompgVisor's kernel, with limited host system callsHardware virtualisation plus jailerHardware virtualisation
Emulated devicesNot applicableNot applicableFiveMany
Start-upFastFastUnder 125 ms boot, per FirecrackerSlower; boots a full operating system
Good forTrusted code, packagingUntrusted containers where you can't use VMsOne machine per agent or taskFull operating systems, any kernel

Two middle options are worth knowing. gVisor intercepts a container's system calls and handles them in its own user-space kernel instead of the host's. Kata Containers runs containers inside lightweight VMs, each with a dedicated kernel.

How does Docker work inside a Sanbox Computer?

A Docker Computer runs Docker Engine, Buildx and Compose inside the Computer's microVM. Containers share the microVM's kernel, not the host's, so a container that breaks out lands inside that one Computer, which has its own disk and its own network policy. The Computer is the security boundary, so your containers, builds and Compose stacks need no special privileges.

sanbox templates create --name "Compose stack" --type docker-computer \
  --network-policy registries.json --json
sanbox run --template <template-id> --json
sanbox exec <run-id> -- docker run --rm hello-world

Pulling hello-world from Docker Hub needs Docker Hub's registry and CDN hosts in registries.json.

What doesn't isolation cover?

A strong wall around the machine doesn't limit what the agent does through the doors you open. If the Computer can reach production, or holds a production key, isolation won't help. Pair it with an egress allowlist and keep keys outside the machine.

When Sanbox is not the right fit

  • You only evaluate small snippets in-process. A language-level sandbox or a container is simpler and faster.
  • You need a GPU, Windows or a custom kernel. Sanbox Computers have no GPUs or Windows. Ask us before you plan on kernel-level changes.
  • Your own security team must operate the hypervisor. Self-host Firecracker or Kata on hardware you control, or write to us about running Sanbox in your own cloud or on your own hardware.

Sources