Docker Bets Its Container Legacy on microVMs for AI Agents

Here's a fun little irony: the company that made containers the default unit of software isolation just told everyone containers aren't isolated enough.

Docker Sandboxes, announced this week, ditches the shared-kernel container model in favor of microVMs for running AI coding agents. Each sandbox gets its own Docker daemon, its own filesystem, its own network stack. No access to the host Docker daemon. This isn't a minor config tweak — it's Docker quietly conceding that the thing it built its empire on has a security ceiling.

The pitch is simple. Let an AI agent like Claude Code, Codex, or Copilot run unsupervised — installing packages, spinning up nested containers, editing files, calling tools — without worrying it'll nuke your host machine or leak your API keys to some sketchy npm postinstall script.

That's the real story here, buried under the AI-agent marketing gloss. Containers were never a security boundary. Everyone in infra knew this. It just didn't matter much when the thing running inside the container was code you wrote and reviewed. Now the thing running inside is an autonomous agent that might decide to rm -rf something important or exfiltrate your .env file because a prompt injection told it to. Suddenly the shared-kernel assumption looks a lot scarier.

What's actually in the box:

• Filesystem passthrough by default — your workspace mounts directly into the sandbox, changes sync instantly, no weird copy-and-merge dance
• Persistence until you delete it — packages, images, agent history all stick around
• Outbound traffic forced through a host-side HTTP/HTTPS proxy, deny-by-default for anything that isn't HTTP
• Credentials never touch the VM — the proxy injects them into outbound requests instead
• Native support for six agents at launch: Claude Code, Gemini, Codex, Copilot, Agent, and Kiro

That credential-injection detail is the smartest part of the design, honestly. Most "safe agent sandbox" setups I've seen just cram secrets into environment variables and hope. Docker routing auth through a proxy that the agent never sees the keys for is a genuinely better pattern.

The Elephant in the Room

Here's what the press release won't lead with: this thing is marketed as "disposable," but the default mode isn't really disposable at all.

Because your workspace mounts directly via filesystem passthrough, agent edits happen to your actual working tree in real time. If the agent decides to helpfully "clean up" your codebase, that's not contained in some throwaway VM you can nuke and forget — that's your repo, right now, with uncommitted changes potentially gone. Docker does offer a --clone option for real isolation, but it's not the headline behavior. It's the opt-in.

So the marketing says disposable, isolated sandbox. The default config says your live files, with an agent poking at them, wrapped in a nicer security perimeter than a plain container. Those are different promises, and the gap between them is exactly where someone's going to get burned in a Hacker News post six months from now.

The other honest caveat: Docker itself is calling this experimental. That's not throwing shade — that's just accurate. MicroVM isolation solves the host-compromise problem elegantly. It does nothing about a compromised agent trashing everything inside the sandbox, including your live-mounted code, if you're running the default config.

Is it a big deal? Yes, genuinely. Docker positioning itself as the execution layer for agentic AI — not just app containers — is a smart, defensible market move, and free pricing for the core feature is the right call to drive adoption. Just don't let the word "sandbox" lull you into thinking your repo is untouchable. Read the docs on --clone first.