Docker Sandboxes and MicroVMs: A Practical Security Model for Local AI and Untrusted Code

Docker’s March 2026 security push is not subtle. The company said over a quarter of production code is now AI-authored, and that developers using agents are merging roughly 60% more pull requests. That is the upside. The downside is obvious to anyone who has watched a coding agent with broad permissions make a bad decision quickly. Docker’s answer is equally obvious: stop trusting the host machine to be the place where autonomous tooling runs.

That is why Docker Sandboxes matters more than yet another container feature announcement. Docker moved the security boundary from “hopefully the agent behaves” to microVM isolation. Each sandbox runs in its own dedicated microVM, with the project workspace mounted in, network policy available through allow and deny lists, and the ability for the agent to run Docker without touching the host daemon. That is a materially different risk model from letting an agent operate directly on your laptop.

If you still need the image-size basics, the Docker multi-stage builds guide is the right warm-up. If your team is thinking more broadly about security gates in delivery pipelines, the DevSecOps with GitLab CI/CD guide is still relevant. This post is about a more specific problem: how to run untrusted code and autonomous agents locally without pretending containers alone are enough.

Why Containers Alone Stop Being Enough

Containers are great process packaging. They are not a complete answer to untrusted autonomy.

A normal container setup shares the host kernel. If the agent needs Docker, teams often mount the host Docker socket, which gives it far more power than they intended. If the agent needs system packages, it starts changing the environment in ways that drift away from the machine the engineer thought they controlled. If the agent sees local secrets, SSH keys, cloud credentials, or shell history, none of the “please be careful” prompts matter much.

Docker’s own Sandboxes product page calls out the tradeoff directly. OS-level sandboxing interrupts workflows, ordinary containers break down when agents need Docker too, and full VMs are heavy and slow to reset. The microVM approach is Docker’s attempt to get the security boundary of a VM without the operational drag of a traditional local VM workflow.

That is the right design target. Coding agents need real system access to be useful. Machines do not need blind trust from the user.

What Docker Sandboxes Actually Gives You

Docker Sandboxes are purpose-built for agent execution, not just generic container hosting. The key details are the ones that change the threat model:

• each sandbox runs in its own microVM
• the host machine is not the execution environment
• the project workspace is mounted in, not the rest of the laptop
• network access can be constrained with allow and deny lists
• agents can build and run containers inside the sandbox without using the host Docker daemon
• the environment is disposable by default

That last point matters more than it sounds. Security controls are only half the story. Recovery speed is the other half. If an agent installs the wrong packages, mutates system configuration, or just goes off the rails, the safe answer is not “undo everything carefully.” It is “delete the sandbox and start again.”

Docker is also clearly steering this toward unattended agent workflows. The product page and March 31 guidance both push the idea that permission prompts are not a serious long-term control boundary for autonomous agents. The real boundary is isolation outside the agent.

Why The MicroVM Boundary Is The Interesting Part

The value of a microVM here is not marketing language. It is defense in depth.

Containers are still part of the story, but the dedicated microVM adds a harder boundary between the workload and the host. Docker’s own Sandboxes launch material is explicit that each sandbox gets a real environment where the agent can install packages, run services, modify files, and work unattended, while the host remains untouched.

That is exactly what you want if the workload is both powerful and fallible. An agent that can edit config files, run package managers, and open ports is useful. An agent that can do that on your host machine is a liability. The microVM lets you keep the first property and reduce the second.

This is also what makes Sandboxes more relevant to AI workflows than ordinary developer isolation tools. The whole point is to let the agent act with autonomy inside a bounding box that exists independently of the agent’s own judgment.

Sandboxes For Development, Hardened Images For Production

A local sandbox is only one side of the problem. If the output still ships inside a bloated, weakly tracked base image, you solved local isolation but left the supply chain sloppy.

That is where Docker Hardened Images fits. Docker says the hardened catalog starts with a dramatically reduced attack surface, up to 95% smaller than traditional community images, and includes SBOMs, provenance, and near-zero known CVEs. The company also says a sample migration from a standard Node base image to a hardened image reduced the package count by over 98% and dropped vulnerabilities to zero in its test case.

This is the practical stack I would recommend for teams leaning into agents:

Use Docker Sandboxes for local and CI-stage agent execution where the code or tool behavior is not fully trusted.

Use Docker Hardened Images, or an equivalent hardened base-image strategy, for what actually goes to production.

Those two controls solve different problems. Sandboxes reduce host risk during execution. Hardened images reduce package and vulnerability risk in the thing you ship.

The Operational Checks That Actually Matter

The nice part is that the verification side is not exotic. You can inspect what is inside an image, and you should:

docker sbom myapp:latest
docker scout cves myapp:latest

If the package count is absurd or the CVE list reads like a backlog nobody owns, the image is not production-ready just because the app passed tests. This is where the GitHub Actions vs GitLab CI comparison matters indirectly too. The CI platform is less important than whether the pipeline actually enforces image hygiene and provenance instead of treating it as a later security concern.

The Gotchas Docker Does Not Remove For You

The first is cost and density. MicroVM isolation is stronger than container-only isolation, but it is not free. If every agent session gets its own isolated runtime, you need to think about host resources, concurrency, and cleanup the same way you would for any other ephemeral compute layer.

The second is platform support. Docker Sandboxes is clearly aimed at Desktop users first, especially macOS and Windows. If your day-to-day engineering platform is Linux or your team needs uniform behavior everywhere right now, check the current product constraints before standardizing on it.

The third is secret scope. Some Docker guidance points out that the network proxy can inject API keys so the agent cannot directly read them. That is useful, but it does not remove the need to define exactly which outbound hosts are allowed and which credentials are available in the first place. Isolation with broad egress and loose secret policy is still loose policy.

The fourth is confusing local safety with runtime safety. A sandbox that protects the host does not automatically make the resulting application safe in production. You still need least privilege, good identity boundaries, logging, and upstream package discipline. The API Gateway, WAF, and Nginx zero-trust setup exists for a reason: runtime controls still matter after the code leaves the laptop.

When This Model Is Worth It

This model is worth it when the code is not fully trusted, the agent is allowed to act with high autonomy, or the team wants the freedom to let the agent install tools and mutate an environment without risking the engineer’s workstation.

It is also worth it when the organization has already crossed the threshold into real agent usage. Once teams start relying on unattended agent execution, the old permission-by-permission model becomes a tax on both productivity and safety. People either stop using the agent, or they start bypassing the guardrails manually.

The microVM boundary is better because it accepts that autonomous agents need room to work. It just moves that work into a safer place.

The Practical Recommendation

Use Docker Sandboxes when the local execution context is the main risk. Use Docker Hardened Images when the production image is the main risk. Use both if your team is serious about agent-driven development.

That is the practical security model here. Isolate the machine the agent runs on. Minimize the thing the agent ships. Do not expect one control to solve both problems.

Containers changed how teams ship software. MicroVM sandboxes are starting to change how teams can safely let software build software.

Sources

• Docker Sandboxes product page
• Docker Sandboxes: Run Claude Code and Other Coding Agents Unsupervised (but Safely)
• Docker Sandboxes: Run Agents in YOLO Mode, Safely
• Run OpenClaw Securely in Docker Sandboxes
• Introducing Docker Hardened Images
• Docker Hardened Images for Every Developer