Further reading

George Andronchik and Pavel Lokhmakov, arXiv · 2026 · paper

The closest thing to a systematic comparison of the engines that AI code sandboxes are built on, scored on attack surface, leakage, stackability, CVE history, patch cadence, and fuzzing. Read it for the axes it argues matter, which are the ones a vendor page will never volunteer, and for its finding that pin policy, which build of the engine a product ships and whether anyone bumps it, varies more between products than the architecture does. It refuses to compute a composite score and is unusually explicit about what its measurements do not establish, both of which make it more useful than a ranking would have been. Measured on defaults in May 2026: treat the per-product numbers as a dated snapshot.

Replit · 2026 · blog post

A vendor writing down its whole isolation stack, layer by layer, instead of asserting a tier. Unusually specific for a security marketing post, and it is the source behind what this site says Replit Agent runs in.

Cognition · 2025 · blog post

Cognition explains otterlink and the block-level snapshot format under it, and argues why Devin gets a VM per session rather than a container. One of the very few closed agent vendors that names its isolation primitive and shows the engineering, so it is worth reading as the exception.

E2B · 2025 · blog post

A practical comparison of the minimal microVM monitor against the general-purpose one, from a sandbox platform that had to pick. The clearest short answer to why not every VM is the same VM: the device model you emulate is the attack surface you keep.

Cyber Security News · 2025 · article

The supply-chain worm that makes this whole subject concrete: a postinstall script, credentials on a developer machine, thirty thousand repositories. The threat model for local isolation is not hypothetical, and this is what it looked like in the wild.

gVisor project · write-up

The best explanation anywhere of why a userspace kernel is a real defense and still not a hardware boundary. It reasons about attack surface as a measurable thing rather than a slogan, which is the habit worth stealing from it.

Firecracker project docs · write-up

A hypervisor writing down exactly which syscalls it allows itself, and why. This is the second wall in primary source form: proof that the VMM is treated as a thing that will eventually be compromised.

Cloud Hypervisor project docs · write-up

Landlock outside a tutorial: a production VMM restricting its own filesystem access to the handful of paths a guest could ever need. Useful for seeing what a real, non-toy ruleset looks like.

Incus documentation · write-up

A short, unusually even-handed statement of the system-container versus VM tradeoff, from a project that ships both behind one CLI and therefore has no side to sell you.

Multipass documentation, Canonical · write-up

What is actually underneath a VM tool on each host OS, KVM here, Hypervisor.framework there, and what changes when the driver changes. A good antidote to treating 'it runs a VM' as a complete answer.

OrbStack documentation · write-up

A proprietary product explaining its own layering: a Linux VM on Virtualization.framework, with containers sharing that VM's kernel. Worth reading as a worked example of the nesting question you should ask of every 'container' on macOS, whose kernel is it sharing?