As AI agents and multi-tenant platforms increasingly execute untrusted code, understanding sandbox isolation has become critical for security. The term 'isolation' gets thrown around loosely - Docker containers, microVMs, and WebAssembly modules are all called 'isolated,' but these represent fundamentally different security boundaries with distinct attack surfaces and failure modes.

At the core of Linux isolation is the kernel, which exposes roughly 340 system calls through tens of millions of lines of C code. Every isolation technique answers the same question: how to reduce untrusted code's access to this massive attack surface. Namespaces create visibility walls by wrapping global system resources so processes see isolated instances, but they're not security boundaries. Recent vulnerabilities like CVE-2024-21626 and three 2025 runc CVEs demonstrated that namespace boundaries don't prevent kernel exploitation through leaked file descriptors or mount race conditions.

Stronger isolation models push complex kernel state up into the sandbox. gVisor uses a separate user-space kernel making minimal host syscalls, while microVMs provide hardware-enforced boundaries with dedicated guest kernels. WebAssembly takes the furthest step by providing no kernel access at all, relying on explicit capability imports. Each approach represents a qualitatively different boundary - not just a stronger version of the same thing.