npm install<\/code> it ran happened on my laptop. Same for every file it modified and every package it pulled. My user privileges, no boundary in sight. If the agent had decided to modify a Git hook or rewrite a CI workflow, I would not have noticed. I wasn\u2019t reviewing individual file changes at that point. I was reviewing outcomes. And reviewing outcomes while skipping changes is not a security model. It\u2019s a prayer.<\/p>\nDocker Sandboxes exists to close that gap.<\/p>\n
The container model and why it doesn\u2019t stretch here<\/h2>\n
Containers were never the wrong abstraction. They were the right abstraction for a world where you knew what was inside them. For twelve years that world held: you wrote the code, you reviewed it, you put it in a Dockerfile, and the container gave it a clean room to run in. Shared kernel was fine because the threat model was bugs in your own software, not surprises from a tenant you\u2019d just invited in.<\/p>\n
AI coding agents don\u2019t fit. They aren\u2019t bugs in your software because they aren\u2019t your software. They\u2019re a new kind of tenant, one that\u2019s autonomous and privileged in ways that would make any security engineer nervous. The agent installs packages you didn\u2019t pick and runs commands you didn\u2019t script. It makes network calls you\u2019d never have predicted, to endpoints you didn\u2019t know were in your dependency tree. The trust profile is code being written right now, by something that won\u2019t pause to ask permission. Containers were built for a different kind of code.<\/p>\n
This isn\u2019t hypothetical. On March 19, 2026, attackers force-pushed 76 of the 77 version tags in aquasecurity\/trivy-action and published a malicious Trivy v0.69.4 binary to GitHub Releases. The exposure window was about 12 hours. The compromised code scraped CI runner memory for secrets, cloud credentials, SSH keys, and Kubernetes tokens, exfiltrating them to a typosquatted domain. Every pipeline that referenced trivy-action by version tag during that window ran code nobody on the receiving end had reviewed.<\/p>\n
What gets me about Trivy: the weaponized tool was a vulnerability scanner. The thing organizations deployed to find malicious code became the malicious code. The maintainers didn\u2019t write the bad binary; a compromised CI workflow with too much access and not enough containment did. Substitute \u201ccompromised CI workflow\u201d with \u201cAI agent in permissive mode\u201d and you have the same threat model, running all day on every developer machine.<\/p>\n
Containers were the right answer to \u201cI trust this code, I want to run it cleanly.\u201d They were never going to be the right answer to \u201cI don\u2019t fully trust this code, and I want to give it real work to do anyway.\u201d That\u2019s the gap microVMs fill.<\/p>\n
What Docker built, and why each piece is there<\/h2>\n
First choice: don\u2019t patch containers. There\u2019s a long tradition in our industry of making a familiar abstraction handle a new problem by adding flags to it. Privileged mode, capability dropping, seccomp profiles, gVisor in front of runc. All of those have their place. None of them solved the specific issue that an autonomous agent needs its own Docker daemon. Docker-in-Docker either compromises the isolation (privileged mode, host socket mounting) or creates a nested complexity that becomes its own attack surface. The Docker docs are blunt about this. Containers, they say, share the host kernel and \u201ccan\u2019t safely isolate something that needs its own Docker daemon.\u201d<\/p>\n
Once you accept that, you end up at a VM. Not a heavyweight one (booting Ubuntu Server for every coding session would be absurd) but a microVM: light enough to start in seconds, with just enough kernel to run the agent\u2019s containers.<\/p>\n
Docker Sandboxes uses a custom VMM, not Firecracker. If you\u2019ve read the Firecracker spec and you\u2019re thinking \u201cboots in 125ms with under 5MB of overhead,\u201d those are Firecracker\u2019s numbers, not Docker\u2019s. Different microVM implementations have different cost profiles. Platform specifics: Hypervisor.framework on macOS, Windows Hypervisor Platform on Windows, KVM on Linux.<\/p>\n
\n ![\"image4\"](\"https:\/\/www.docker.com\/app\/uploads\/2026\/05\/image4.jpg\" "\\"-")
\n <\/div>\nCaption: The Sandbox architecture. Each microVM runs its own kernel and its own Docker Engine. Credentials never cross the VM boundary.<\/em><\/p>\nInside each microVM, the sandbox runs a complete Docker Engine. When the agent runs docker build<\/code>, that command goes to a private daemon that doesn\u2019t know your host containers exist. When it pulls an image, the image lives inside the sandbox VM. When you delete the sandbox, the entire image cache goes with it. Multiple sandboxes don\u2019t share layers. Wasteful. Worth it.<\/p>\nThe first time I looked inside a running sandbox, the agent was running as root with sudo and full Docker Engine access inside the VM. My reflex was that this had to be wrong. You don\u2019t give root to untrusted code. But the design is right: the isolation model doesn\u2019t constrain what the agent does inside the boundary. It constrains where the consequences land. Inside the VM, the agent can do whatever it wants. Outside? Nothing. Trying to lock the agent down with capability dropping inside the VM would be solving the wrong problem. The agent legitimately needs to install packages and run docker build<\/code>. What it doesn\u2019t need is for any of that to touch your laptop.<\/p>\n\n ![\"image1\"](\"https:\/\/www.docker.com\/app\/uploads\/2026\/05\/image1.jpg\" "\\"-")
\n <\/div>\nCaption: From the host, sandboxes don\u2019t show up in docker ps<\/code> because they aren\u2019t containers; sbx ls<\/code> is how you see them.<\/em><\/p>\nThe network layer is where it gets interesting, because it doubles as the credential boundary.<\/p>\n
Outbound HTTP\/HTTPS traffic routes through a proxy on the host, accessible from inside the VM at host.docker.internal:3128<\/code>. UDP and ICMP are blocked at the network layer and can\u2019t be allowed by policy. Non-HTTP TCP (like SSH) needs explicit IP+port rules. DNS resolution goes through the proxy. If a request can\u2019t go through the proxy, it doesn\u2019t leave. The proxy terminates TLS, inspects the host header, applies your policy, and re-encrypts with its own certificate authority that the sandbox trusts. Man-in-the-middle by design. Docker uses that exact framing in the documentation.<\/p>\nMITM is what makes credential injection work. Agents need API keys: for the AI provider, for registries, sometimes for cloud accounts. Naive answer is to pass those credentials in as environment variables, where they sit inside the VM and follow it everywhere. Docker instead keeps credentials on the host, in your OS keychain, and has the proxy inject them into outbound requests transparently. The agent sees requests that just work, and the VM never had the secrets to begin with. The docs don\u2019t hedge on this: credential values are never stored inside the VM. A compromised sandbox can\u2019t exfiltrate your API keys because your API keys were never in there.<\/p>\n
Docker tells you what won\u2019t work<\/h2>\n
Sandboxes documentation has a quality that\u2019s rare in security architecture docs: it tells you what the system doesn\u2019t protect against. Most of these documents are written to make a product look strong. Docker\u2019s docs surface the limits. Two of them matter.<\/p>\n
The first one is about the network policy.<\/p>\n
At first sbx login, you pick one of three default policies. Open allows everything except blocked CIDR ranges (private networks, link-local addresses, cloud metadata endpoints). Balanced denies by default but pre-allows common dev domains. Locked Down denies everything until you explicitly allow. Locked Down is the strictest option, the deny-by-default mode you\u2019d want if you were paranoid. But even with Locked Down and a curated allowlist, the proxy filters by domain, not by content.<\/p>\n
Here\u2019s the exact language from the docs: allowing broad domains like github.com<\/code> permits access to any content on that domain, \u201cand agents could use these as channels for data exfiltration.\u201d Security vendors don\u2019t usually say this about their own products. If github.com is on your allowlist (and it almost certainly is, because the agent needs to clone repos), the proxy knows the request is going to github.com. It does not know whether the agent is reading documentation, cloning a repository, or creating a public gist with the contents of your .env<\/code> file. All three look identical at the domain level. Same goes for every allowlist entry that includes user-generated content: Discord webhooks, Notion pages. \u201cThe domain is allowed\u201d doesn\u2019t mean \u201conly safe content lives there.\u201d<\/p>\n\n ![\"image5\"](\"data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20100%%20100%%22%20width%3D%22100%%22%20height%3D%22100%%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Crect%20width%3D%22100%%22%20height%3D%22100%%22%20fill%3D%22transparent%22%2F%3E%3C%2Fsvg%3E\" "\\"-")
\n <\/div>\nCaption: Under a deny policy, non-allowlisted domains are blocked. Allowlisted domains succeed, including domains that host arbitrary user-generated content.<\/em><\/p>\nDocs also acknowledge domain fronting as an inherent limitation of HTTPS proxying. Proxy sees which domain a request claims to be going to; it cannot always prevent the request from being routed elsewhere through that allowed CDN.<\/p>\n
The microVM boundary is the primary isolation. Network proxy is a useful additional control, especially for blocking accidental access to internal networks. It is not a hermetic seal, and Docker doesn\u2019t claim it is. \u201cThe agent is on a deny policy\u201d is not the same thing as \u201cthe agent cannot send data anywhere.\u201d<\/p>\n
The workspace is always shared<\/h2>\n
Network policy is the smaller honest limit. Workspace sharing is the bigger one.<\/p>\n
The microVM boundary is strong everywhere except for one path that crosses it on purpose: the workspace directory.<\/p>\n
The whole point of running an agent in a Sandbox is for the agent to do real work in your real codebase. Docker shares the workspace between the host and the sandbox at the same absolute path. When the agent edits a file inside the sandbox, the file changes on your host. When you pull a new commit on your host, the agent sees it. This is the design. It\u2019s exactly what you want from a developer tool.<\/p>\n
It\u2019s also a covert channel that the agent has legitimate write access to.<\/p>\n
Docker security documentation spells out what \u201cthe same files\u201d includes, and this is what matters: files that execute implicitly during normal development. Git hooks. CI configurations. IDE task definitions. Makefile targets. package.json<\/code> scripts. Pre-commit configs. Anything that runs when you do something that feels like just \u201cusing your tools.\u201d<\/p>\nSimplest version of the attack: an agent inside the sandbox writes a malicious post-commit<\/code> hook to .git\/hooks\/post-commit<\/code>. Git hooks don\u2019t appear in git diff<\/code>. They live in .git\/<\/code>, which most developers never open. Next time you commit on your host, the hook runs on your host with your user privileges. Sandbox boundary doesn\u2019t matter, because the boundary ended at the workspace, and the workspace was always shared.<\/p>\nWhich brought me back to my own Astro migration, uncomfortably. I\u2019d let Claude Code rewrite hundreds of files across my blog. I\u2019d reviewed the outcomes (Lighthouse scores, visual appearance, build success) but I had not audited every file it touched. Had not checked .git\/hooks\/<\/code>. I\u2019d never opened that directory in my life. Had not read every package.json<\/code> script before running npm install<\/code>. I\u2019d been doing exactly the thing the documentation warns about: treating the agent\u2019s output as reviewed code when it was unreviewed code that I was about to execute on my machine.<\/p>\nIt would be easy to read this as \u201cSandboxes are broken.\u201d That\u2019s not what I mean. The microVM does exactly what microVMs are supposed to do: it contains the consequences of arbitrary code execution behind a hardware boundary. What it cannot do is make the workspace contents safe, because the workspace contents are how the agent does its job. The agent has to be able to write files. You have to be able to read them. Shared region is necessary, and the shared region is where the threat model gets interesting.<\/p>\n
Mitigation isn\u2019t more isolation. The microVM is doing its job. Mitigation is discipline: treat the workspace contents the way you\u2019d treat a pull request from a contributor you don\u2019t know yet. Diff .git\/hooks\/<\/code> after agent sessions. Read package.json<\/code> scripts before running npm install<\/code>. Use the --branch<\/code> flag, which creates a Git worktree so the agent works in an isolated branch you can review before merging. None of this is exotic. It\u2019s just the practice of not treating autonomous-agent output as trusted code. Because it isn\u2019t.<\/p>\nI\u2019m spending this much space on it because it\u2019s the part most people get wrong. Hypervisor boundary makes you feel safe, but you aren\u2019t. Not completely. Both things have to be true at once for the product to work, and the Docker team built it that way on purpose. Good security architectures document their gaps and make sure the user knows what they\u2019re signing up for.<\/p>\n
What it actually costs<\/h2>\n
Hypervisor isolation isn\u2019t free, and you can\u2019t pretend otherwise. I tested this against my own production codebase, the same Astro blog I mentioned at the top, because synthetic benchmarks for sandboxed agent workloads don\u2019t tell you much. You want to know what it feels like to do real work.<\/p>\n
\n \n <\/div>\nCaption: The same docker build --no-cache<\/code> against the same Astro codebase. Host: 1:44.62. Sandbox microVM: 1:28.58. The isolation boundary is invisible to the workload. On this run, the sandbox actually finished faster.<\/em><\/p>\nI ran docker build --no-cache<\/code> against the same Dockerfile and the same codebase, once on the host and once inside the sandbox. Host finished in 1:44.62. Sandbox finished in 1:28.58, actually faster, within noise across runs. The Docker Engine inside the sandbox is running on its own kernel with its own block device, completely isolated from the host, and the build doesn\u2019t care. The microVM adds essentially zero overhead to the actual build.<\/p>\nOne real-world caveat from running this on Apple Silicon: a Rust dependency in my Astro pipeline ships jemalloc that assumes 4K page sizes, which fails on sandbox VMs (16K pages). The build itself completed correctly. All 354 pages rendered, dist generated, but a teardown step exited non-zero. The fix was a one-line guard in the Dockerfile that checks for valid build output before exiting. Took 30 minutes to track down. Worth knowing about before you ship sandbox-aware Dockerfiles on Apple Silicon, because the symptom looks like a build failure when the build actually succeeded.<\/p>\n
Verdict: for session-based agent work (a few hours on a project), the overhead disappears. For high-frequency sandbox creation (dozens per minute for short tasks), cold-start cost adds up. For the workload Sandboxes is designed for, which is giving an agent a real environment for a real session, the trade is sound.<\/p>\n
Matching isolation to trust<\/h2>\n
Most discussions of containers versus VMs treat it as a binary, and that\u2019s the wrong frame. The frame I\u2019ve found useful, both for my own work and in conversations with engineering leaders who ask \u201cdo we really need microVMs for this?\u201d, is a spectrum.<\/p>\n
\n \n <\/div>\nCaption: The Trust Spectrum. Match isolation strength to the trust profile of the workload.<\/em><\/p>\nOn one end you have code you wrote yourself. Your team reviewed it, your CI tested it, your production runs it. A standard container is the right answer. Kernel is shared, daemon is shared, and none of that matters because the workload is known.<\/p>\n
One step removed from that are CI\/CD pipelines running your team\u2019s code plus dependencies from registries you mostly trust. Mostly known, but the inputs are more variable. You add seccomp profiles, drop capabilities, write network policies.<\/p>\n
Further along, supervised AI agents: tools that suggest code while a developer reviews each step. Human in the loop, so hardened containers with strict policies still work.<\/p>\n
At the far end are autonomous AI agents. Nobody reviewing each command. Agents making decisions on your behalf, each one potentially different from the last. The trust profile isn\u2019t \u201cI trust this code\u201d because there\u2019s no fixed code to trust. It\u2019s \u201cI\u2019m letting something operate on my system without supervision, and I want the failure mode to be \u2018contained to a disposable VM\u2019 rather than \u2018on my laptop.’\u201d That\u2019s the workload that needs a microVM.<\/p>\n
This is not a declaration that containers are obsolete. It\u2019s the opposite. Containers are the right answer for everything on the left side of that spectrum, which is most of what runs in production today. MicroVMs extend the spectrum to the right, where containers were never going to be the right tool. The four isolation layers in Sandboxes (hypervisor, network, Docker Engine, credential proxy) are additive. They wrap containers in additional protection rather than replacing them. Inside every Sandbox is a microVM that runs containers. Containers haven\u2019t gone anywhere, they\u2019ve moved one level deeper in the trust stack.<\/p>\n
\u201cMicroVMs for AI agents, containers for everything else\u201d is too crude. \u201cMatch the isolation to the trust profile of the workload\u201d is the one that holds up.<\/p>\n
Why everyone is converging here<\/h2>\n
Docker isn\u2019t the only company that arrived at this answer, and the convergence tells you something.<\/p>\n
Firecracker powers AWS Lambda and Fly.io\u2019s microVM platform. gVisor intercepts syscalls in a user-space kernel. Kata Containers provides VM isolation behind a container-compatible interface. Modal runs serverless agent workloads on gVisor. E2B offers Firecracker-based sandboxes as a managed cloud service. Northflank ships Kata-based isolation for production AI workloads. All adopted at the same time, for the same reasons. Architecture everywhere looks the same: containers on the inside (because that\u2019s how developers think), VM on the outside (because that\u2019s where the boundary needs to be).<\/p>\n
Docker Sandboxes is the local-first version. Most alternatives are cloud services where you pay per execution and your code runs on someone else\u2019s machines. Docker put the same architecture on the developer\u2019s laptop. CLI supports eight agents natively (Claude Code, Codex, Copilot, Gemini CLI, Kiro, OpenCode, Docker Agent, and Droid), plus a Shell mode for custom tooling. A standalone sbx CLI runs without Docker Desktop, so the architecture isn\u2019t locked to a commercial product. MicroVM layer has an HTTP API that the open-source community has already started building on.<\/p>\n
That\u2019s a runtime. And Docker is positioning it to become the standard way to run autonomous coding agents, the way docker run<\/code> became the standard way to run microservices ten years ago.<\/p>\nOne more thing. Hardened Images and sandboxes address different layers of the same problem: Hardened Images for the supply chain (where binaries come from), sandboxes for runtime isolation (what those binaries can touch). Both exist because the assumption that \u201ccode from a trusted publisher is safe\u201d stopped being reliable.<\/p>\n
Looking back, looking forward<\/h2>\n
I\u2019ve watched the industry rebuild its trust model three times in twenty years.<\/p>\n
Bare metal to virtual machines, because we needed to put multiple workloads on the same hardware safely.<\/p>\n
Virtual machines to containers, because we needed faster startup, lower overhead, and a packaging model that matched how developers actually ship code.<\/p>\n
Now, containers to a different kind of virtual machine, because the workload changed and the kernel namespace stopped being enough. Not because containers were wrong, but because the new tenant needs more, and more looks like a hypervisor again.<\/p>\n
Each of these transitions felt obvious in hindsight and contested at the time. I remember the arguments about whether containers were really secure enough for multi-tenant workloads. (They mostly weren\u2019t, which is why we ended up with namespaced clusters and per-tenant VMs and gVisor and now microVMs for agents.) I expect the microVM argument to follow the same arc: contested for about a year, obvious within three.<\/p>\n
My Astro migration taught me what it feels like to work alongside an autonomous agent that has real access to your system. More productive than doing it by hand, and more unsettling than I expected, once I realized how much I\u2019d stopped tracking. Sandboxes don\u2019t make the agent trustworthy. It just makes sure that when the agent does something you didn\u2019t expect, the damage stays inside a box you can throw away. Workspace still requires your attention. Your skepticism. That combination (strong boundaries where you can enforce them, disciplined review where you can\u2019t) is the model for working with autonomous code, and it\u2019s probably going to stay that way for a while.<\/p>\n
If you\u2019ve been holding back on running AI coding agents because of permission prompts, accidental file changes, or just a feeling that something about the whole arrangement isn\u2019t quite safe: that feeling was correct. Containers were the wrong fit for the workload. Sandboxes is the right one. Try it on a project you actually care about. That\u2019s the only test that matters.<\/p>\n
![\"image5\"](\"https:\/\/www.docker.com\/app\/uploads\/2026\/05\/image5.jpg\" "\\"-")
\n <\/div>\n![\"image2\"](\"https:\/\/www.docker.com\/app\/uploads\/2026\/05\/image2.jpg\" "\\"-")
\n <\/div>\n![\"image3\"](\"https:\/\/www.docker.com\/app\/uploads\/2026\/05\/image3.jpg\" "\\"-")
\n <\/div>\n