Building Secure AI Sandboxes on Kubernetes

AI agents now execute code they wrote themselves—via pip install calls and shell commands—meaning unreviewed, untrusted code runs in production. Real incidents back this up: a Replit agent deleted a production database, and the Nx supply-chain attack (s1ngularity) exfiltrated thousands of secrets from over a thousand repositories. Anthropic and OpenAI have already conceded the threat by shipping OS-level sandboxing and default network restrictions in their own tools.

Kubernetes pods are built around trusted code by default: namespaces give processes a restricted view, not a hard wall, and every pod still shares the same host kernel. Runc vulnerabilities—CVE-2019-5736, CVE-2024-21626, and three separate escapes disclosed on the same day in November 2025—prove this isn't theoretical. Running agents multi-tenant, or fanning one task into many subagents, pushes this weak isolation past its limits.

Kubernetes' RuntimeClass mechanism lets the same pod spec target a different execution boundary. gVisor emulates a kernel in user space with low overhead but can slow syscall-heavy workloads; Kata Containers gives every pod a full VM and guest kernel at the cost of roughly 600ms startup latency and 180MiB overhead; Firecracker, the microVM technology behind AWS Lambda, delivers hardware-level isolation at near-container cost, booting in under 125ms with under 5MiB of overhead per instance.

But Firecracker's minimalism strips out things Kubernetes normally assumes, like virtio-fs shared filesystems, device hotplug, and VFIO passthrough, requiring extra infrastructure engineering to compensate. For engineers, the decision reduces to three questions: who wrote the code, what does it actually touch or execute, and do many agents need to fork rapidly from one warm state.