Docker Sandboxes: Disposable microVMs for safer AI agent coding

The moment you realize “agent autonomy” needs guardrails

A familiar scene: an AI coding agent starts installing dependencies, editing files, running tests, and spinning up services. It feels productive—until you remember that the agent is operating on your machine with real consequences.

That’s the promise of Docker Sandboxes (the sbx CLI): run an AI coding agent in a disposable, isolated sandbox designed for unattended work, without giving it unfettered access to your host system. The key move is isolating the agent inside a microVM (a lightweight virtual machine) so the host stays protected even when the agent runs with high autonomy. (docs.docker.com)

What problem is a “sandbox” solving for AI coding agents?

Before microVMs became mainstream in dev workflows, we relied on softer tools: code reviews, cautious permissions, and sometimes “don’t let the agent touch anything important.” That breaks down fast once you want long-running automation.

An AI coding agent needs to do three things that are inherently risky if they happen on the host:

• Run arbitrary code (build steps, scripts, installers)
• Access the network (package registries, model APIs, documentation)
• Write files (source changes, configs, generated artifacts)

A sandbox addresses this by creating a boundary where those actions can happen safely. In Docker Sandboxes, the boundary is a set of isolation layers built around a microVM. ()

Containers vs microVM sandboxes: the difference you actually feel

It’s tempting to think “we already have containers—why do we need something else?” The practical difference comes down to kernel isolation.

• A container typically shares the host’s operating system kernel, which is powerful but increases the blast radius if something escapes the container boundary.
• A microVM runs with its own kernel, meaning processes inside the sandbox are not visible to the host outside the defined interface.

Docker Sandboxes explicitly uses microVM isolation for each sandbox so the host doesn’t get exposed to sandbox processes or host resources. ()

That’s the mental model: containers are packaging and process isolation; microVMs are closer to “separate execution environment.”

How Docker Sandboxes isolate an agent (the “five walls” model)

One of the most reassuring parts of the Docker Sandboxes approach is that it doesn’t rely on one fragile permission. Instead, it stacks isolation layers:

1. Hypervisor isolation: each sandbox runs in its own microVM with a separate Linux kernel.
2. Network isolation: sandboxes don’t share network with each other or your host; outbound HTTP/HTTPS goes through a host proxy.
3. Docker Engine isolation: each sandbox has its own Docker daemon, so the agent can run Docker commands without reaching the host daemon.
4. Workspace isolation: you choose how your project appears inside the sandbox (direct mount vs clone mode).
5. Credential proxy isolation: API keys aren’t handed to the sandbox as raw secrets; they’re injected into outbound requests by the host-side proxy.

If you’ve ever seen “we locked down the filesystem” and then realized the agent still had the network and the host credentials, this is the opposite: the network and credentials are treated as first-class isolation surfaces. ()

The part that makes it feel disposable: lifecycle and persistence

“Disposable” can sound marketing-y, so here’s the grounded version.

A sandbox behaves like a temporary workspace that you can delete completely. When you remove it, the microVM and everything inside are deleted. ()

But while it exists, it’s not forced to start from zero every time. Installed packages, Docker images, and configuration changes persist across stops and restarts, which matters for productivity when you iterate on an agent session. Only when you remove the sandbox do you reclaim disk space and lose the in-sandbox state. ()

So the right way to think about it is:

• Stop/start = keep the environment warm
• Remove = wipe the slate clean

“YOLO mode” and --dangerously-skip-permissions: what it means in practice

Many agent products include a “permission mode” concept: the agent pauses to ask approval for risky actions like writing files or making network calls.

Docker Sandboxes is designed to support high-autonomy operation. For example, the Claude Code sandbox template runs Claude with --dangerously-skip-permissions by default. That’s the label Docker uses for “YOLO mode”—autonomy without approval prompts—because the sandbox boundary is what does the real safety work.

Here’s the important subtlety: removing permission prompts does not remove isolation. The sandbox still controls network access and what the agent can reach. ()

The “review still matters” moment

Even with a strong sandbox boundary, your workspace choice changes what can affect your host.

In the default workspace mode (often called direct mount), your project directory is shared so the agent can edit your host files directly. Docker Sandboxes warns that sandbox-modified files should be treated similarly to changes from an untrusted contributor because hidden files and build-related scripts can be modified as well. ()

This is why “YOLO inside the VM” still comes with “review what changed” outside the VM.

Workspace isolation choices: direct mount vs clone mode

Docker Sandboxes lets you decide how strong the wall is between the agent and your repository.

Direct mount (fast feedback)

The agent edits the same files you see on your host. That’s great for speed, but it means the agent’s work flows into your working tree immediately. ()

Clone mode (--clone) (stronger repository protection)

Clone mode mounts your repository read-only and the agent works on a private clone inside the sandbox. The agent cannot write back to your host repo checkout or alter .git state. ()

Clone mode protects modification, but not inspection: files within the repository that are readable through the mount can still be seen. That’s a big deal for secrets—especially .env-style values. The sandbox guidance is to keep secrets out of the working directory or use credential isolation. ()

Network control you can reason about

AI agents love the internet. Package registries, doc sites, and model APIs all show up quickly.

Docker Sandboxes routes sandbox outbound traffic through a proxy on the host that enforces network access policies. Raw TCP/UDP/ICMP traffic is blocked; HTTP/HTTPS is filtered based on allowed domains. ()

On first run, the CLI asks you to choose a default network preset. Docker describes options like Balanced (default deny with common dev sites allowed) and Locked Down (block everything unless explicitly allowed). ()

If you need precision, you can inspect and update policy rules later using sbx policy commands. ()

A hands-on walkthrough: from install to first sandbox

Docker Sandboxes is available as a standalone CLI (sbx) with OS-specific install steps.

Install and sign in

• macOS: use brew trust docker/tap and install docker/tap/sbx, then run sbx login
• Windows: install with winget, then run sbx login
• Ubuntu: install via the Docker apt flow, then sbx login

Those exact commands are listed in the official get-started guide. ()

Run your first agent sandbox

A typical workflow is:

cd ~/my-project
sbx run --name my-sandbox claude

The sandbox attaches you to the agent running inside the microVM. You can then do work knowing your host is protected except for the explicitly shared workspace boundary. (docs.docker.com)

Add or restrict capabilities

If you want extra isolation on the repo, create with clone mode:

sbx run --clone --name my-sandbox claude

To run additional workspaces read-only, mount them with :ro:

sbx run claude ~/project-a ~/shared-libs:ro

And if you’re curating what the agent can reach, use network policy rules via the sbx policy subcommands. (docs.docker.com)

Kits: changing the sandbox’s “contract” without rewriting everything

A kit is a packaged bundle of capabilities a sandbox can use: tools to install, environment variables, credentials to inject, network rules, files to drop in, and startup instructions. Kits are especially useful when you want consistent behavior across teams or repeat runs.

One example from Docker’s docs: a kit can remove Claude Code’s permission-skipping behavior so tool calls prompt for approval instead. ()

Kits also have an install-source allowlist for supply-chain safety, so you’re not accidentally depending on untrusted kit origins. ()

What makes Docker Sandboxes feel “agent-native”

A good agent sandbox isn’t just confinement—it’s a development-friendly environment.

Docker Sandboxes expects agents to:

• install packages
• modify configs
• build and run containers using the sandbox’s own Docker Engine
• run unattended while policy controls what’s reachable

That’s why the microVM boundary pairs with workspace mounts, credential proxy injection, and policy-enforced networking. The result is a setup where autonomy doesn’t require constant supervision because the safety model is built into the infrastructure. ()

So what’s the big takeaway?

You don’t get safer agent execution by sprinkling permission prompts everywhere. You get it by creating a real isolation boundary—and then letting the agent do the work inside it.

Closing thought

Once you’ve used one of these sandboxes, you start noticing the same pattern across secure systems: policy should be enforced at runtime, not trusted to good behavior. Docker Sandboxes turns that idea into a developer workflow by combining microVM isolation, controlled network egress, credential proxying, and workspace boundary choices—then wrapping it all in a workflow you can start and remove like a disposable environment.