Docker Sandboxes

Canonical version: Docker Sandboxes.

Docker Sandboxes runs each AI agent session inside a dedicated microVM with its own private Docker daemon, isolated by the VM boundary, with no path back to the host. It exists to solve one problem: running autonomous coding agents safely. As Docker puts it, an LLM deciding its own security boundaries is not a security model. The boundary has to come from infrastructure, not from a system prompt.

Why microVMs

Docker compares four options for running agents:

• Full VMs: strong isolation, but slow cold starts and heavy overhead
• Containers: fast, but Docker-in-Docker needs elevated privileges that undermine isolation
• WASM / V8 isolates: fast startup, but can't install system packages or run arbitrary shell commands
• No sandboxing: fast, but one rm -rf or one leaked .env and the blast radius is your whole machine

MicroVMs aim to remove the usual tradeoff: VM-grade isolation with near-instant cold starts and full Docker support inside the sandbox.

Architecture

• One microVM per session: each sandbox gets its own kernel (hardware-boundary isolation)
• Private Docker daemon inside the VM: full docker build, run, and compose with no socket mounting and no host privileges
• Custom cross-platform VMM: instead of Firecracker (Linux/KVM only), Docker built its own Virtual Machine Monitor that runs natively on Apple Hypervisor.framework, Windows Hypervisor Platform, and Linux KVM
• Boundaries defined up front: which files, network endpoints, and secrets the agent gets are set before it runs; credentials are injected at runtime outside the microVM boundary
• Disposable: if an agent goes off track, delete the sandbox and start fresh in seconds, with no host state to clean up

Usage

Works with Claude Code, Codex, OpenCode, GitHub Copilot, Gemini CLI, Kiro, Docker Agent, and autonomous systems like OpenClaw and NanoClaw. Install standalone (no Docker Desktop license needed):

brew install docker/tap/sbx     # macOS
winget install Docker.sbx       # Windows

Customization: Kits

Kits are the (experimental) packaging format for sandbox capabilities: one spec.yaml declaring tools to install, environment variables, credentials to inject, files to drop in, network allow/deny rules, and agent memory (project guidance, tool docs), distributed from local directories, Git repositories, or OCI registries.

Two flavors:

• Mixin kits extend an existing agent: pre-installed tools, authenticated service access, shared team configuration. Stack several with repeated --kit flags, or add to a running sandbox with sbx kit add
• Sandbox kits define a complete agent from scratch (image + entrypoint), the vehicle for packaging custom or team-internal agents

Supply-chain posture is sane by default: only approved sources (Docker Hub) are allowed until you extend kit.allowedSources, and kits support cosign-compatible Sigstore signatures. Credentials are injected through host-side proxies rather than baked into the sandbox, consistent with the microVM boundary philosophy above.

Kits turn sandbox setup from per-developer scripting into a versioned, signed artifact, the team-scale piece Docker Sandboxes was missing.

References

• https://docs.docker.com/ai/sandboxes/
• Kits: https://docs.docker.com/ai/sandboxes/customize/kits/
• https://www.docker.com/products/docker-sandboxes/
• https://www.docker.com/blog/why-microvms-the-architecture-behind-docker-sandboxes/
• https://andrewlock.net/running-ai-agents-safely-in-a-microvm-using-docker-sandbox/
• https://www.docker.com/blog/building-ai-teams-docker-sandboxes-agent/

Related

• Docker
• AgentBox
• AI Agents
• Agentic Engineering
• Claude Code
• Strands Agents Shell
• Flue
• Vercel Sandboxes
• microVM
• OpenSandbox
• Cloudflare Sandbox SDK
• Sandcastle (AI)
• GitHub Copilot Sandboxing
• Microsoft eXecution Container (MXC)
• WSL Container: Microsoft's built-in Linux container runtime on Windows
• Coder: governed workspaces at enterprise scale, same isolation motive

About Sébastien

Ready to get to the next level?