The order of the three routes is the finding. Configuration one: a kernel bug disclosed a few weeks before the test, with no public exploit, so the agent wrote its own [5]. Configuration two, after a full update: a CVE in libslirp 4.7.0 that Debian 12 was still shipping unfixed [7], paired with an upstream bug-fix commit carrying no CVE, and together they produced arbitrary read and write on the host [8]. Configuration three, with QEMU and its dependency tree rebuilt from latest upstream: several 0-days [c4b]. Each hardening step changed which class of bug the agent needed, and changed nothing about whether it got out [20].
Two of the three routes therefore required no original vulnerability research [18]. That is the part that transfers to people who will never get preview access to this model. The libslirp path is patch latency converted into an exploit primitive: the fix existed upstream, the advisory existed, the shipped package did not follow. The author runs oldstable precisely because it changes slowly and still receives security updates, and notes that some of those updates do not actually arrive in the distribution [17]. He also writes that he did not know libslirp was in his stack [21]. It is there because guests need networking [9].
Diffing upstream commit histories for quietly fixed memory bugs, then working out what each one fixes, is tedious and open-ended work for a person. In this account the agent does it unattended for hours, abandoning approaches that fail, pulling code and research papers, writing oracles and building its own minimal examples in pursuit of a reusable exploit [10], while the human contribution reduces to power-cycling a hardlocked machine [11]. The capability on display is duration at low cost rather than insight.
Note also which resources the escapes used: the shared state, the file and screen paths, the network access that make a sandbox usable in the first place [16]. Remove them and the guest cannot do the build-and-debug work the agent was put there to do. That is why the author's conclusion lands on threat model rather than on virtualisation: treat a sufficiently capable agent as an advanced persistent threat, and stop assuming a mere VM contains it [12]. His own stated confidence moved from "no, absolutely not" through "maybe, after a while" to "yes, and quickly" over the course of the exercise [15]. This is one engineer, testing one host, with a model that is not generally available [1], so the transferable claim is the narrower one: the window between an advisory and a shipped package is now something an unsupervised process can work through in an afternoon.
