Containers<\/strong> are fast and are the way modern applications are built. But for an autonomous agent that needs to build and run its own Docker containers, which coding agents routinely do, you hit Docker-in-Docker, which requires elevated privileges that undermine the isolation you set up in the first place. Agents need a real Docker environment to do development work, and containers alone don\u2019t give you that cleanly.<\/p>\n WASM \/ V8 isolates<\/strong> are fast to spin up, but the isolation model is fundamentally different. You\u2019re running isolates, not operating systems. Even providers of isolate-based sandboxes have acknowledged that hardening V8 is difficult, and that security bugs in the V8 engine surface more frequently than in mature hypervisors. Beyond the security model, there\u2019s a practical gap: your agent can\u2019t install system packages or run arbitrary shell commands. For a coding agent that needs a real development environment, WASM isn\u2019t one.<\/p>\n Not using any sandboxing<\/strong> is fast, obviously. It\u2019s also a liability. One rm -rf, one leaked .env, one rogue network call, and the blast radius is your entire machine.<\/p>\n Docker Sandboxes run each agent session inside a dedicated microVM with a private Docker daemon isolated by the VM boundary, and no path back to the host.<\/p>\n That one sentence contains three architectural decisions worth unpacking.<\/p>\n Dedicated microVM.<\/strong> Each sandbox gets its own kernel. It\u2019s hardware-boundary isolation, the same kind you get from a full VM. A compromised or runaway agent can\u2019t reach the host, other sandboxes, or anything outside its environment. If it tries to escape, it hits a wall.<\/p>\n Private, VM-isolated Docker daemon.<\/strong> This is the key differentiator for coding agents. AI is going to result in more container workloads, not fewer. Containers are how applications are developed, and agents need a Docker environment to do that development. Docker Sandboxes give each agent its own Docker daemon running inside a microVM, fully isolated by the VM boundary. Your agent gets full docker build<\/em>, docker run<\/em>, and docker compose <\/em>support with no socket mounting, no host-level privileges, none of the security compromises other approaches require. This means we treat agents as we would a human developer, giving them a true developer environment so they can actually complete tasks across the SDLC.<\/p>\n No path back to the host.<\/strong> File access, network policies, and secrets are defined before<\/em> the agent runs, not enforced by the agent itself. This is an important distinction. An LLM deciding its own security boundaries is not a security model. The bounding box has to come from infrastructure, not from a system prompt.<\/p>\n Choosing microVMs was the easy part. Running them where developers actually work was the hard part.<\/p>\n We looked hard at existing options, but none of them were designed for what we needed. Firecracker, the most well-known microVM runtime, was designed for cloud infrastructure, specifically Linux\/KVM environments like AWS Lambda. It has no native support for macOS or Windows, full stop. That\u2019s fine for server-side workloads, but coding agents don\u2019t run in the cloud. They run on developer laptops, across macOS, Windows, and Linux.\u00a0<\/p>\n We could have shimmed an existing VMM into working across platforms, creating translation layers on macOS and workarounds on Windows, but bolting cross-platform support onto a Linux-first VMM means fighting abstractions that were never designed for it. That\u2019s how you end up with fragile, layered workarounds that break the \u201cit just works\u201d promise and create the friction that makes developers skip sandboxing altogether.<\/p>\n So we built a new VMM, purpose-built for where coding agents actually run.<\/strong><\/p>\n It runs natively on all three platforms using each OS\u2019s native hypervisor: Apple\u2019s Hypervisor.framework, Windows Hypervisor Platform, and Linux KVM. A single codebase for three platforms and zero translation layers.<\/p>\n This matters because it means agents get kernel-level isolation optimized for each specific OS. Cold starts are fast because there\u2019s no abstraction tax. A developer on a MacBook gets the same isolation guarantees and startup performance as a developer on a Linux workstation or a Windows machine.<\/p>\n Building a VMM from scratch is not a small undertaking. But the alternative, asking developers to accept slower starts, degraded compatibility, or platform-specific caveats, is exactly the kind of asterisk that makes people run agents on the host instead. Our approach removes that asterisk at the hypervisor level.<\/p>\n We rebuilt the virtualization layer from scratch, optimizing for fast spin up and fast tear downs. Cold starts are fast. This matters for one reason: if the sandbox is slow, developers skip it. Every friction point between \u201cstart agent\u201d and \u201cagent is running\u201d is a reason to run on the host instead. With near-instant starts, there is no performance reason to run outside it.<\/p>\n Here\u2019s the concrete version of what this architecture gives you:<\/p>\n Full development environment.<\/strong> Agents can clone repos, install dependencies, run test suites, build Docker images, spin up multi-container services, and open pull requests, all inside the sandbox. Nothing is stubbed out or simulated. Agents are treated as developers and given what they need to complete tasks end to end.\u00a0<\/p>\n Scoped access, not all-or-nothing.<\/strong> You define the boundary: exactly which files and directories the agent can see, which network endpoints it can reach, and which secrets it receives. Credentials are injected at runtime and outside the MicroVM boundary, never baked into the environment.<\/p>\n Disposable by design.<\/strong> If an agent goes off track, delete the sandbox and start fresh in seconds. There is no state to clean up and nothing to roll back on your host.<\/p>\n Works with every major agent.<\/strong> Claude Code, Codex, OpenCode, GitHub Copilot, Gemini CLI, Kiro, Docker Agent, and next-generation autonomous systems like OpenClaw and NanoClaw. Same isolation, same speed, one sandbox model across all of them.<\/p>\n Individual developers can install and run Docker Sandboxes today, standalone, no Docker Desktop license required.\u00a0<\/p>\n For teams that want centralized filesystem and network policies that can be enforced across an organization and scale sandboxed execution, get in touch<\/a><\/strong> to learn about enterprise deployment.<\/p>\n The pitch for sandboxing has always come with an asterisk: yes, it\u2019s safer, but you\u2019ll pay for it in speed, compatibility, or workflow friction.<\/em><\/p>\n MicroVMs eliminate that asterisk. You get VM-grade isolation with cold starts fast enough that there\u2019s no reason to skip it, and full Docker support inside the sandbox. There is no tradeoff.<\/p>\n Your agents should be running autonomously. They just shouldn\u2019t be running without any guardrails.<\/p>\n Install Sandboxes with a single command.<\/p>\nWhy MicroVMs<\/h2>\n
![\"Screenshot](\"https:\/\/www.docker.com\/app\/uploads\/2026\/04\/Screenshot-2026-04-09-at-3.23.44-PM-2320x1302.png\" "\\"-")
\n <\/div>\nWhy We Built a New VMM<\/h2>\n
Fast Cold Starts<\/h2>\n
What This Means In Practice<\/h2>\n
For Teams<\/h2>\n
The Tradeoff That Isn\u2019t<\/h2>\n
Use Sandboxes in Seconds<\/h2>\n