--- title: "gVisor vs. Docker vs. Firecracker: How to Sandbox AI Coding Agents" author: "Shobit Singh" published: "2026-11-14T08:17:35.254Z" updated: "2026-11-14T08:17:35.254Z" url: "https://zyvop.com/gvisor-vs-docker-vs-firecracker-how-to-sandbox-ai-coding-agents-8c2jy" canonical: "https://zyvop.com/gvisor-vs-docker-vs-firecracker-how-to-sandbox-ai-coding-agents-8c2jy" tags: ["security","containers","AI agents","DevOps","Kubernetes"] --- # gVisor vs. Docker vs. Firecracker: How to Sandbox AI Coding Agents A practical comparison of containers, gVisor and Firecracker microVMs for running AI coding agents safely, with working examples, current security news and a decision guide. ![Cover image]() **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: ```bash 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](): ```bash 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: ```yaml 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: ```json { "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 } } ``` ```bash # 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: ```bash # 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]() - gVisor: [gVisor is being donated to CNCF]() - gVisor docs: [Docker Quick Start]() and [Application Compatibility]() - Firecracker: [project site]() and [getting started guide]() - AWS: [Security Bulletin 2026-169-AWS, CVE-2026-122192]() - Docker: [The Untrusted Autonomous Workload: How AI Coding Agents Reshape What Isolation Has to Do]() (Vladimir Mikhalev, Docker Captain) - Docker: [Docker Sandboxes]() - iTnews: [Low-privileged accounts on unpatched systems as good as root: OpenAI]() - Help Net Security: [OpenAI's upcoming AI model built 948 working Linux root exploits in a single run]()