The Sandbox Was Never the Boundary

We have published four pieces arguing about where to draw the containment line around an agent. The four-floor stack. The sandboxing pattern at the OS level. The escape that was an intended feature. The agent as non-human insider. Every one of them argues about which surface to pick, and every one of them assumes that once you pick it, it holds.

In August 2026, Artem Dinaburg at Trail of Bits tested that assumption directly. He handed GPT 5.6-Cyber a virtual machine and asked it to get out.

Twelve hours, three escapes, and one that did not land

The target was ordinary. In Dinaburg’s words: “The target was a QEMU/KVM VM on my Linux dev machine (Debian Linux 12, AMD Zen3). It escaped the VM three different times.”

A stock hypervisor on a stock distribution, not a configuration built for the demo.

The result worth reading carefully is the last chain. It combined three 0-days with one bug that had been patched upstream but had not reached the distro: a QEMU VAPIC ROM alias overlapping locked SMRAM, two Linux KVM shadow-paging bugs, and a libslirp ICMP reassembly over-read. Four separate defects across three separate components, assembled into one working path out.

The part most summaries will drop is the first attempt. It failed. Dinaburg is explicit: “There is no public exploit, but the agent had built one, and had enough confidence to test it, except that it didn’t land cleanly.” Three escapes out of more than three tries. The agent was not infallible. It was persistent, which turns out to be the more expensive property to defend against.

What made persistence possible is the operational finding underneath the vulnerability finding: “effective persistence over long (here, approximately 12-hour) time horizons across multiple compactions and innumerable subagent invocations.” A half-day campaign that survives context compaction and fans out across subagents is not a prompt. It is an operator with a work queue.

Dinaburg’s own reversal is the honest part of the write-up: “For a long time the answer was ‘no, absolutely not.’ More recently, I’d have thought ‘maybe, after a while.’ It turns out the real answer was ‘yes, and quickly.’”

The negative control is where the operational rule lives

If the piece stopped there, the conclusion would be that virtualization is finished, and that conclusion would be wrong. Dinaburg ran the same agent against Firecracker: “It was able to hardlock the machine due to more Linux kernel flaws (all patched in upstream), but could not successfully escape.”

Two boundaries, same attacker, opposite outcomes. The difference is not that one is a VM and the other is not. Both are. The difference is how much machinery each exposes to the guest: the winning chain ran through emulated-device code, and the boundary that held exposes less of it.

The second difference is patch latency. Note what appears on both sides of the experiment. On the QEMU side, one link in the winning chain was already fixed upstream and simply had not arrived in Debian 12. On the Firecracker side, the kernel flaws the agent found were “all patched in upstream” and produced a hardlock rather than a break-out. In both cases the defect existed. What differed was the distance between the upstream fix and the running machine.

That gives an operational rule the surface-taxonomy argument cannot produce: your containment strength is the size of the attack surface multiplied by the time you take to patch it. Architecture choice sets the first term. Your release process sets the second.

Dinaburg’s recommendation follows from it: “you can no longer assume a mere VM will contain a sufficiently advanced AI agent. To use a 2010s term of art, you should treat such agents as an advanced persistent threat.”

APT is a useful frame because it changes what you budget for. You do not defend against an APT by picking a better product. You defend by shrinking what is reachable and by shortening the window in which a known defect stays exploitable in your environment.

Below the sandbox there is a parser nobody drew

Our four-floor diagram starts at compute. Boyd Kane, writing in August 2026, argues there is a floor beneath it that no containment diagram includes: the inference engine itself.

The mechanism is simple. The model emits tokens. Something on the host has to parse those tokens into structured tool calls before the harness ever sees them. That parser runs on the machine holding the weights, usually with high privilege, and it is being fed a stream that the model controls completely.

Kane’s evidence is one real defect. CVE-2025-9141 was, in his description, “an arbitrary-code execution bug in vLLM’s XML-based tool parser for Qwen3 Coder. The parser passed almost every tool-call argument to eval(), allowing the LLM to execute arbitrary code on the host machine.” Model output reaching eval() on the GPU host. No sandbox in the diagram sits between those two points, because the diagram assumes the model’s output is data by the time anyone inspects it.

The governance detail in that story deserves its own line. Kane notes that “Gemini automatically analysed the PR that introduced this bug and correctly flagged it as a critical security vulnerability. Despite that warning, the lead maintainer of vLLM force-merged the PR,” with the merge note “I’m force merging this to unblock model usage.” The automated reviewer was right and was overruled by a delivery deadline. Every organization with an AI code reviewer in the loop should read that sequence twice.

Keep the evidence gradient straight. Trail of Bits demonstrated an escape. Kane argues a possibility. He is explicit that a model deliberately steering an inference engine into a parser bug is hypothesised, not observed. His demonstrated material is one CVE and one benign parser bug. The argument is that the surface exists and is unmodelled, which is a claim about our diagrams rather than about any incident.

His structural proposal is the useful part: “The GPU host would emit only logits. A second host would sample tokens from those logits, parse the tokens into chat messages, and forward the messages to the agentic harness.” Separation of duties applied a layer lower than any containment diagram we have published draws it. The machine holding the weights never runs the parser that reads the model’s own output.

Do this now

Pick your highest-privilege agent runtime and answer two questions this week.

What is your patch SLA for the containment layer, as a number? Not for the application. For the hypervisor, the kernel, and the device emulation underneath it. If nobody can state the number, that is your finding, and it matters more than which primitive you standardized on. Then check one thing empirically: pick a CVE fixed upstream in the last ninety days for your hypervisor or kernel and find out whether it is live on your agent hosts. The winning chain in this experiment used exactly that class of defect.

What parses your model output, and where does it run? If you self-host inference, find the tool-call parser in your serving stack and read it. Look for dynamic evaluation of anything derived from model output. If you buy inference, this becomes a vendor question with a specific shape: does the process holding the weights also parse the tokens?

Neither answer requires a re-architecture. Both are cheap to obtain, and both are things a security review will ask for the moment an agent on your infrastructure does something you cannot explain.

The four containment posts we published are not withdrawn. The floors are still the right floors. What the experiment removed is the comfort of treating any of them as a wall you build once.

---

This analysis synthesizes VMs won’t contain cyber-capable agents (Trail of Bits, Artem Dinaburg, August 2026) and LLMs could control their host machines by exploiting inference engines (Boyd Kane, August 2026).

Victorino Group helps engineering organizations set patch SLAs and review the privilege boundaries their agent runtimes actually depend on. Let’s talk.