Guide · Isolation explained
Docker containers vs microVMs: which isolates an AI agent better?
Updated
A microVM isolates an AI agent more strongly than a Docker container. A container's processes make system calls straight into the host kernel, so a kernel bug or a container-runtime flaw can become a host escape; a microVM gives the agent its own guest kernel behind a hypervisor, so it has to break two layers instead of one. A hardened container is often enough for code you trust; a microVM is worth it when the agent writes and runs code nobody has reviewed.
01Steps
- See which kernel your containers use. On a Linux host, a container reports the host's kernel release, because it is the host's kernel. On a Mac, Docker Desktop runs containers inside one Linux VM, so they share that VM's kernel with each other.
- If you stay with a container, harden it. Drop capabilities, block privilege gain, run as non-root, mount only the project, and cut the network.
- Check that the default seccomp profile is active. Docker applies a default seccomp profile that blocks a list of system calls. Never run agents with --privileged or seccomp=unconfined.
- For a separate kernel, run the agent in a microVM. With kosa8, for example, each sandbox is a VM with its own Linux kernel. This one has no network and a read-only project folder.
02Does a container protect the host from an AI agent?
Partly. Namespaces, cgroups, dropped capabilities and a seccomp filter limit what a containerised agent can see and call, but every system call it makes is still handled by the host's own kernel. Any kernel bug reachable from inside the container, or a flaw in the container runtime, can turn into access to the host.
That matters more for an AI agent than for a typical service: its job is to run code it just wrote or downloaded, and prompt injection in a README or package can steer that code.
03What kinds of container escapes have actually happened?
Two classes recur in the CVE record: flaws in the container runtime, such as runc's CVE-2019-5736 and CVE-2024-21626, and Linux kernel bugs reachable from inside a container, such as CVE-2022-0185, CVE-2022-0492 and CVE-2022-0847. All of these are patched; the point is the pattern, not the individual bugs.
- CVE-2019-5736 (runc). A process running as root in a container could overwrite the host's runc binary through
/proc/self/exeand gain root on the host. - CVE-2024-21626 (runc, "Leaky Vessels"). A leaked file descriptor could give a container process a working directory in the host filesystem; a malicious image could use it at
runc run. - CVE-2022-0185 (Linux kernel). A heap overflow in filesystem-context parsing, reachable by an unprivileged user when unprivileged user namespaces are enabled, allowed privilege escalation.
- CVE-2022-0492 (Linux kernel). The cgroups v1
release_agentfeature could be used to escalate privileges and bypass namespace isolation. - CVE-2022-0847 ("Dirty Pipe"). An unprivileged local user could write to page-cache pages of read-only files, and so escalate privileges on the kernel the container shares.
04Can a microVM be escaped too?
Yes, in principle. Hypervisors and their emulated devices have had bugs: CVE-2015-3456 ("VENOM") was a flaw in QEMU's virtual floppy controller that could let a guest user crash the VM or possibly run code in the QEMU process on the host. MicroVM designs respond by shrinking that surface: Firecracker exposes a minimal device model and adds a jailer as a second line of defence. The difference is that an attacker in a microVM needs a guest-kernel exploit and then a hypervisor or device exploit, while one in a container needs one bug in the kernel or runtime it shares with the host.
05How do the isolation properties compare?
| Property | Container (runc) | Container under gVisor | MicroVM | Full VM |
|---|---|---|---|---|
| What handles the agent's system calls | The host kernel, shared | gVisor's Sentry, a kernel in user space | Its own guest kernel | Its own guest kernel |
| Boundary between agent and host | Namespaces, cgroups, capabilities, seccomp | Sentry, plus a narrow interface to the host kernel | Hardware virtualization and a minimal device model | Hardware virtualization and a full device model |
| A host kernel bug reachable from inside | Yes, directly | Only through the calls the Sentry makes | No; the guest kernel is hit first | No; the guest kernel is hit first |
| Linux syscall compatibility | Full | Most, not all | Full | Full |
| Start-up and overhead | Lowest | Low; syscall-heavy work is slower | Low; boots a small kernel | Highest |
06When is a container enough for an AI agent?
A container is usually enough when the code is yours or reviewed, the host kernel and runtime are patched, the container runs as a non-root user with capabilities dropped and no extra privileges, and it holds no secrets worth stealing. It is the cheapest and most compatible option.
07When is a microVM worth it for an AI agent?
A microVM is worth it when the agent runs code that nobody has reviewed, installs packages on its own, or runs unattended, and when the machine it runs on also holds things you care about, such as your home directory, SSH keys or cloud credentials.
One caution applies to every option: a folder you mount in is writable from inside unless you mount it read-only.
08Other options
- Firecracker runs microVMs on Linux with KVM, with a minimal device model and a jailer.
- Kata Containers runs each container or pod in a lightweight VM with a dedicated kernel, behind the OCI and Kubernetes CRI interfaces, on QEMU, Cloud Hypervisor or Firecracker.
- gVisor is not a microVM: it is an application kernel written in Go that runs in user space and handles the container's system calls itself. It fits when you want a smaller host-kernel surface without running VMs.
- Docker Sandboxes runs each agent in its own microVM with its own Linux kernel and its own Docker daemon.
- kosa8 gives each sandbox its own microVM and kernel on an Apple silicon Mac (Apple's Virtualization framework) or x86-64 Linux (KVM with Cloud Hypervisor), with a Docker-compatible API. Its everyday
kosa8 runengine is one shared VM, where containers are separated from each other by ordinary container isolation;kosa8 sandboxandkosa8 agent rungive each workload a VM of its own. - Hosted sandboxes (E2B, Daytona, Modal) or a full VM in UTM or Lima fit when you want the agent off your machine, or a guest you manage yourself.