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

> Containers share the host kernel. MicroVMs such as Firecracker give each workload its own kernel behind hardware virtualisation. Full VMs do too, with more weight.

- Source: Sanbox knowledge base, by Sanlabs GmbH
- URL: https://sanbox.cloud/kb/agent-computers/container-microvm-or-vm-for-coding-agents/
- Type: explainer
- Section: Agent computers explained
- Language: en
- Published: 2026-11-06
- Updated: 2026-11-06

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?

| | Container | gVisor | MicroVM (Firecracker) | Full VM |
|---|---|---|---|---|
| Kernel | Host kernel, shared | A user-space application kernel handles system calls | Own guest kernel | Own guest kernel |
| Main boundary | Namespaces, cgroups, seccomp | gVisor's kernel, with limited host system calls | Hardware virtualisation plus jailer | Hardware virtualisation |
| Emulated devices | Not applicable | Not applicable | Five | Many |
| Start-up | Fast | Fast | Under 125 ms boot, per Firecracker | Slower; boots a full operating system |
| Good for | Trusted code, packaging | Untrusted containers where you can't use VMs | One machine per agent or task | Full 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.

```bash
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](mailto:sales@sanlabs.ai) about running Sanbox in your own cloud or on your own hardware.

## Related

- [What is an agent computer? Sandbox vs Computer vs VPS](https://sanbox.cloud/kb/agent-computers/what-is-an-agent-computer/)
- [Give your agent its own computer, not SSH to production](https://sanbox.cloud/kb/security/agent-own-computer-not-ssh-to-production/)
- [How do I restrict which domains an AI agent can reach?](https://sanbox.cloud/kb/security/restrict-which-domains-an-agent-can-reach/)
- [How do I run Docker Compose inside an AI agent's sandbox?](https://sanbox.cloud/kb/parallel-work/docker-compose-inside-an-agent-computer/)
- [Docker Sandboxes vs a persistent cloud computer for coding agents](https://sanbox.cloud/compare/docker-sandboxes-vs-a-persistent-computer/)

## Sources

- [Docker: What is a container?](https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/), shared kernel (checked 2026-11-06)
- [Docker Engine security](https://docs.docker.com/engine/security/), namespaces, cgroups, daemon privileges and bind mounts (checked 2026-11-06)
- [Firecracker](https://firecracker-microvm.github.io/), KVM, device model, jailer, boot time and overhead (checked 2026-11-06)
- [Firecracker README](https://github.com/firecracker-microvm/firecracker) (checked 2026-11-06)
- [Firecracker production host setup](https://github.com/firecracker-microvm/firecracker/blob/main/docs/prod-host-setup.md), hardware vulnerabilities and SMT (checked 2026-11-06)
- [gVisor documentation](https://gvisor.dev/docs/) (checked 2026-11-06)
- [Kata Containers](https://katacontainers.io/) (checked 2026-11-06)

## Next step

Talk to us at sales@sanlabs.ai. Sanlabs' forward-deployed engineers build agent use cases with your team, with experience in aviation, pharmaceuticals, supply chain and logistics, and internal admin workflows. How we work: https://sanbox.cloud/kb/teams/forward-deployed-engineering.md

Existing customers can use Sanbox from a coding agent: install the CLI with `npm install -g @sanlabs/sanbox-cli@latest`, sign in with `sanbox login`, then run `sanbox skill` for the full agent guide.