"Isolation" isn't a security property. It's a spectrum.

Trail of Bits published an important piece of security research: VMs won't contain cyber-capable agents. If you're running AI agents anywhere near production infrastructure, stop and read it. Then come back, because it validates an argument we've been making since day one at Edera, and it's worth explaining why.

What Trail of Bits found: An AI Agent Escaped a QEMU/KVM VM Three Times

Artem Dinaburg gave GPT 5.6-Cyber one job: escape a QEMU/KVM VM on his own dev machine. It didn't just succeed once. It escaped three separate times, over roughly 12 hours of autonomous operation, backtracking, hunting for bugs, writing its own exploit oracles, and chaining vulnerabilities with almost no hand-holding.

The first escape used a recently disclosed kernel bug. The second chained two libslirp networking bugs the distro hadn't patched yet. The third was the real wake-up call: the agent went bug-hunting across QEMU, KVM, and the host kernel from scratch and assembled a novel exploit chain out of three 0-days plus one already-fixed-upstream-but-not-backported bug, spanning QEMU's VAPIC emulation, KVM's shadow paging, and a crafted ICMP packet. It even found and evaluated a CUPS exploit path and a QEMU display-renderer heap overflow along the way, and discarded them only because they weren't the most reliable path to the flag.

Then they tried Firecracker, the industry's go-to "we already thought about this" answer. The agent couldn't escape it. But it did fully hardlock the host, using kernel bugs in the shared virtualization stack.

Why This Happened

QEMU exists to emulate real hardware for the guest: disks, GPUs, virtio devices, VAPIC, network cards. Every one of those is a parser, and every one of those parsers is written in C and exposed directly to untrusted guest input. That's not a QEMU-specific flaw. That's what device emulation is. An AI agent that can read source, write fuzzers, and reason about memory safety for twelve straight hours is exactly the adversary that class of code was never built to withstand.

Firecracker gets a lot right by ripping out most of that device model. But it still hands the guest a KVM interface into the host kernel's virtualization stack, and that stack is enormous, general-purpose, and shared across every guest on the box. Minimizing device emulation shrinks the target. It doesn't remove it. The agent proved that by DoS'ing the host without ever needing QEMU.

Where Edera Enters the Chat

This is the argument we've been making since we founded Edera: the entire Linux kernel should not be your trusted computing base.

"Isolation" gets used like it's one thing. It isn't. As our Head of Security, Jed Salazar puts it: “it's about as descriptive as calling something a "sport". Golf and boxing are both sports, but knowing something is "a sport" tells you almost nothing about how it's played, what it costs you if you get it wrong, or how to prepare. Same with isolation: knowing something is "isolated" tells you almost nothing on its own. What actually matters isn't whether something is labeled a VM, a container, or a sandbox. It's how much you trust the guest, and how much attack surface you've handed it to work with.

QEMU/KVM hands a guest a huge, C-based, host-kernel-resident attack surface by default. Firecracker/KVM hands it a smaller one, still inside the host kernel. The VMM is smaller, but the KVM interface remains the same. Edera's default guest mode hands it almost nothing: no device emulation at all. Our guests talk to our hypervisor through direct hypercalls, not through a giant emulated PCI bus and a pile of C parsers. And the hypervisor is truly minimal: delegating most operations to disaggregated user space components. A kernel bug inside an Edera guest is a bug inside that zone. It's not a bug in the thing standing between the guest and your host.

Defaults matter more than options. Kata Containers, for example, defaults to QEMU – which means the isolation properties everyone assumes they're getting from "Kata" actually depend on which VMM they picked. We don't ship a QEMU subsystem at all in our default path. The one piece of QEMU functionality we needed – 9pfs, for file sharing – we rewrote from scratch in Rust, specifically because parsing untrusted guest data in C is exactly the bug class this agent used to break out three times. Memory-safe by construction beats memory-safe by patch cadence.

Full Disclosure: Trail of Bits Has Audited Edera

Trail of Bits has assessed Edera for vulnerabilities (you can view the full audit upon request). No high-priority findings. 

If you're running agentic workloads – anything that can read code, write exploits, or operate autonomously for hours – inside Kubernetes, isolation strength is not a nice-to-have you can defer. This research shows a capable agent will find the gap between "sandboxed" and "actually contained" faster than your patch cycle can close it.

Great work by the Trail of Bits team. 

If you're evaluating how your infrastructure would hold up against this exact scenario, we'd love to chat. And if you'd like to learn about a similar experiment we ran, read on.

‍