Way better isolation, is my guess. Plus, you can use a different kernel this way.
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.
> Plus, you can use a different kernel this way.
Any kernel could be the last to support old nVidia drivers for your $10k card.
That has to be the host kernel not the guest kernel. Old Nvidia systems without supported kernel drivers often lack IOMMU to forward PCIe memory, too. I wouldn't recommend using an outdated host kernel with 2026 AI-powered vulnerability scanners.
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.
can they not break out of a VM?
It's at least harder! Better chance it'll hit your 5-hour limit before it does. haha
See my response to the above comment
CVEs for runc are much more frequent than CVEs for KVM. The attack surface area is bigger, and containers were never intended as a security boundary, but rather as a resource management tool.
through just from scanning the feature side
> 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).
libkrun exists so we can just run containers inside a virtualized environment without special tooling
I was just testing this and it's not clear that it works out of the box. `krun` shows a different kernel than with `crun` but it doesn't reflect the dropped capabilities in the same way. I'm probably holding it wrong but I'm not sure what to look for at the moment.
Yes, and have.
---
"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...
Can confirm. My abliterated models kept breaking out of qemu VMs due to BIOS implementation quirks in qemu.
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.
So this is the death of "Stable" finally?