If your threat model is that of a malicious agent that will use a 0-day LPE to get root and exfiltrate all of your SSH keys, virtualization makes sense. But then, I wouldn't run such an agent at all, if not specifically in the context of malware analysis.

If you're just concerned about "agent messing up and taking the rules in some markdown files more laxly than I would have", then running it as a seperate user is totally enough...

Threat model is supply chain attacks on unmaintained package repositories like npm, pip and cargo. Everything on my host comes from my Linux distribution's repositories. Everything else gets virtualized with extreme prejudice. I'll even virtualize my Steam games one of these days.

IMO the threat model is more letting the agent loose on issues/PRs in a public Github repo and it getting tricked into running a malicious payload.

What kind of things are you even doing that the agent would try to perform a kernel exploit on you? I thought sandboxing is just to protect from the agent accidentally clearing your home directory.

Side note, just 6 days ago a Linux VM escape exploit was disclosed.

I'm not worried about the agent at all. The VM is there to prevent it from clobbering files on my real system.

I'm worried about supply chain attacks on npm, pip, cargo and everything else. Don't want to get compromised if I install some stupid package.

My virtdev project has essentially split my computer into two systems: my "real" trusted system with software coming directly from my Linux distribition's repositories, and the VMs for everything else.

> just 6 days ago a Linux VM escape exploit was disclosed

Well, shit. Details?

> npm, pip, cargo and everything else

All that stuff should also go into the agent user's home directory.

CVE-2026-53359 - https://github.com/V4bel/Januscape/blob/main/assets/write-up...

CVE-2026-43499 - https://nebusec.ai/research/ionstack-part-2/

Patched in Linux 7.1.3, which happens to be the exact kernel version I'm running. Update your kernels, folks.