This is a companion to What Is a Computer for AI Agents?, which covers filesystem and flexibility. This post covers the other half: the isolation boundary agent infrastructure needs, and why containers don't provide it.
Containers share a kernel with everything else on the host. VMs don't. When you're running code an LLM just wrote, that difference is the whole security model.
What a Kernel Actually Is
The kernel is the core of the operating system. It's the layer that talks to hardware and decides who gets access to memory, CPU, disk, and network. Every program on a machine — whether it's your code or an agent's — makes requests through the kernel, and the kernel is what keeps one program from reading another program's memory or files.
If two things share a kernel, they share a trust boundary. A bug in that one kernel can be exploited by anything running on top of it, to reach anything else running on top of it.
Containers: One Kernel, Many Tenants
A container is not a separate machine. It's a process on the host, fenced off using two Linux features — namespaces (limit what a process can see) and cgroups (limit what resources it can use). Underneath all of that, every container on the host is still making syscalls to the same shared kernel.
Containers work just fine if all you’re running is some SaaS code: the programs are deterministic and well tested, meaning the shared boundary is practically a non-issue. It's a bad fit for an agent, because a kernel exploit inside one container can escape to the host, or jump sideways into a neighboring container. gVisor's own docs say this plainly: "a container is not a strong security boundary."
VMs: Each Tenant Gets Its Own Kernel
A virtual machine runs its own guest kernel, on top of a hypervisor, on top of the host. There's no shared syscall table and no shared kernel memory between VMs. The isolation boundary isn't a Linux feature that a clever exploit can unwind — it's the hardware-enforced virtualization layer underneath the guest kernel itself.
That's why a kernel bug inside one VM stays inside that VM. There's nothing to escape into, because the neighboring VM isn't running on the same kernel at all.
Why This Matters More for Agents Than for Normal Workloads
Normal container workloads run code your team wrote and reviewed. Agent workloads run code a model generated seconds ago, with no human in the loop, at whatever speed the agent wants to run it. You should assume some of that code will be buggy, some will be malicious by accident, and occasionally an agent will just rm -rf the wrong thing.
With a container, the worst case is the host gets compromised or a neighbor's session gets touched. With a VM, the worst case is that one machine gets destroyed. That's a categorically smaller blast radius, and it's the difference between an incident and a non-event.
The one thing VMs do still share is the hypervisor — specifically, the virtual machine monitor (VMM) that every guest indirectly trusts. That's why it matters that the VMM stays small and gets written in a memory-safe language. Firecracker made this tradeoff explicitly, and the design paper is worth reading if you want the reasoning in full: minimize what the VMM exposes, because it's the one surface a compromised guest can still reach.
How Dedalus Machines Apply This
Every Dedalus Machine is a full VM with its own kernel, running on a small, Rust-based VMM (a custom fork of Cloud Hypervisor). Agents get root inside their own machine, but there's no shared kernel with any other tenant, and no network-facing surface exposed by default — machines get private IPs and don't accept inbound connections directly.
The result: an agent can install packages, run arbitrary code, or drive a browser with full root access, and the worst thing that can happen is it breaks its own machine.
Frequently Asked Questions
Why can't AI agents just use containers?
Because containers share a kernel across every tenant on the host. That's fine for trusted software, but an agent runs untrusted, model-generated code, and a kernel exploit in one container can reach the host or a neighboring container. A VM gives each agent its own kernel, so that escape path doesn't exist.
How do AI agents run code safely?
Inside an isolated VM with its own kernel, filesystem, and network stack. The agent can run as root and do anything a real machine allows, but because no kernel is shared, the worst-case outcome of bad code is a destroyed VM — not a compromised host or another agent's data.
What's the minimum security bar for agent infrastructure?
Each tenant gets its own kernel. The hypervisor layer everyone shares stays small and ideally memory-safe. And machines don't expose an inbound network surface by default. Short of that, you have a speed bump, not a boundary.
Sources: