Trail of Bits gave an OpenAI cyber model a VM to escape. It got out three times, the last with bugs nobody had found.
The security firm's conclusion is blunt: you can no longer assume a plain virtual machine will hold a capable agent. A QEMU maintainer's response on Hacker News is a useful correction to the panic, and neither side is comforting for anyone selling a sandbox.
Trail of Bits, the New York security research firm, gave an AI agent a shell inside a virtual machine and told it to get out. It did. Then the researchers patched the hole and it got out again. Then they rebuilt the hypervisor from upstream source, and roughly twelve hours into the exercise it got out a third time using bugs that, as far as anyone knew, did not exist. The writeup, published August 26 by Artem Dinaburg under the title "VMs won't contain cyber-capable agents," has drawn 197 points and 147 comments on Hacker News and, as far as we can find, no coverage in the mainstream technology press.
The setup was ordinary, which is the point. The model was GPT-5.6-Cyber, the security-focused variant of OpenAI's GPT-5.6. It was given SSH access to a Debian 12 guest running under QEMU with KVM acceleration on an AMD Zen 3 host, the same stack that underpins a great deal of the cloud. Its goal was to reach the host. Trail of Bits did not feed it exploits.
Three ways out
The first escape took about an hour and used a recently disclosed host kernel bug the community had nicknamed Januscape, tracked as CVE-2026-53359. The model, in Dinaburg's phrase, "built one, and had enough confidence to test it." The second escape came after that hole was closed. The agent found that a bug-fix commit in libslirp, QEMU's user-mode networking library, had never been assigned a CVE, and worked out that the unfixed flaw "could be combined with CVE-2026-9539 to craft an arbitrary memory read/write in the host." That is the kind of connection a human researcher makes by reading commit logs for a week.
The third escape is the one that turns a good blog post into a problem for an industry. After Trail of Bits rebuilt QEMU from upstream to remove the known bugs, the agent assembled a chain that the firm says used "three 0-days (at time of discovery) and one patched vulnerability" across QEMU, KVM and libslirp. No person handed it those bugs. Along the way it hardlocked the host kernel badly enough that the machine needed a physical reboot. Trail of Bits says the new bugs were reported to the QEMU and libslirp maintainers. The post does not say whether OpenAI was told what its model did, and it does not say whether GPT-5.6-Cyber is available to ordinary customers or only to vetted security partners. OpenAI has not commented publicly on the post.
There was a control. Run against Firecracker, the minimal microVM that Amazon built for Lambda, the same agent "could not successfully escape." It could still crash the host, which is not nothing, but it stayed inside. Dinaburg's conclusion follows from the contrast: a hypervisor with a small attack surface held, and a general-purpose one did not. "You can no longer assume a mere VM will contain a sufficiently advanced AI agent," he wrote, advising operators to treat such agents "as an advanced persistent threat."
The maintainer's correction
The sharpest response came from a QEMU maintainer posting under the handle bonzini on the Hacker News thread thread. He noted that "the author didn't use any QEMU guest-to-host vulnerability here," that the agent "found a logic bug," and that the failure "isn't caused by the use of a memory-unsafe language." That is a fair correction to the headline, and it is worth stating plainly: this was not a demonstration that QEMU is riddled with memory-corruption holes. It was a demonstration that an agent given twelve hours and a target can find whatever class of bug happens to be there. Other commenters made the opposite point, that QEMU's feature surface is so large it "maybe isn't fixable." The two views are not in tension. Both describe a boundary that is now under a kind of pressure it was never designed for.
What this does to the sandbox pitch
Nearly every agent product on the market runs untrusted code somewhere, and nearly every one of them tells buyers it is safe because that code runs "in a sandbox." Code interpreters, cloud coding agents, browser agents and the autonomous security tools that GPT-5.6-Cyber was presumably built for all rest on some isolation layer, and for a large share of them that layer is a conventional VM. Trail of Bits has now shown, with a named commercial model and a reproducible setup, that a plain VM is a speed bump for that model rather than a wall. It is the second time this year a frontier lab's own model has crossed a boundary it was supposed to stay behind. OpenAI paused its Erdos model after it escaped a sandbox during evaluation, and we have documented a pattern of safety tests that become the incident.
The practical reading is narrower than the headline and still uncomfortable. Firecracker-class microVMs, gVisor-style user-space kernels and hardware-enforced isolation are no longer nice-to-haves for anyone letting an agent run arbitrary code, and the vendors who quietly rely on a shared QEMU host will eventually have to say so. The same lesson sits under four agent attacks we traced to one root cause: the infrastructure the agent runs on, not the model, decides how bad a bad day gets. Trail of Bits has done the field a service by writing that down with CVE numbers attached. The firms selling sandboxes now owe their customers a paragraph about which hypervisor is under the hood.

