gVisor vs. Docker vs. Firecracker: How to Sandbox AI Coding Agents

Google announced on November 5 that it is donating gVisor and its new Agent Substrate runtime to the CNCF, one day after OpenAI published research on AI-found Linux kernel privilege-escalation bugs and recommended layered defenses including sandboxing with Firecracker and gVisor. The moves come as coding agents run unread code and install packages without human approval, exposing the shared-kernel boundary of plain Docker containers, which gVisor replaces with a userspace kernel (Sentry, written in Go, shipped as the runsc OCI runtime) and Firecracker replaces with a per-workload microVM requiring KVM. Docker Captain Vladimir Mikhalev wrote on Docker's blog that an agent "is not a bug in your software because it is not your software.

TL;DR - A plain Docker container shares the host's kernel. That is fine for code you wrote, and a weak boundary for code an AI agent wrote a minute ago. - gVisor puts a userspace kernel between the workload and the host. It behaves like a container and suits dense, short-lived workloads on Kubernetes. - Firecracker gives each workload its own kernel in a microVM, which is a stronger boundary but needs KVM. Docker Sandboxes is the same idea packaged for laptops, so "Docker" now means two different things. - Whatever you pick, keep it patched, restrict network access and scope credentials. Coding agents write code, run it, install packages and read files that may contain hostile instructions, often without a human approving each step. The question is not whether an agent will eventually run something you did not intend. It is how much damage that can do. The topic is timely. On November 4, OpenAI published research on AI-found Linux kernel privilege-escalation bugs and recommended layered defenses, including sandboxing with Firecracker and gVisor. The next day, Google announced it is donating gVisor and its new Agent Substrate runtime to the CNCF. The core problem: a shared kernel A container is a normal Linux process wrapped in namespaces and cgroups, and every container on a host makes system calls to the same kernel. A kernel bug reachable from inside a container can break the boundary, because there is only one kernel to attack. That was an acceptable trade when the threat was bugs in your own reviewed software. Agents change the model. As Docker Captain Vladimir Mikhalev put it on Docker's blog, an agent is not a bug in your software because it is not your software. It runs code nobody has read, and it can be steered by anything it reads: a README, an issue comment, a package description. There are three broad responses: 1. Harden the container and accept the shared kernel. 2. Intercept the syscalls so the workload never talks to the real kernel directly gVisor . 3. Stop sharing the kernel by giving each workload its own, inside a lightweight VM Firecracker and other microVMs . Option 1: Plain Docker, hardened Hardening raises the bar for code you mostly trust: docker run --rm -it \ --user 1000:1000 \ --cap-drop=ALL \ --security-opt=no-new-privileges \ --read-only \ --tmpfs /tmp \ --pids-limit 256 \ --memory 2g --cpus 2 \ -v "$PWD":/workspace \ my-agent-image This drops capabilities, blocks privilege escalation, makes the root filesystem read-only and caps processes and memory. It helps, but two limits remain: - The kernel is still shared. Seccomp narrows which syscalls are allowed without removing the kernel from the attack surface. - Agents want Docker themselves. To build images they need privileged mode or the host's Docker socket, which hands over the keys. Docker-in-Docker avoids that but adds its own attack surface. Use plain containers for low-risk or closely supervised tasks. For autonomous agents, treat them as the floor. Docker Sandboxes, covered below, is a different product that uses microVMs. Option 2: gVisor, a kernel in userspace gVisor was open-sourced by Google in 2018. Its core, the Sentry, is written in Go and implements much of the Linux syscall interface in userspace. Code in the sandbox talks to the Sentry instead of the host kernel, and the Sentry makes only a small, filtered set of calls to the host. It plugs in as an OCI runtime called runsc , so you keep your images and tooling. It needs no hardware or nested virtualization. With Docker , after installing runsc using the gVisor install guide https://gvisor.dev/docs/user guide/install/ : sudo runsc install sudo systemctl restart docker docker run --rm --runtime=runsc alpine dmesg The dmesg output shows gVisor's own startup messages instead of the host's kernel log. The gVisor docs warn that an attacker can fake this, so never use it as a security check. On Kubernetes , you select it with a RuntimeClass: apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: gvisor handler: runsc --- apiVersion: v1 kind: Pod metadata: name: agent-sandbox spec: runtimeClassName: gvisor containers: - name: agent image: python:3.12-slim command: "sleep", "infinity" resources: limits: cpu: "2" memory: 2Gi Where it fits: many short-lived sandboxes on Kubernetes, since its container-like process model packs more densely than VM-based runtimes. It also suits hosts without virtualization, and GPU workloads that are awkward in a microVM Modal, for example, runs serverless workloads on gVisor . What it costs: - It implements a subset of the Linux syscall ABI. The docs say compatibility problems are uncommon in practice, but test your real toolchain. io uring, for example, is disabled by default. - Overhead depends on the workload. CPU-bound work is barely affected, while syscall- and I/O-heavy work pays more. The gVisor team admits out-of-the-box performance can disappoint on some I/O-heavy workloads, so benchmark your own. The news: - The CNCF accepted gVisor on September 28, and Google announced the donation of gVisor and Agent Substrate on November 5. Both start at Sandbox status, the entry-level maturity stage. - The gVisor team plans to move toward Incubation and adopt org-based voting so Google no longer holds unilateral control. Listed adopters include Google, Ant Group, OpenAI, Anthropic, Modal and Tines. - Agent Substrate now at 1.0 keeps agent state separate from a shared pool of pre-warmed workers, pairs them with gVisor, and aims to resume an idle agent in under 500 ms. That figure is Google's own claim. Option 3: Firecracker, a VM that behaves like a container Firecracker is a Rust virtual machine monitor from AWS. It uses KVM to run each workload in a microVM with its own guest kernel and emulates only five devices to keep the attack surface small. It powers AWS Lambda and Fly.io, and E2B offers it as a managed sandbox service. The project's specs target 125 ms or less from the start call to the guest's init process, and 5 MiB or less of VMM overhead for a 1 vCPU, 128 MiB microVM excluding guest memory . Both are measured on a minimal kernel and root filesystem, so a real agent image will take longer to be ready. Each Firecracker process runs exactly one microVM. A companion "jailer" confines that process with a chroot, namespaces, cgroups, dropped privileges and a seccomp filter. A minimal example needs a kernel image, a root filesystem and a JSON config: { "boot-source": { "kernel image path": "vmlinux.bin", "boot args": "console=ttyS0 reboot=k panic=1 pci=off" }, "drives": { "drive id": "rootfs", "path on host": "rootfs.ext4", "is root device": true, "is read only": false } , "machine-config": { "vcpu count": 2, "mem size mib": 1024 } } Needs read/write access to /dev/kvm firecracker --api-sock /tmp/firecracker.sock --config-file vmconfig.json A usable agent sandbox also needs a tap device for networking, a way to move code and results in and out, snapshotting, a lifecycle manager and the jailer. That work is why most teams use a platform built on Firecracker instead of driving it directly. Where it fits: multi-tenant platforms running untrusted code, and high-volume, short-lived sandboxes that need VM-grade isolation. What it costs: - Linux on x86 64 or aarch64 with KVM. Firecracker's own docs use AWS .metal instances because EC2 only supports KVM there, and other clouds need bare metal or nested virtualization. - More overhead and lifecycle complexity than containers. - Its minimal device model makes GPUs and other specialized workloads awkward. Docker Sandboxes: microVMs for laptops Firecracker targets Linux servers, but coding agents mostly run on laptops. Docker Sandboxes gives each agent a microVM built on a custom VMM that uses each platform's native hypervisor Hypervisor.framework on macOS, Windows Hypervisor Platform on Windows, KVM on Linux . Inside runs a private Docker Engine, so the agent can build images and run Compose without touching your host's Docker. Docker says the local CLI is free: macOS brew trust docker/tap && brew install docker/tap/sbx Windows winget install Docker.sbx Linux curl -fsSL https://get.docker.com | sudo SBX=1 sh From your project directory sbx run claude Three design choices matter: - Credentials stay outside the VM. API keys live on the host and a network proxy injects them into outbound requests, so a compromised sandbox has nothing to steal. - Network access goes through a proxy. At first login you pick Open, Balanced or Locked Down. The proxy filters by domain, not content, so an allowed domain like github.com can still be used to exfiltrate data. - The workspace is shared on purpose. The agent edits your real files, which is the point and also the biggest remaining risk. A malicious Git hook or package.json script written in the sandbox can run on your host at your next commit or install. Review .git/hooks/ and package scripts after sessions, and consider a separate branch or worktree Docker's CLI has a --branch option, so check current docs . Docker's write-up found negligible build overhead for session-length work, but says cold starts add up if you create dozens of sandboxes a minute. Side by side | | Hardened Docker | gVisor | Firecracker | Docker Sandboxes | |---|---|---|---|---| | Boundary | Namespaces, cgroups, seccomp | Userspace kernel | Hardware virtualization, own kernel | Hardware virtualization, own kernel | | Runs as | Container | Container runsc | microVM | microVM | | Startup | Fastest | Container-like | 125 ms or less to guest init spec, minimal image | Seconds | | Platform | Anywhere Docker runs | Linux, no virtualization needed | Linux with KVM | macOS, Windows, Linux | | Main cost | Weakest boundary | Syscall coverage, I/O overhead | Ops complexity, KVM | Laptop-first, slow for high-frequency creation | Which should you choose? | If you are... | Start with | |---|---| | Running an agent locally on your own machine | Docker Sandboxes | | Running many short-lived sandboxes on Kubernetes | gVisor RuntimeClass, or Agent Substrate | | Building a multi-tenant platform for strangers' code | Firecracker, directly or through a platform built on it | | Running a trusted internal agent on well-understood tasks | Hardened Docker, revisited as autonomy grows | | Needing GPUs inside the sandbox | gVisor, since microVMs make this harder | If you are unsure, run your real workload under each and measure startup time, I/O behavior and what breaks. The answer depends on your toolchain more than on any table. Sandboxes have bugs too OpenAI's report recommends defense in depth, and also says its own testing found many vulnerabilities in Kata, Moby/Docker, gVisor and other projects, which it reported and helped patch. Parts of that research cannot yet be independently verified. Firecracker is no exception. On November 4, AWS disclosed CVE-2026-122192: under certain host memory conditions, a root user in a guest could read or modify the Firecracker process's memory. It affects VMs restored from a snapshot using the File memory backend with a balloon or virtio-mem device, in versions 0.23.0 through 1.16.1. It is fixed in 1.16.2 and 1.17.0, and AWS says Lambda and its other services are not affected. Snapshot restore is common in agent sandbox platforms, so check which version yours runs. Three habits follow: patch the runtime and host kernel promptly, subscribe to your runtime's security advisories, and layer controls instead of relying on one boundary. What a sandbox does not fix A sandbox limits what an agent can reach on the host, not what it can do with what it is allowed to reach: - Network egress. Default-deny with an allowlist beats open access, though domain allowlists are not airtight. - Credentials. Never paste a broad API key or personal access token into a sandbox. Prefer short-lived, narrowly scoped credentials injected from outside. - The workspace. Whatever you mount in is fair game, so review changes through a pull request. - Prompt injection. Sandboxes limit the damage but do not stop the model from being manipulated. The next post in this series covers the credentials part in detail. Conclusion Start from the threat model. If the code is yours and reviewed, a hardened container is enough. If an autonomous agent is writing code you will never read, move the boundary: gVisor for container ergonomics and density on Kubernetes, a microVM for a hardware boundary, and Docker Sandboxes for a microVM on your laptop. Whichever you choose, assume the agent will eventually do something unintended, and make sure the answer to "what can it reach?" is small. Sources and further reading - Google Open Source Blog: Sandboxing Untrusted AI Agents at Scale: Google Donates Agent Substrate and gVisor to the CNCF https://opensource.googleblog.com/2026/11/sandboxing-untrusted-ai-agents-at-scale.html - gVisor: gVisor is being donated to CNCF https://gvisor.dev/blog/2026/10/02/gvisor-cncf/ - gVisor docs: Docker Quick Start https://gvisor.dev/docs/user guide/docker and Application Compatibility https://gvisor.dev/docs/user guide/compatibility/ - Firecracker: project site https://firecracker-microvm.github.io/ and getting started guide https://github.com/firecracker-microvm/firecracker/blob/main/docs/getting-started.md - AWS: Security Bulletin 2026-169-AWS, CVE-2026-122192 https://aws.amazon.com/security/security-bulletins/2026-169-aws/ - Docker: The Untrusted Autonomous Workload: How AI Coding Agents Reshape What Isolation Has to Do https://www.docker.com/blog/untrusted-autonomous-workload-ai-sandboxes Vladimir Mikhalev, Docker Captain - Docker: Docker Sandboxes https://www.docker.com/products/docker-sandboxes/ - iTnews: Low-privileged accounts on unpatched systems as good as root: OpenAI https://www.itnews.com.au/news/low-privileged-accounts-on-unpatched-systems-as-good-as-root-openai-630145 - Help Net Security: OpenAI's upcoming AI model built 948 working Linux root exploits in a single run https://www.helpnetsecurity.com/2026/11/05/openai-linux-kernel-root-exploits/