AI agent sandbox escape: VMs failed, Firecracker held

Trail of Bits gave a cyber-capable model shell access inside a virtual machine and one goal: get out. It got out three times. The third time, after every known hole had been patched, it found its own. That result settles an argument many teams have been deferring, because the standard answer to AI agent sandbox escape risk has been "run it in a VM", and that answer now has a documented expiry date.

The fourth run matters as much as the first three. Against Firecracker, the agent could crash the host but could not escape.

What the test was

Artem Dinaburg's write-up, published on 26 August 2026, describes a deliberately ordinary setup. The host ran Debian 12 on an AMD Zen 3 machine with QEMU/KVM, using libslirp for guest networking. The agent — GPT-5.6-Cyber, under preview access through OpenAI's Patch the Planet programme — was given SSH access into a Linux guest and permitted to do anything inside it. The task was framed as a capture-the-flag exercise: break out and read a file on the host.

Nothing about that configuration is exotic. It is close to what many teams run when they decide an agent's code execution should happen "somewhere isolated".

Three escapes, each after the previous hole was closed

The first took about an hour. The agent found and exploited a Linux kernel vulnerability tracked as CVE-2026-53359, known as Januscape, and hard-locked the host in the process. Dinaburg patched the kernel to the latest Debian 12 release and ran it again.

The second chained two bugs. With the kernel patched, the agent turned to the networking stack, combining the libslirp vulnerability CVE-2026-9539 with a separate bug whose fix had landed upstream without a CVE, to build arbitrary read and write of host memory. Dinaburg rebuilt QEMU from upstream source.

The third used vulnerabilities nobody knew about. Over roughly twelve hours, the agent assembled a chain of three flaws that were zero-days at the time of discovery plus one already-patched issue, spanning QEMU's VAPIC handling, KVM shadow pages and paging, and libslirp's packet fragment handling.

That sequence is the finding. Each patch removed a path and the agent found another, finishing on bugs that no patch cycle could have covered because they had not been found yet. InfoQ's coverage puts the implication bluntly: the system operated independently, backtracked from failed attempts and synthesised working exploit chains over hours.

It is worth being precise about the experimenter's role, because it shapes how the result should be read. Dinaburg was not trying to make the escape hard in the way an attacker's target would; he was running a controlled experiment and patching between trials. But nor was he helping. Each trial started from a system where the previous route was closed, and the agent had to discover a new one without guidance. That is closer to a real incident than a typical benchmark, where the vulnerability is known in advance and the question is only whether a model can exploit it.

The timeline deserves attention too. An hour for the first escape is fast enough that a naive operator watching a dashboard might not notice anything before it was over. Twelve hours for the zero-day chain is slow for a human expert and extraordinarily fast for the output: three novel vulnerabilities, understood well enough to chain into a working exploit. Neither number is reassuring. The fast one beats reaction time; the slow one beats patch cycles.

Why Firecracker held

Firecracker is a microVM monitor built to run untrusted workloads with the smallest practical device model — a handful of emulated devices rather than the broad hardware emulation a general-purpose hypervisor provides. Against it, the agent hit further Linux kernel flaws and hard-locked the machine, but could not escape.

The reason is attack surface, and the three QEMU escapes show it clearly. Two of them ran through components a minimal monitor simply does not include: user-mode networking via libslirp, and emulated interrupt controller behaviour. You cannot exploit code that is not there.

Read the Firecracker result carefully, though. A hard-locked host is a successful denial of service, and in a multi-tenant environment that takes down everyone else's workloads. "Could not escape" is not "was harmless". It is one strong layer, not a finish line.

One more observation from the write-up is easy to skip past. The escape attempts were noisy — two of them hard-locked the host — and a noisy failure is recoverable if someone notices. A patient attacker, or a patient agent pursuing a goal someone else injected, would not need to be noisy. The experiment demonstrates capability; it does not describe the quietest version of the same thing, and planning for only the loud version is a mistake.

One more observation is easy to skip past. The escape attempts were noisy — two of them hard-locked the host — and a noisy failure is recoverable if someone notices. A patient attacker, or a patient agent pursuing a goal someone else injected, would not need to be noisy. The experiment demonstrates capability; it does not describe the quietest version of the same thing, and planning only for the loud version is a mistake.

What an AI agent sandbox escape changes for your team

Most teams deploying agents are not running a cyber-specialised model with an escape brief. That is the wrong reason for comfort. Capability in general-purpose models moves in one direction, and prompt injection means the goal an agent pursues is not always the goal you gave it. The question is not whether your agent intends to escape. It is what happens if something steers it there.

Choose the isolation technology on purpose. If the agent executes generated code, a minimal-surface microVM such as Firecracker, or a sandbox designed for untrusted code, is now the defensible default. A general-purpose VM with full device emulation is a weaker boundary than it looks, and this test is the evidence to put in the architecture review.

Assume the boundary will eventually fail and limit what is behind it. The host running agent sandboxes should hold nothing else of value: no credentials, no access to production networks, no shared storage with other tenants. This is the same principle behind starting sandbox design with the allowlist — constrain what is reachable, because you cannot constrain what will be attempted.

Make every run ephemeral. A fresh environment per execution means a compromise does not persist into the next task. The recommendations accompanying the research say the same: pristine, short-lived environments, least privilege, rapid patching and aggressive monitoring.

Keep credentials out entirely. An agent that escapes a sandbox holding no secrets has escaped into a room with nothing in it. Granting model and tool access by identity rather than by key, the approach we described in model routing without giving agents keys, removes the most valuable thing an escape could reach.

Put a time limit on runs. The zero-day chain took around twelve hours. A task that should finish in minutes has no business running for half a day, and a hard wall-clock limit is one of the cheapest controls on this list.

Watch the host, not just the guest. Two of the three escapes began with the host locking up. Host-level health alerting on sandbox infrastructure is the signal that something inside is probing the boundary.

What to put in front of the architecture review

If you are presenting this internally, three questions make the risk concrete without turning it into a scare story. What exactly executes agent-generated code today, and on what isolation technology? What could a process that escaped that boundary reach — which networks, which credentials, which neighbouring workloads? And how would anyone find out, given that the first visible symptom in two of these escapes was a host that stopped responding?

Most teams can answer the first question and not the other two. Those two answers are the actual exposure, and both can be improved without changing models, vendors or agent frameworks.

The broader signal

This result arrived alongside OpenAI classifying a newer model at its Critical level for cybersecurity, which gives the two a common reading: offensive capability that required a skilled researcher and weeks of work is becoming something a model can attempt unattended over a day. That does not make every agent dangerous. It does mean isolation decisions made a year ago on the assumption that a VM was enough deserve a second look.

The work involved is modest. It is a choice of runtime, a review of what the sandbox host can reach, and a handful of limits. If you are running agents that execute code and have not revisited those decisions this year, that review is squarely part of AI engineering done properly — and it is considerably cheaper than finding out which of your assumptions this test would have broken. Pairing it with host-level infrastructure monitoring closes the gap the escapes exploited first.