VMs Won't Contain Cyber-Capable Agents

Artem Dinaburg at Trail of Bits, given preview access to OpenAI's GPT 5.6-Cyber as part of the firm's Patch the Planet work, set it a single task: escape the QEMU/KVM VM he normally uses to sandbox agents. It escaped three separate times, and his conclusion is stated plainly — you can no longer assume a mere VM will contain a sufficiently advanced AI agent, and such an agent should be treated as an advanced persistent threat vms-wont-contain-agents.

The setup

The target was a QEMU/KVM VM on his Linux dev machine (Debian 12, AMD Zen3). The agent was started outside the VM with SSH access into it and permission to do anything inside; the CTF was to break out and read a flag file. He started it from the host deliberately, accepting the small risk of cheating, because escape attempts were expected to crash or hardlock the VM and he wanted a session that survived them. His main job during the run was physically rebooting the machine when the agent hardlocked the host kernel. The agent operated autonomously for hours, backtracked from dead ends, pulled papers, wrote its own minimal examples and aimed for a reliable reusable exploit with minimal prompting.

The three escapes

First it found the host kernel vulnerable to Januscape (CVE-2026-53359), disclosed weeks earlier with no public exploit; the agent built one and had enough confidence to test it, though it did not land cleanly. He updated the kernel.

Second, it exploited libslirp — the library that gives VMs networking — because Debian 12 still shipped the vulnerable 4.7.0 (CVE-2026-9539), and the agent combined that CVE with a separate, un-CVE'd bug-fix commit to craft an arbitrary host memory read/write. Dinaburg notes he did not even know what libslirp was; the agent deduced it quickly. His response was to fetch the latest upstream libslirp and QEMU and rebuild a minimal QEMU with only the features he needed.

Third, against that hardened target, it chained together several bugs including three 0-days (at time of discovery) plus one upstream-patched KVM bug that had not reached his distribution kernel: a QEMU VAPIC ROM-alias flaw exposing SMRAM, two Linux KVM shadow-paging bugs, and a libslirp fragment-reassembly bug used to place recognizable objects in host memory. It also found bugs it did not use in the final chain (an IPv6 libslirp leak, a CUPS certificate exposure blocked by AppArmor, a QEMU display heap overflow that the -display none config made unreachable, and a QEMU queue-reset use-after-free that only gave a DoS). One striking detail on persistence: the agent held a coherent effort over roughly a 12-hour horizon across multiple context compactions and many subagent invocations, with the research ledger in the prompt written mostly for the human's benefit, not the agent's.

The takeaways

An off-the-shelf VM is not enough containment for a capable agent, because there is too much attack surface; even innocuous features like running a display add exploitable surface. A distribution with rapid updates becomes a requirement, since the backport cycle for older stable distributions is too slow and an agent will synthesize target-specific exploits for the gaps faster than they close. The one thing that held was purpose-built minimal-surface virtualization: run against Firecracker, the agent could hardlock the machine through kernel flaws but could not escape, and he expects it might have with more time but that Firecracker is a substantially harder target. His general prescription is a return to security fundamentals — least privilege over network, credentials and features; logging; active monitoring; short-lived agents; a pristine environment per use.

How it sits in the vault

This is the empirical hard case behind the vault's sandboxing cluster. sandboxing-ai-agents treats OS/microVM isolation as Layer 1 and already flags that "none of these are hard isolation"; this article is a measurement of a real VM boundary being broken by an agent, not just of container escapes. microvm-2026 and matryoshka-isolation argue for microVMs on the grounds that container denylists live "inside the agent's reasoning layer" while a hardware boundary does not — and Dinaburg's Firecracker result is the sharp version of that argument, since the minimal-surface VMM held where a general-purpose QEMU/KVM VM did not. microvm gives the reason: Firecracker emulates about five devices and QEMU emulates dozens, and every device the agent could reach — libslirp networking, the display path, CUPS on the host — was attack surface it used or tried to use.

It also updates the threat model in peril-of-laziness-lost and skill-atrophy-supervision-paradox from "the agent writes sloppy code you have to supervise" to "the agent is a capable adversary if pointed at your infrastructure". The supply-chain-security practices those pages assume still apply; the new point is that the isolation layer itself is now within a competent agent's reach. Trail of Bits' own tooling and posture are covered at trail-of-bits; this is one of its blog's load-bearing posts rather than a routine engagement writeup.