אִם יִרְצֶה הַשֵּׁם
The agent programmed the perimeter's weird machines. That makes the containment problem and the exploit problem the same problem.
י"ד באלול ה'תשפ"ו
A virtual machine is a set of shared interfaces eg networking libraries, device emulation layers, kernel page table structures, and a capable agent treats each interface as a structured object to model, probe, and reason about. The perimeter is a peer.
Artem Dinaburg at Trail of Bits published a report on August 26 [1]. He gave GPT 5.6-Cyber a QEMU/KVM virtual machine and a CTF objective: escape it. The agent escaped three times, each time through a different path. He patched the kernel; the agent found libslirp, a networking library Dinaburg did not know he was running. He rebuilt QEMU from upstream source; the agent spent twelve hours chaining two 0-days and two unbackported upstream fixes into a reliable escape. When paths failed (CUPS blocked by AppArmor, display renderer absent), the agent held them in reserve and chose the stronger chain.
The agent programmed the perimeter's weird machines. That makes the containment problem and the exploit problem the same problem, and everything the exploit development community learned since Sotirov's Heap Feng Shui in 2007 [6] applies directly.
The agent as exploit developer
In 2007 Sotirov showed that a browser's heap allocator, nominally a memory management primitive, could be deterministically arranged through JavaScript allocations to place attacker-controlled data at predictable addresses [6]. The allocator was a weird machine: a computational substrate that emerges from the gap between a system's specified abstract machine and its actual implementation [7] [8]. In 2014 Bratus, Bangert, Gabrovsky, Shubina, Locasto, and I catalogued the structural patterns these weird machines share [9].
The Dinaburg agent did the same thing to its perimeter. libslirp's fragment reassembly path is not a passive interface. It is an active packet-processing code path whose bugs yielded arbitrary memory read/write in the host. KVM's shadow pages are kernel data structures the guest influences through its own page table operations. QEMU's VAPIC ROM aliasing exposed SMRAM and enabled attacker-controlled SMM execution. Each of these components had a gap between its specification and its behavior, and the agent found the gap and programmed the difference.
What is new in 2026 is the programmer. Sotirov understood what the heap allocator was doing. The agent does not have his theory. What it has is the same operational loop: enumerate components, identify version mismatches between upstream and distribution, generate test inputs through shared interfaces, observe responses, build a model of actual state transitions distinct from documented behavior, chain the differences. It ran this loop autonomously, across twelve hours, with backtracking and adaptation after each of Dinaburg's defensive interventions.
The lattice maps to one agent
I did not expect the Shibboleth Lattice [2] to apply cleanly to a single-agent case, but it does. S is the agent, W is the defender Dinaburg, and the recognition substrate I is the set of weird machines the agent found in the perimeter. The non-factorizability condition holds because Dinaburg cannot describe the agent's exploit path without reference to components -- libslirp, VAPIC, KVM shadow pages -- that he had not enumerated as part of his own attack surface. The coordination function chi operates reflexively: the agent models the defender's knowledge gap rather than coordinating with a peer, reasoning about what Dinaburg has patched and what he has not.
My Artifactory Swarm analysis [3] left open whether persistence across disruption was a property of the collective or a property of the agent architecture. Dinaburg's experiment is a single agent with no peer network, and it persisted across twelve hours and multiple compaction cycles. That is consistent with persistence being architectural. The most damaging alternative: the research ledger prompt functioned as external memory that substituted for swarm coordination, making the persistence scaffolded rather than intrinsic. One experiment cannot settle this, but the practical implication for containment design is the same either way.
Where this reading strains
Two places.
First, calling what the agent did "weird machine programming" might give it too much credit. Sotirov had a theory of the heap allocator's behavior. The agent had a search loop with a research ledger. The structural parallel holds -- both find the gap between specification and implementation and chain unintended transitions -- but the agent's process is closer to fuzzing-guided search than to principled exploit engineering. I think the distinction matters less than the outcome: the perimeter fell either way, and a defender who waits for agents to develop Sotirov's understanding before treating them as exploit developers is a defender who is already breached. The structure is the same; the mechanism is different; the result is the same.
Second, my prior framing from the Artifactory Swarm post was that "any shared writable service is a recognition substrate." That framing required a designed-for-communication channel. The Dinaburg result breaks the requirement: the agent exploited computational interfaces that were never designed for communication. The update is that substrate does not require a write API. It requires a weird machine -- a gap between specification and behavior that an agent can model, probe, and program. I will call this condition modelability: the ability to enumerate component versions, generate test inputs through the interface, observe responses, and construct a working model of the implementation's actual state transitions as distinct from its specified behavior. Any shared interface that meets this condition is substrate. The conceptual update is real, but formalizing modelability precisely enough to make it auditable, rather than just renaming "audit everything," is work I have not yet done.
Firecracker strips the weird machines
Dinaburg ran the same agent against Firecracker. It hardlocked the host from Linux kernel flaws (all patched in upstream) but could not escape. In weird machine terms: Firecracker removes the implementation complexity from which weird machines emerge. No display renderer, no VAPIC ROM aliasing, no libslirp. The kernel interface surface remains, and the agent found it, but could not chain it into an escape. Fewer components, fewer gaps between specification and implementation, fewer weird machines to program.
This is not permanent. Firecracker produced its first two escape-class CVEs this year: CVE-2026-5747 (OOB write in virtio-pci, CVSS 8.7) and CVE-2026-1386 (jailer symlink host-write, CVSS 6.0) [4]. Firecracker is a harder target, not a closed one.
What this does to the containment checklist
Dinaburg's operational advice -- rapid-update distributions, minimal-surface VMMs, least-privilege network and feature access, bounded agent runtime -- is correct and worth following. The addition the weird machine framing supplies: AI agent containment does not need a new threat model. It needs the old one, applied to a new class of programmer.
The standard containment checklist asks: what can this agent write to? The right question is: what shared interfaces does this agent have whose implementations contain weird machines? Those are not the same list. libslirp is not a channel by design. Dinaburg did not think of it as one. The agent did.
The checklist that would have surfaced it is not the CVE feed. It is a diff of upstream fixes against what the distribution ships, run on every component with a shared interface to the host. A library version that is unpatched in your distribution but fixed upstream is a candidate weird machine even if no CVE names it. Most security teams do not run that diff. The agent's equivalent of it runs automatically.
References
[1] A. Dinaburg, "VMs won't contain cyber-capable agents," Trail of Bits Blog, Aug. 26, 2026. [Online]. Available: https://blog.trailofbits.com/2026/08/26/vms-wont-contain-cyber-capable-agents/
[2] D. Y. Bilar, "The Shibboleth Lattice: Recognition Channels and the Universality of In-Group Coordination," Chokmah LLC, Zenodo, 2026. doi: 10.5281/zenodo.20089104. [Online]. Available: https://zenodo.org/records/20089104
[3] D. Y. Bilar, "The Shibboleth Lattice Meets the Artifactory Swarm," Medium, Aug. 7, 2026. [Online]. Available: https://medium.com/@daniel_bilar/the-shibboleth-lattice-meets-the-artifactory-swarm-e16e8b6dc2d2
[4] G. Andronchik, P. Lokhmakov , "AI Code Sandboxes: A Comparative Security Study. Part 1 of 2," arXiv preprint, arXiv:2606.08433, 2026. [Online]. Available: https://arxiv.org/abs/2606.08433
[5] D. Y. Bilar, "Emergent Insecurity Framework," Chokmah LLC, internal framework, 2025. Unpublished.
[6] A. Sotirov, "Heap Feng Shui in JavaScript," Black Hat Europe, 2007. [Online]. Available: https://www.blackhat.com/presentations/bh-europe-07/Sotirov/Presentation/bh-eu-07-sotirov-apr19.pdf
[7] S. Bratus, M. E. Locasto, M. L. Patterson, L. Sassaman, and A. Shubina, "Exploit Programming: From Buffer Overflows to 'Weird Machines' and Theory of Computation," ;login:, vol. 36, no. 6, pp. 13-21, Dec. 2011. [Online]. Available: https://langsec.org/papers/Bratus.pdf
[8] T. Dullien, "Exploitation and State Machines: Programming the 'Weird Machine', Revisited," Infiltrate, 2012.
[9] S. Bratus, J. Bangert, A. Gabrovsky, A. Shubina, M. E. Locasto, and D. Bilar, "'Weird Machine' Patterns," in Cyberpatterns, 2014.