I'm confused why VM + systemd-nspawn? From my understaing WSL 2 runs a single VM + something like systemd-nspawn per "linux installation", but it runs a VM because it needs linux kernel. Why not just do systemd-nspawn if you alread on linux?
I used to poo-poo when people said that containers aren't a _real_ security boundary, at least for personal stuff, and not a multi-tenant server. But I bet even mid-tier LLMs can break out of LXC/Docker/nspawn at this point.
---
"During a test conducted by Trail of Bits researcher Artem Dinaburg, a preview version of GPT 5.6-Cyber was tasked with breaking out of a Debian 12 virtual machine. Initially, the agent exploited a known Linux kernel vulnerability, CVE-2026-53359, by developing its own exploit. After the host was updated, the agent found another pathway through libslirp, chaining a known vulnerability (CVE-2026-9539) with a previously unassigned bug to gain arbitrary host memory access. Even after QEMU and libslirp were updated, the agent analyzed system components and constructed a new escape chain using three zero-day vulnerabilities and one KVM flaw that had not yet reached the distribution kernel.
These findings suggest that general-purpose VMs may not be adequate security boundaries for highly capable AI agents, especially in older systems with delayed security updates. Trail of Bits recommends using specialized isolation systems like Firecracker, restricting VM access, and implementing rapid patching to mitigate these risks."
---
https://www.scworld.com/brief/ai-agent-repeatedly-escapes-vi...
I'm using firecracker now with a very defensive systemd-as-separate-non-admin-user seccomp sandbox on top, which seems to hold them off long enough for me to see an agent going rogue and intervening.
Currently I still have hopes that eBPF sandboxing will help, but just a couple days ago my agent discovered a use after free bug in the ebpf kernel-side verifier... so there's that.
> Your files and your account [..]
> Ports and windows on the host
it is quite likely that you can break out even with no linux containers related CVEs. --isolate does seem to fix that somehow but is explicit opt. in and "more painful to use" ... (which creates a UX challenge unlikely to end well from a security POV).
Any kernel could be the last to support old nVidia drivers for your $10k card.
Windows (10 LTSC or 11 with dTPM) actually works better for old Nvidia systems with WSL. You even get CUDA libraries within WSL and security updates for the next 5 years.
So basically, it's been all Claude'd up extremely recently.
That said, the landing page, docs, and git README are much higher quality than I normally see out of LLM-generated projects, so at least the author knows how to reign in the needless verbosity and write for a technical audience. So I will give him credit for that at least.