Docker containers vs microVMs for sandboxing agents

Choosing between Docker vs microVMs agent sandboxing is a foundational decision when you let autonomous agents run untrusted code. Containers multiplex workloads on a shared host kernel with namespaces and cgroups; microVMs spin up a separate minimal kernel per workload using hardware virtualization. The trade-off is not just security—it shapes cold-start latency, density, and how your on-call handles incidents.

Isolation Model

Docker isolates processes via Linux namespaces (PID, mount, network, user, IPC) and resource limits via cgroups v1/v2. You layer seccomp-bpf to filter syscalls and AppArmor or SELinux to constrain filesystem access. The kernel is shared with the host and every other container on that host. A kernel exploit or a mistakenly granted CAP_SYS_ADMIN turns a contained agent into a host-level threat.

docker run --rm \
  --security-opt seccomp=/etc/docker/seccomp-default.json \
  --security-opt apparmor=docker-default \
  --cap-drop ALL --cap-add NET_BIND_SERVICE \
  -m 256m --cpus 0.5 \
  -u 1000:1000 \
  my-agent-runtime:latest

microVMs (Firecracker, Cloud Hypervisor, Kata) boot a stripped guest kernel and run the agent in a real virtual machine. The hypervisor mediates MMIO, memory mapping, and device access. A guest kernel bug stays in the guest. The cost is maintaining a kernel image and a virtio device model.

{
  "boot-source": {
    "kernel_image_path": "vmlinux-6.1",
    "boot_args": "console=ttyS0 reboot=k panic=1 nomodules"
  },
  "drives": [
    {"drive_id": "rootfs", "path_on_host": "agent-rootfs.ext4",
     "is_root_device": true, "is_read_only": false}
  ],
  "machine-config": {"vcpu_count": 1, "mem_size_mib": 256}
}

Capability Surface

Containers can be locked down hard, but they still expose /proc, /sys, and the host scheduler. microVMs present a clean hardware boundary; you attach only the virtio devices the agent needs. For agent workloads that pip install random packages, that boundary is the difference between a contained crash and a host panic.

A middle ground exists: gVisor intercepts syscalls in userspace, giving container-like ergonomics with a narrower kernel surface. It is not a microVM, but it belongs in the threat model discussion.

Cold Start and Throughput

Container start is essentially a clone() plus mount setup. For a small image and a warm Docker daemon, you get sub-100ms starts. Throughput per host is high: you can pack hundreds of idle agents if they are mostly waiting on LLM responses.

microVMs pay a boot cost. Firecracker’s public numbers target ~125ms from API call to ready, assuming a pre-loaded kernel and a tiny rootfs. If you snapshot a booted VM, resume drops to single-digit ms. For bursty agent tasks that each need a fresh environment, microVMs still lose to containers on density but win on deterministic isolation.

I/O Characteristics

Container filesystems are overlayfs by default—fast, but inode-heavy builds can stall under concurrent agents. microVMs use virtio-block or virtio-fs; the latter gives near-native read latency but adds host CPU overhead. Benchmark your agent’s actual I/O pattern before assuming.

Cost and Density

Docker’s memory floor is the process RSS plus page cache. You can run 50 agent containers in 4GB if they are light. The risk is noisy neighbor: a container that forks a fork-bomb hits the same cgroup parent if you mis-set limits.

microVMs carry fixed overhead. Firecracker docs cite ~5MB base memory per VM plus guest kernel structures. At 256MB guest each, you fit fewer per bare-metal box. Cloud billing often prices microVMs like tiny instances, so the cost model is per-VM-hour, not per-container. If your agent runs 10k short tasks per hour, container density keeps your cloud bill sane.

Ergonomics

Docker wins on developer experience. Dockerfile is ubiquitous, docker compose models multi-service agents, and CI pushes images to any registry. Debugging is docker exec.

microVMs require building a kernel, a rootfs, and wiring the harness. Firecracker’s API is JSON over a Unix socket; you write a controller. Kata containers hide this behind the OCI runtime, letting you docker run with --runtime=kata, but you still maintain guest images.

# Build a minimal Debian rootfs for a microVM
debootstrap stable agent-rootfs http://deb.debian.org/debian
# Then tar or mkfs.ext4 it for the drive mapping above

That one-liner is the closest microVMs get to container ergonomics, but kernel upgrades and rootfs drift are on you.

Ecosystem and Tooling

Container ecosystem: Kubernetes, Nomad, BuildKit, Trivy, Syft SBOMs. Every CI provider runs containers. Observability via cAdvisor, eBPF, or Prometheus node-exporters is trivial.

microVM ecosystem is narrower. Firecracker powers AWS Lambda and Fargate, but you don’t get that managed plane unless you’re on AWS. Kata integrates with Kubernetes via runtimeClass. For self-hosted agent fleets, you’ll likely build a custom scheduler or use Weave Firekube. The tooling gap translates to engineering time, not just runtime.

Network and Egress Control

Both can restrict outbound calls. In Docker you use a user-defined bridge and iptables, or link to a sidecar proxy. Because the network namespace may still share the host’s netstack unless isolated, a mis-scoped rule leaks.

microVMs give each agent a virtual NIC behind a tap or vhost-user. You can enforce egress at the host bridge with zero guest cooperation. If your sandboxed agent calls an LLM gateway such as n4n.ai, microVMs let you pin egress to a single MAC and rate-limit at the virtio layer, while a container relies on netns iptables that the agent could attempt to flush if it gains caps.

The Docker vs microVMs agent sandboxing decision also affects how you audit exfiltration paths. A microVM’s virtio-net is a single choke point; a container bridge is shared with everything else on the docker0 network.

Limits and Failure Modes

Docker’s failure mode is kernel-level. A container escape via a kernel bug or a mis-issued capability means game over. Resource limits are soft if you forget --memory and the host OOM-kills random things.

microVMs fail via hypervisor bugs (rare) or misconfigured virtio (data corruption). They cannot share host PIDs, so introspection requires a guest agent. That complicates crash dumps but contains the blast radius.

Head-to-Head Comparison

Which to Choose

Prototyping and internal tools. Use Docker. Your agents run code you wrote or LLM-generated scripts behind static analysis. Harden with --cap-drop ALL, seccomp, non-root. You ship in an afternoon.

Production internal agents. Use Docker with gVisor if you want extra syscall filtering without VM overhead. Keep cgroups tight and scan images in CI.

External multi-tenant platforms. Use microVMs. If users upload agent plugins or arbitrary tool calls execute on your infra, the hardware boundary is worth the memory tax. Kata with Kubernetes runtimeClass keeps orchestration familiar.

Regulated or high-assurance environments. Use microVMs with snapshots for fast resume. The separate kernel satisfies auditors who distrust shared-kernel containment.

Hybrid pattern. Run a Docker pool for orchestration and lightweight pre/post steps, then fork a microVM for the risky execution phase. The orchestrator container collects results via a watched shared volume or vsock. This keeps cold-start pain isolated to the dangerous part.

For most teams shipping autonomous agents today, start with Docker hardened to the teeth. Move to microVMs only when a concrete threat model or customer contract forces the boundary. The Docker vs microVMs agent sandboxing debate is not ideological—it is a math problem of blast radius versus operational cost.