Building Secure AI Sandboxes on Kubernetes
Comparing gVisor, Kata, and Firecracker for running untrusted AI agent code safely on Kubernetes, and why pods alone aren't a security boundary.
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.