The Shared Kernel Fallacy: Why a Kubernetes Pod Isn't Enough for Agents That Run Code

Enterprise teams are dropping autonomous AI agents into standard Docker and Kubernetes pods and treating them like microservices. That is an architectural time bomb, because every one of those pods shares a single kernel with everything else on the node. The fix is not a harder container. It is a different boundary.

To be precise about the claim: it applies to agents that execute generated code, run shell commands or fetch dependencies, and Kubernetes is not the problem. The shared kernel underneath a default pod is. Fix the boundary and Kubernetes remains a fine orchestrator. I build virtualization infrastructure and spent years selling it, so weigh my bias accordingly and check the sources.

A microservice is code your team wrote, reviewed and built into an image. Its behavior is bounded at build time. An autonomous agent is none of those things.

That last row is the one that matters. A model that reads web pages, tickets and documents can be steered by whatever is written in them. Treat an agent as a process whose instructions can be rewritten by a stranger, and the security model changes.

Nobody sets out to run an agent as root on the host. It happens one reasonable request at a time.

1. The agent needs to install a package, so you loosen the filesystem restrictions.
2. It needs to run tests that start containers, so you mount the Docker socket or run Docker-in-Docker.
3. Build tools need extra capabilities, so you add them, or set the pod to privileged to stop fighting the error messages.
4. It needs to reach internal APIs, so the network policy gets a broad allow rule.

The result is a pod that has the capabilities needed to load kernel modules or reach the host, running text the model chose a moment ago.

A privileged container is not a tenant boundary. It is a host process with a nicer name, and every other tenant on that node now shares its fate.

Kubernetes has guardrails against exactly this, and they deserve credit. The Baseline Pod Security Standard forbids privileged pods, hostPath volumes (the usual way a Docker socket gets mounted), capabilities beyond a short safe list, and sharing the host's namespaces. Since Kubernetes 1.36, user namespaces are generally available: set hostUsers: false and root inside the container maps to an unprivileged user on the host. Use both. But each step of the creep above is a request to switch one of them off, and agents are the workload that keeps making that request. Even with every guardrail on, the kernel is still shared.

Containers are namespaces and cgroups over one Linux kernel. Every system call an agent makes lands in the same kernel that serves your other workloads. That boundary has been breached repeatedly, and recently. In January 2024, Leaky Vessels (CVE-2024-21626) let a container process land in the host filesystem through a file descriptor runc leaked, reachable with runc exec or a malicious image.

In November 2025, the runc project disclosed three high-severity container-escape flaws (CVE-2025-31133, CVE-2025-52565 and CVE-2025-52881). They are race conditions in how runc handles mounts and writes to /proc during container start. The CNCF's technical overview notes they can be triggered by custom mount configurations, including ones defined in a Dockerfile, and one of them (CVE-2025-52881) can defeat Linux security module labelling, which leaves AppArmor-confined processes unconfined. Affected versions included essentially every release up to the fixes in runc 1.2.8, 1.3.3 and 1.4.0-rc.3.

Now place that next to agent behavior, with one precision. These flaws need the ability to start containers with a chosen image or mount settings, and running a build is enough. So an agent confined to an ordinary pod is exposed only if it can run builds, push images or shape pod specs. The danger appears when you give it those means: a mounted Docker socket, Docker-in-Docker or shared build nodes. Agents ask for exactly that, because building images and running Dockerfiles is part of the job. These particular bugs are patched. The lesson is the class: runtime and kernel escapes keep appearing, and a platform that lets agents start containers is betting it will patch faster than someone tries.

The tool layer adds more. One security write-up counts about 30 CVEs filed against MCP servers in under 60 days from January 2026, with command injection among the most common flaws. Treat the exact figure as indicative, since it is a secondary tally. That pattern is easy to understand: an MCP server that passes model-supplied input to a shell has turned a prompt into a command. From there, the shortest path to damage usually runs through whatever that server's credentials and network can reach. The longer path runs through the kernel: if the server shares a node with your payments service, a runtime or kernel escape turns one crafted string into a very bad day. A microVM closes the second path, not the first, which is why the credential and egress controls below matter as much as the boundary.

Security teams do have options, and they are worth being honest about.

• Plain containers with tightened profiles. Seccomp, dropped capabilities, read-only roots and user namespaces reduce risk. The kernel is still shared.
• gVisor. A userspace kernel intercepts system calls, so the application talks to a reimplementation instead of the host kernel. A real step up, with some I/O overhead (one practitioner guide puts it around 10 to 30 percent on I/O-heavy work).
• Hardware-isolated microVMs. Each workload gets its own guest kernel behind a KVM boundary enforced by the CPU.

The Kubernetes community has noticed. SIG Apps launched the Agent Sandbox project at KubeCon North America in November 2025: a Sandbox custom resource for isolated, stateful, singleton agent runtimes, backed by gVisor or Kata Containers, with warm pools to bring startup under a second. That is a strong signal that the default pod is not considered enough for agents.

The rungs differ in kind, not just degree. gVisor narrows what a hostile process can reach in the host kernel. A microVM removes the shared kernel from the picture. For many teams gVisor is the pragmatic middle rung, and it is one of the two runtimes Agent Sandbox supports. Choose a microVM when agents run untrusted code from many sources, when tenants must be separated for compliance, or when you cannot accept any shared-kernel exposure.

Not every agent needs a microVM. An agent that calls a fixed set of vetted APIs, runs no generated code and has no shell is much closer to a microservice. A hardened pod (non-root, seccomp, read-only root filesystem, dropped capabilities, default-deny network) is a reasonable home for it.

Risk climbs with each capability you add: running generated code, installing packages, starting containers, loading third-party MCP servers, or serving more than one tenant. A useful rule: the moment an agent can write and run something you did not review, it has left the microservice category, and the boundary should change with it.

Why microVMs fit how agents actually work

The case rests on four properties.

1. Privilege stops being scary. Inside a microVM the agent can be root, install anything and run Docker, because the guest kernel is its own. A "privileged" agent has privilege over a disposable machine, not over your node. This is the property that resolves the permissions trap above: you can say yes to the agent without saying yes to the host.

2. The attack surface is small and different. A container can reach the full system-call interface of the host kernel. A microVM guest reaches a minimal virtual machine monitor. Firecracker, the AWS-built VMM behind Lambda and Fargate, is written in Rust, emulates a deliberately short list of devices and ships a jailer that wraps the VMM in its own chroot, namespaces and cgroups, while Firecracker itself applies per-thread seccomp filters. An escape now needs a flaw in that narrow path, rather than any of the host kernel's several hundred system calls.

3. It is fast enough to be disposable. Firecracker documents user-space startup in about 125 milliseconds, under 5 MiB of memory overhead per microVM, and creation rates up to 150 per second per host. That figure is time to guest init, so the agent's runtime and any packages add to it. Still, startup measured in fractions of a second is what makes one microVM per task practical instead of aspirational.

4. Teardown is a boundary, not a cleanup script. Which brings us to residue.

Long-lived pods accumulate secrets. Tokens sit in environment variables, shell history, package-manager caches, temp directories and swap. A "clean" container reused for the next task can hand the next task the last task's keys.

An ephemeral microVM changes the default:

• One task, one machine. The writable disk and guest memory are discarded when the task ends. There is nothing to scrub inside the guest, though anything you mounted in or sent out remains your responsibility.
• Secrets stay outside. Follow the pattern Google Cloud describes for Agent Compute Engine, announced in October 2026 and targeted for preview: long-lived credentials never enter the sandbox, and a gateway injects access on the agent's behalf. A compromised guest cannot carry the credentials away, but during the session it can still use whatever access the gateway grants, so scope and budget that access tightly.
• Default-deny egress. The sandbox reaches only destinations you listed, so a poisoned tool cannot phone home.
• Treat snapshots as sensitive. Snapshot and restore make warm pools fast, but a snapshot captures memory. Store it with the same care as the secrets that might be in it. Restoring many microVMs from one snapshot also copies state that was meant to be unique: Firecracker's documentation warns that identifiers, random numbers and cryptographic tokens can end up used twice, and VMGenID only reseeds the guest kernel's entropy. Give each clone its own identity and keys after restore.

One caveat deserves repeating from the sandboxing literature: isolation contains execution, not purpose. An agent allowed to send data to an approved destination can still send the wrong data. The kernel boundary is the floor. Identity, policy and audit sit on top of it.

What microVMs cost

The case is strong, not free.

• Not unbreakable. Hypervisors and VMMs have had escape bugs too, including a qemu-kvm guest-to-host breakout published in 2011 (Virtunoid, CVE-2011-1751). The claim is a much smaller attack surface plus defense in depth, not zero risk.
• They need KVM. That means bare metal or nested virtualization, which not every cloud instance type offers and which can cost performance.
• Startup has layers. The 125 millisecond figure covers getting the guest to init. The agent's runtime and dependencies come after, which is why warm pools and snapshots matter.
• Some things are harder. GPU access, shared filesystems and fine-grained observability take more design than they do in a plain pod.

Kubernetes can stay

None of this requires abandoning your cluster. Kata Containers runs each pod inside its own lightweight VM, using QEMU, Cloud Hypervisor, Firecracker or Dragonball, among others, while presenting the normal Kubernetes API. Agent Sandbox selects the isolation layer through a runtime class. You can keep scheduling, networking, observability and RBAC, and change what sits beneath the pod.

The design principle is simple: orchestrate with Kubernetes, isolate with hardware.

What to do before your agents reach production

• Find the privileged pods. Search for privileged: true, mounted Docker sockets, added capabilities and hostPath volumes in any namespace that runs agents. Each one is a finding.
• Move agent workloads to a VM-backed runtime class. Kata or a microVM-based sandbox, not the default runtime.
• One agent task per sandbox, destroyed at the end. No reuse across tenants or tasks.
• Keep credentials out of the guest. Use a brokered access pattern and short-lived tokens.
• Enforce Pod Security in agent namespaces. Baseline at minimum, Restricted where you can, so every privileged exception is a visible, reviewed decision.
• Turn on user namespaces where the runtime supports them. With hostUsers: false, root in the container is not root on the host.
• Patch the runtime anyway. Check that nodes run a fixed runc version, since defense in depth still includes the shared-kernel layer for everything else you run.
• Log at the boundary. Record what each sandbox started, reached and wrote, tamper-evident, so you can reconstruct a session.

The takeaway

Containers were designed to package software your team trusts. Autonomous agents are software that decides what to run after it ships. Putting the ones that run code nobody reviewed in the same kernel as your production services is a category error, however well the pod is configured.

The infrastructure that handles agents well will look less like a bigger Docker host and more like a fleet of small, disposable virtual machines, started in a fraction of a second and gone when the task ends. Hypervisors have spent two decades learning how to hold hostile workloads apart. Agents are the reason to use that lesson again.

Frequently asked questions

What is a container? It is a way to package an application and run it in isolation from other applications on the same server. Containers are light and fast because they all borrow the same core of the operating system.

What is a kernel, and what does "shared kernel" mean? The kernel is the core of the operating system, the part that controls memory, files and hardware. Containers on one server share a single kernel, so a flaw in it can expose every container on that server.

What is a microVM? It is a very small virtual machine with its own kernel, started in a fraction of a second. Because the kernel is not shared, a problem inside it stays inside it.

What does "privileged" mean for a container? It means the container is given powers close to those of the host itself. A privileged container is no longer a safe boundary between tenants, which is why granting it to an agent is risky.

What is an MCP server? The Model Context Protocol is a standard way for an AI agent to use outside tools, such as a database or a ticketing system. An MCP server is the program that exposes one of those tools to the agent.

Isn't Kubernetes Pod Security enough? It blocks privileged pods, host mounts and extra capabilities, and it should be on in every namespace that runs agents. It does not change what sits underneath: an agent in a fully compliant pod still shares the node's kernel with everything else.

What are user namespaces? A Linux feature, generally available in Kubernetes since version 1.36, that maps root inside a container to an ordinary user on the host. It limits what an escape can do, but the kernel is still shared.

What is gVisor? A kernel written in user space that sits between a container and the host kernel and answers most system calls itself. It narrows what reaches the host kernel, at some cost in I/O performance.

Do I have to give up Kubernetes? No. Kubernetes can keep scheduling and managing your workloads while a VM-based runtime such as Kata Containers provides the isolation underneath. The change is in what sits under the pod, not in how you run the cluster.

Does every AI agent need a microVM? No. An agent that only calls a fixed set of vetted APIs and runs no generated code is much closer to an ordinary service, and a hardened container can be enough for it. The risk rises when the agent can write and run things nobody reviewed.

What is Kata Containers? An open-source runtime that runs each Kubernetes pod inside its own lightweight virtual machine, using a hypervisor such as QEMU, Cloud Hypervisor, Firecracker or Dragonball. The cluster still sees an ordinary pod.

What is Firecracker? An open-source virtual machine monitor built by AWS and used behind Lambda and Fargate. Its documentation puts startup to the guest's init at about 125 milliseconds, with under 5 MiB of memory overhead per microVM.

What is Agent Sandbox? A Kubernetes SIG Apps project launched in November 2025. It adds a Sandbox resource for isolated, stateful agent runtimes, backed by gVisor or Kata Containers, with warm pools that bring startup under a second.

How do I find risky agent pods in my cluster? Look for privileged: true, mounted Docker sockets, added capabilities and hostPath volumes in any namespace that runs agents. Enforcing the Baseline Pod Security Standard turns each of these into a rejected request or a reviewed exception.

Does a microVM stop prompt injection? No. It limits what a hijacked agent can reach on the host, but an agent allowed to call an approved tool or destination can still be steered into misusing it. Credentials kept outside the sandbox, default-deny outbound traffic and logging at the boundary handle the rest.

Do microVMs cost more to run? They need KVM, which means bare metal or nested virtualization, and each sandbox adds some memory and startup overhead. Warm pools and snapshots cut the startup time, but each restored clone needs its own identity and keys.

Cheick M Ouedraogo spent about eight years in enterprise technology sales, including VMware and Broadcom, before founding Aurakore, where he builds virtualization and private AI infrastructure. He writes about what buyers should ask and what the documentation actually says.

Sources

• runc container breakout vulnerabilities: a technical overview, CNCF, Nov 2025
• runc security advisory GHSA-cgrx-mc8f-2prm (CVE-2025-52881), runc project
• runc security advisory GHSA-xr7r-f8xq-vfvv (CVE-2024-21626), runc project, Jan 2024
• Kubernetes v1.36: User Namespaces in Kubernetes are finally GA, Kubernetes blog, Apr 2026
• Pod Security Standards, Kubernetes documentation
• Firecracker snapshot support, Firecracker project
• New runc vulnerabilities allow container escape, Sysdig, Nov 2025
• Running Agents on Kubernetes with Agent Sandbox, Kubernetes blog, Mar 2026
• Unleashing autonomous AI agents: why Kubernetes needs a new standard for agent execution, Google Open Source Blog, Nov 2025
• Kubernetes Agent Sandbox guide, Pulumi
• AI Agent Sandboxing Explained: Why Docker Is Not Enough, SoftwareSeni
• Firecracker, secure and fast microVMs, Firecracker project
• Firecracker: lightweight virtualization for serverless, LWN.net
• MCP Security: 30 CVEs in 60 Days, Noqta
• MCP Security Vulnerabilities: Complete Threat Inventory, Obsidian Security
• Agent Compute Engine deep dive, Google Cloud blog, Oct 2026
• AI Agent Sandboxing, Prediction Guard, updated Aug 2026