1. In the Age of AI Agents, "It's Safe Because It's in a Container" No Longer Holds
Until now, the safety of a Kubernetes cluster has rested on a simple premise: the code you run in a container is a trusted product — written by a human, reviewed, and passed through CI/CD. Under that premise, isolation via namespaces and cgroups was a sufficient line of defense.
But as AI agents increasingly call tools autonomously, generate code on the fly, and execute scripts fetched from external sources on the spot, that premise is starting to collapse. Code written by an agent isn't a reviewed product — it's closer to an unknown program whose behavior can't be fully predicted until it actually runs.
The CNCF blog points out that the moment you grant an AI agent execution privileges, it stops being a mere efficiency tool and becomes a new kind of non-human identity — one with permissions and a blast radius (CNCF Blog). Organizations now need a design philosophy that keeps agent-generated code from directly touching sensitive data or the infrastructure control plane.
One realistic answer to this challenge is sandbox design for running AI agents on Kubernetes — an approach that adds "one more thick wall" on top of existing container operations. If you're planning to run AI agents in production, it's worth working backward from this kind of isolation design from the moment you choose an operational platform like Kubo.
2. The Limits of Container Isolation — Namespaces and cgroups Still Share the Same Kernel
Linux containers use namespaces to isolate what a process can see — processes, networking, the filesystem — and cgroups to limit resource usage. They're lightweight and fast, but the fact remains that every container on a host shares the same host kernel. If the kernel itself has an unknown vulnerability, a single container can potentially affect the host and other containers as well. That's the fundamental limit of container isolation.
One well-known approach to addressing this limit is gVisor. gVisor isn't a VM, and it isn't a syscall filter like seccomp — Google built it as a third option: an "application kernel" (gVisor GitHub repository). A userspace kernel called Sentry intercepts every syscall, narrowing down what actually reaches the host kernel. According to the official documentation, gVisor keeps resource overhead lower and startup faster than a VM while offering a container-like experience — but it doesn't implement every syscall or filesystem feature, so there are real compatibility trade-offs (gVisor official documentation).
In other words, there are two directions for covering the limits of container isolation: mediate everything in userspace, or fall back on hardware virtualization. For workloads you can't fully trust in their behavior — like AI agents — the latter option comes into view.
3. Adding VM Isolation Without Breaking Your Kubernetes Investment — Kata Containers
Kata Containers is the option that lets you add VM isolation without tearing up your existing Kubernetes workflow. It's an open source project aiming to be the standard lightweight virtual machine implementation — keeping the container-like usability you're used to, while adding hardware virtualization as a "second layer of defense" (Kata Containers GitHub repository).
A key feature of Kata Containers is that you can keep using your existing container images and Kubernetes manifests as-is. Kubernetes provides a mechanism called RuntimeClass, which lets you switch the container runtime on a per-Pod basis (Kubernetes official documentation). RuntimeClass was originally introduced as an alpha feature in Kubernetes 1.12 back in 2018, designed to let clusters run multiple runtimes side by side and let each Pod choose its own balance between performance and security (Kubernetes official blog).
Simply specifying this RuntimeClass in a Pod spec is enough to make that Pod run inside a Kata Containers microVM. Architecturally, a containerd/CRI-O-compatible shimv2 runtime launches a hypervisor, and the container process runs inside a lightweight VM with its own dedicated guest kernel. Even if that guest kernel is compromised, the damage doesn't spread directly to the worker node or other Pods (Kata Containers architecture documentation). It's a design that adds a microVM wall to your Kubernetes AI agent sandbox without changing your images or your workflow.
4. The Wall That Remains — Startup Time and Cost Overhead
MicroVM isolation is an effective way to compensate for the limits of container isolation, but it isn't free. Because you have to boot a hypervisor and bring up a guest kernel, startup takes longer than a regular container, and the cost of keeping instances warm goes up too. If you're running AI agent sandboxes on Kubernetes and spinning up a fresh microVM for every single task, this overhead becomes an operational issue you can't ignore.
The industry recognizes this as a problem to be engineered around, not simply accepted. Google Cloud has introduced a new Kubernetes primitive for AI agents called "Agent Sandbox," built on gVisor with support for Kata Containers as well. By using a "pre-warmed pool" that keeps sandboxes warmed up in advance, they report dramatically shortening cold starts and achieving sub-second latency (Google Cloud official blog).
That said, the upstream Kubernetes Agent Sandbox API itself has, as of 2026, progressed from alpha to the next stage, v1beta1 — but the spec is still evolving (Kubernetes Agent Sandbox explainer). Rolling it out fully in production is realistically something to phase in gradually as it stabilizes further.
For an AI agent execution platform like Captain.AI to work safely as a member of your organization, it needs to be built on top of a standard Kubernetes operational foundation — like the K3s-based Kubo — that accounts for this cold-start-versus-cost trade-off from the start.
5. Conclusion — Design Your Kubernetes AI Agent Sandbox by Working Backward from Isolation
If you're putting AI agents into production as members of your organization, you can't start from "it's safe because it's in a container." You need to work backward from the premise that "this agent's code can't be trusted." Understand the limits of lightweight isolation via namespaces and cgroups, and use RuntimeClass to add microVM isolation — like Kata Containers — only where it's actually needed. The practical strength of this approach is that you can deepen your defenses incrementally, without breaking your existing container images or Kubernetes operational investment.
Running AI agents in production requires a robust foundation built around this kind of isolation design from the outset. Kubo is a managed Kubernetes platform built on K3s that gives you access to standard Kubernetes features like RuntimeClass, unmodified. For an AI agent execution platform like Captain.AI to work safely as a member of your organization, this kind of isolation design at the infrastructure layer is a prerequisite. If you're evaluating the execution environment design for your AI agent platform, get in touch to talk through what running Captain.AI on top of Kubo could look like for you.