When an app automatically executes code generated by an AI agent, that code may run before anyone reviews it. On a typical Kubernetes cluster, it runs in a container that shares the server's operating system kernel with every other workload. Kata Containers is an open-source container runtime that gives each workload its own lightweight virtual machine (VM) with a separate kernel. It runs standard container images, so existing builds don't change.
Copy link to headingWhat is Kata Containers?
Kata Containers is a container runtime built on hardware virtualization. Each pod configured to use Kata has its own guest kernel, with a VM boundary around the namespaces and control groups (cgroups) used inside the guest. Kata runs Open Container Initiative (OCI) images and integrates with Kubernetes through Container Runtime Interface (CRI) implementations such as containerd and CRI-O. Pods keep using Kubernetes APIs and container registries, but runtime behavior can differ.
The project uses the Apache License 2.0 and is supported by the Open Infrastructure Foundation, which confirmed Kata as its first new top-level project in 2019. Kata Containers 4.0, released in July 2026, made runtime-rs, a runtime written in Rust, the default and deprecated the original Go runtime.
Copy link to headingKata Containers vs. Docker, gVisor, and Firecracker
The biggest difference is where the kernel boundary sits. Docker's default runtime, runc, starts containers as host processes, using Linux isolation and resource-control mechanisms. Kata runs those OCI images inside a VM with a guest kernel between the container and the host. gVisor handles application system calls in a user-space kernel called the Sentry. Firecracker is a minimal virtual machine monitor (VMM) that runs microVMs, stripped-down VMs built for fast startup, using the Kernel-based Virtual Machine (KVM).
Here's how the options compare on isolation, limitations, overhead, hardware needs, and integration:
Kata's packaged kata-fc RuntimeClass uses the deprecated Go runtime. Firecracker also exposes an API and integrates with containerd through firecracker-containerd. The microVMs vs containers guide compares isolation boundaries and operating costs.
Copy link to headingWhy container isolation can fail
Containers using runc on a node depend on the host kernel and container runtime for isolation. Common Vulnerabilities and Exposures (CVE) records document vulnerabilities in both layers:
A runtime bug can overwrite host software: CVE-2019-5736 allowed a malicious container to overwrite runc, the host program that starts containers, and gain root access to an affected host.
A runtime leak can open the host filesystem: CVE-2024-21626, one of the vulnerabilities reported as Leaky Vessels, allowed container processes to retain access outside their intended filesystem boundary and potentially read or modify host files.
A kernel bug can bypass the container entirely: CVE-2022-0847, nicknamed Dirty Pipe, let an unprivileged process overwrite data in read-only files. On vulnerable host kernels, a container process could exploit it to modify files it could access, potentially including files shared with the host.
Hardening doesn’t provide a separate kernel: Linux security mechanisms such as seccomp and AppArmor restrict container behavior and reduce attack exposure. They do not give containers their own kernel, and exploitable shared-kernel vulnerabilities can still threaten host isolation.
A guest kernel adds a virtualization boundary between container processes and the host. Vercel Sandbox uses a microVM as that boundary. For Kata, host isolation depends on the hypervisor, host kernel, and host-side helpers. The guest agent manages containers inside the VM boundary.
Copy link to headingHow Kata Containers works
Each Kata pod depends on components on both sides of the VM boundary. A shim on the host manages the pod's VM, a hypervisor runs the VM, and an agent inside the guest runs the containers. The runtime and hypervisor determine which features are available. Operators maintain both host and guest components.
Copy link to headingThe host-side shim
The shim is a host process that containerd or CRI-O starts for each pod. Kata's shim, containerd-shim-kata-v2, launches the hypervisor, starts the VM, and passes instructions to the guest agent over a virtual socket (VSOCK). Since Kata Containers 4.0, the default runtime implementation has been runtime-rs, written in Rust.
Kubernetes selects a runtime configuration per pod through RuntimeClass, stable since v1.20. This lets Kata and runc run side by side on one cluster. Each Kata pod has a host-side shim process that operators need to monitor and keep updated.
Copy link to headingHypervisor that boots the VM
The hypervisor creates and runs the VM using a supported virtualization backend. runtime-rs supports QEMU, Cloud Hypervisor, and Dragonball. Version 4.1 added OpenVMM. Dragonball runs inside the Rust shim's process, while the current Helm chart defaults select QEMU with runtime-rs. Firecracker remains available through the deprecated Go runtime.
The choice determines which features a pod gets. QEMU supports Kata's NVIDIA graphics processing unit (GPU) passthrough and confidential-computing workloads. Confidential computing uses hardware protections for guest data and needs appropriate hardware and security configuration. Azure Kubernetes Service (AKS) Pod Sandboxing uses Cloud Hypervisor. RuntimeClasses let pods select among the runtime and hypervisor configurations installed on their nodes.
Copy link to headingGuest kernel and agent inside the VM
Each VM has its own Linux guest kernel. A single kata-agent runs inside it, receives the shim's instructions, and starts and supervises the pod's containers. Workload namespaces and cgroups live inside the guest, while host-side resource controls also account for the VM and its supporting processes.
Configurations using virtio-fs share files with the guest through a host-side virtiofsd process. That daemon handles guest-controlled requests and needs appropriate confinement and updates. Other storage configurations deliver container layers as block devices without a shared-filesystem daemon. Choose between these configurations based on the workload's file-access and security requirements.
Copy link to heading4 best practices for running Kata Containers with untrusted code
Each locally hosted Kata pod adds VM resource costs and the cost of supporting software to maintain. Measure those costs against the workload's risks and operational needs.
Copy link to headingReserve Kata for untrusted pods
Moving a whole cluster to Kata adds VM overhead across its workloads. Pods that run agent-generated code are a priority for stronger isolation. Assess reviewed frontend and backend services based on their privileges, dependencies, data sensitivity, and tenancy requirements. Kubernetes supports different runtime configurations through RuntimeClass, and Agent Sandbox, a project under the Kubernetes Special Interest Group (SIG) Apps, supports Kata for agent pods. Select the runtime for each workload's threat model rather than code provenance alone.
Copy link to headingBudget for memory overhead and host requirements
Node density can decrease because each Kata pod needs memory for its guest kernel and supporting components as well as the workload. On AKS Pod Sandboxing, a pod without a memory limit gets a 512 MiB VM. The default kata-vm-isolation RuntimeClass reserves about 88 MiB of host overhead for that configuration. Local Kata VMs require a supported virtualization backend, commonly KVM or MSHV. Running them inside another VM requires nested virtualization.
Check the selected backend's prerequisites and verify the installation with a test pod. Startup and memory figures vary by configuration and release, so measure them on your own nodes before deciding how many pods each node can host.
Copy link to headingApply security updates promptly
A VM boundary still depends on the host software serving the guest, as two of Kata's 2026 advisories show. CVE-2026-47243 let root-equivalent code inside the guest become root on the host through affected runtime-rs file-sharing configurations. CVE-2026-44210 let pod creators inject virtiofsd arguments through default-enabled annotations and, combined with another enabled setting, read or write host files. Kata 3.31.0 fixed both. Upstream uses rolling monthly releases without stable branches; downstream distributions may maintain their own backports. Track advisories and promptly apply relevant fixes to the runtime, hypervisor, host and guest kernels, and guest images. Recreate workloads when required.
Copy link to headingDistrust every value the guest sends the host
Host-side code must treat guest-provided values as untrusted input. This includes snapshot metadata, storage paths, and device requests. Derive sensitive values on the host where possible, or authenticate them with signatures the guest cannot forge. Check ownership before accessing stored objects such as snapshots. For Kata deployments, review pod annotations, shared filesystems, and any snapshot or restore integration that processes guest-controlled data.
Copy link to headingVercel Sandbox as a managed alternative
Vercel Sandbox gives every sandbox its own Firecracker microVM with a dedicated guest kernel, running on bare-metal Amazon Elastic Compute Cloud (EC2) hosts with a Linux container inside. Its threat model treats sandboxed code as fully hostile, assuming root inside the container and full kernel access inside the microVM. Vercel manages this infrastructure through an implementation independent of Kata.
Copy link to headingA dedicated kernel for every sandbox
Teams adding agent execution may not have a Kubernetes cluster. Building one to host generated scripts adds infrastructure to maintain. Each Vercel Sandbox microVM gets its own filesystem and network and runs on the infrastructure Vercel uses for its builds. Sandboxes use an Ubuntu image by default, or a custom OCI image stored in Vercel Container Registry when teams need a different environment.
Copy link to headingNetwork and credential policy enforced on the host
Agent code can print or forward any API key it receives, and kernel isolation alone cannot prevent that. The sandbox firewall runs on the host outside the microVM, where code inside the sandbox cannot modify or disable it. It enforces configured policies on outbound Transmission Control Protocol (TCP) connections and Domain Name System (DNS) queries, but the default allow-all policy permits unrestricted public-internet access.
When configured, credential brokering adds keys to outbound requests at that boundary without placing them inside the sandbox. Notion Workers use this model to run third-party and agent-generated code with access to brokered credentials. Teams must limit API permissions and control which data those requests can access or send.
Copy link to headingSecurity testing by public escape attempts
Vercel ran a two-week public challenge in August 2026 with a $1M reward pool for escapes from the Firecracker microVM or past the host-side firewall. Researchers filed 1,285 reports in two weeks, and none showed access to customer data. The public challenge uncovered a Linux kernel vulnerability that enabled host-memory disclosure in production sandboxes. Related host-crash and code-execution attacks were demonstrated in the researcher’s matching environment.
Vercel changed its isolation controls after these security assessments. The changes included keeping host and guest kernels updated, reducing exposed kernel functionality, disabling nested virtualization, and running microVM processes with restricted permissions through Firecracker's jailer. These controls reduce exposure and potential impact.
Copy link to headingDocker workflows that run inside the guest
Agent workflows built around a Dockerfile or Docker Compose configuration may need to start container engines with elevated privileges. Vercel Sandbox supports running Docker and other container engines with sudo inside the microVM. The guest kernel adds a virtualization boundary around those privileged processes, alongside the platform's host-side controls.
Copy link to headingAgent integrations and limits
Teams using Cursor Enterprise can configure Cursor Cloud Agents to use Vercel Sandbox as the execution environment, with a dedicated Firecracker microVM for each agent request. Pro and Enterprise support up to 10,000 concurrent sandboxes and continuous sessions lasting up to 24 hours. Hobby supports 10 concurrent sandboxes and 45-minute sessions. The default session timeout is 5 minutes and can be extended within the plan's runtime limit.
Copy link to headingGive agent-generated code its own kernel on Vercel
Apps that run model-generated code need compute isolation, limited permissions, network controls, and regular updates. Kata Containers can suit teams that already operate Kubernetes and want VM isolation inside their own clusters, if they can maintain the configuration and software.
Deploying Kata means configuring RuntimeClasses, budgeting VM overhead, maintaining host and guest components, and reviewing paths where guest-controlled data reaches the host. Vercel Sandbox manages the underlying platform. Teams remain responsible for their applications:
Isolation provisioned by default: Every sandbox gets its own microVM by default. Teams decide which code and data belong in each sandbox.
Managed microVM infrastructure: Vercel provisions the microVMs. Teams still choose resource allocations, stay within concurrency quotas, and monitor usage costs.
Managed platform patching: Vercel maintains the underlying hypervisor, host kernels, and platform isolation controls. Teams maintain their application code, dependencies, and custom-image contents.
Configurable host-side controls: Vercel maintains its control plane and sandbox firewall. Your application still needs authorization checks, appropriate network and credential policies, and validation of sandbox outputs.
Start a new project and route your agent's generated code through Vercel Sandbox, or browse templates for an agent starting point.
Copy link to headingFrequently asked questions about Kata Containers
Copy link to headingCan you use Kata Containers with Docker?
Yes. Docker Engine 23.0 introduced support for alternate containerd shims, including Kata. The current Kata installation instructions use Docker 26 or later and explain how to register the runtime-rs shim, then select it with docker run --runtime kata. Upstream tests Docker integration with QEMU. Host networking (--net=host) and Podman are not supported.
Copy link to headingDoes Kata Containers work with Firecracker?
Kata's packaged kata-fc RuntimeClass uses the deprecated Go runtime. That runtime continues to accept bug and security fixes, with a limited grace period for feature work already underway. Removal is planned no earlier than Kata 5.0, currently forecast for the first quarter of 2028. Teams should track the deprecation plan and evaluate a supported runtime-rs hypervisor or a separate Firecracker integration such as firecracker-containerd.
Copy link to headingDoes Kata Containers support privileged containers?
Yes, with different semantics than runc. A privileged Kata container can receive additional capabilities and access to guest devices. Configure the container engine to prevent automatic exposure of host devices, for example by setting containerd's privileged_without_host_devices option to true. kata-deploy configures that mitigation automatically.
Copy link to headingIs Kata Containers used in production?
Yes. Beyond AKS Pod Sandboxing, Confidential Containers, a Cloud Native Computing Foundation (CNCF) project, uses Kata. Confidential Containers adds guest components, supported trusted execution hardware, and attestation to protect workload data from the infrastructure operator. Those protections require supported hardware, a verified guest configuration, and policies that control when secrets are released.