AI coding agents are incredible and terrifying in equal measure.
When a developer asks Claude Code, OpenAI Codex, or Gemini CLI to fix a bug or add a feature, they often don’t think twice about what else the agent can access. The answer: everything. Your SSH keys, your AWS credentials, your entire home directory, even the Docker daemon running on your machine. The agent isn’t malicious but it doesn’t have to be for something to go catastrophically wrong.
That is the problem Docker Sandboxes (sbx) is built to solve. And if you’re running AI coding agents in 2026, this is the tool you need to understand.
What Is Docker Sandboxes (sbx)?
Docker Sandboxes is a microVM-based runtime for running AI coding agents safely. Rather than letting an agent process run directly on your laptop with full user privileges, sbx wraps each agent inside a lightweight virtual machine with its own Linux kernel. Only the specific workspace directory you explicitly mount is shared with the VM. Everything else, your home directory, SSH keys, cloud credentials, and Docker socket – stays on the host, invisible to the agent.
The isolation boundary here isn’t a permission dialog or a policy document. It’s the hypervisor itself. That’s a fundamentally different security posture.
The Real Risk: Your Laptop Is an Attacker’s Dream
To understand why Docker Sandboxes matters, you first have to appreciate how dangerous the default setup is.
When you run Claude Code or Codex as a regular user process on your laptop, it inherits your full user session. That means access to:
- ~/.aws/credentials – your AWS access keys
- ~/.ssh/id_rsa – your SSH private keys
- .env files scattered across projects – database passwords, API tokens, third-party service credentials
- The host Docker daemon – which can be leveraged to escape containers entirely
- Your entire home directory – years of work, personal files, and stored secrets
None of this requires a malicious agent. A confused model, a rogue MCP server, or a well-crafted prompt injection in a file the agent reads can redirect the agent’s behavior without the developer ever knowing. And without an audit trail, you won’t know it happened.
Real incidents in 2026 – leaked system prompts, remote code execution via malicious MCP file swaps, MCP tool poisoning across Anthropic, OpenAI, Zapier, and Cursor – all follow the same pattern: agents are trusted, and that trust is being exploited.
The Four Pillars of Docker Sandboxes Security
Docker Sandboxes doesn’t patch the problem with a warning dialog. It addresses it architecturally through four distinct layers of governance.
1. Structural Isolation via microVM
Each sandbox runs as a lightweight VM with its own kernel. The agent process has no visibility into host credentials, no access to the SSH key ring, and no path to the Docker daemon. There is nothing to exfiltrate because there is nothing there. The boundary is enforced by the hypervisor – not by a policy file the agent could theoretically override.
2. Credential Proxy Injection
API keys live in your OS keychain – not inside the VM. When the agent makes an outbound authenticated request, a host-side proxy intercepts the call and injects the authentication header before it goes out. The raw API key never enters the VM. The agent can authenticate to OpenAI, Anthropic, or Google without ever seeing its own credentials.
Learn more: https://docs.docker.com/ai/sandboxes/security/credentials/
3. Network Policy Enforcement
Every outbound connection from the sandbox passes through a configurable policy layer with three modes:
- Open – all traffic allowed, no restrictions
- Balanced – default-deny with common development sites permitted (recommended for most developers)
- Locked Down – all traffic blocked unless explicitly allowed, for high-security or air-gapped environments
Every allowed and blocked connection attempt is logged in real time in the interactive TUI dashboard. You get a live audit trail of exactly what the agent is communicating with – and when.
Learn more: https://docs.docker.com/ai/sandboxes/security/defaults/#network-defaults
4. Branch Mode and Parallel Execution
Agent work lands on its own isolated Git worktree and branch. You review the diff before deciding to merge or throw it away entirely. Because each agent gets its own worktree, you can run multiple agents against the same codebase simultaneously without file-locking conflicts. Review, merge, or discard on your terms.
Learn more: https://docs.docker.com/ai/sandboxes/workflows/
Getting Your First Sandbox Running
Let’s walk through what it actually looks like to launch a sandbox and put it to work. Docker Sandboxes supports macOS Apple Silicon (M1–M4), Linux x86_64 with KVM, and Windows 11 x86_64.
Step 1: Install sbx
# macOS
brew install docker/tap/sbx
# Linux
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvmStep 2: Log In and Choose a Network Policy
sbx loginThe CLI opens a browser-based device confirmation flow. After authentication, it prompts you to choose a network policy. Select Balanced for most development work – it uses default-deny with common dev sites allowed.
Step 3: Store Your API Key Securely
Rather than pasting your API key anywhere it could be captured, set it as an environment variable and pipe it to sbx secret set:
# For Anthropic + Claude Code
export ANTHROPIC_API_KEY=sk-ant-...
echo "$ANTHROPIC_API_KEY" | sbx secret set -g anthropic
# For OpenAI + Codex
export OPENAI_API_KEY=sk-proj-...
echo "$OPENAI_API_KEY" | sbx secret set -g openaiThe key is stored in your OS keychain and injected at the proxy layer. The agent running inside the VM never sees the raw key – only the authenticated request goes through.
Step 4: Create and Run Your Sandbox
git clone https://github.com/dockersamples/sbx-quickstart ~/sbx-lab
cd ~/sbx-lab
sbx create --name=sbxlab claude .
sbx run sbxlabOn first run, the agent image pulls (1–2 minutes) and the sandbox initializes. You’ll see a trust prompt – confirm you trust the workspace contents and the agent launches inside the VM.
The Isolation Proof: sbx vs. Docker Containers
Here’s something that surprises most developers the first time they use Docker Sandboxes. Run this from your host terminal while the sandbox is active:
docker ps # sbxlab does NOT appear here
sbx ls # sbxlab appears HEREThe sandbox isn’t a Docker container on your host. It’s a virtual machine. It doesn’t show up in docker ps because it has nothing to do with your host Docker daemon. That distinction matters enormously from a security perspective – it means the agent cannot interact with your host containers even if it tried.
The Workspace Mount: Shared But Scoped
One of the most elegant aspects of Docker Sandboxes is how it handles the workspace. Your ~/sbx-lab directory is mounted into the VM at the same absolute path. Changes you make on the host appear immediately inside the sandbox. Changes the agent makes appear immediately on your host. There’s no sync step, no copy delay, no version mismatch.
But nothing else from your host filesystem is accessible inside the VM. The agent can read and modify your project – and only your project. Open a file in your editor, make a change, and ask the agent to read it. It sees your change instantly. Your SSH keys remain completely out of reach.
The Interactive TUI Dashboard
Run sbx in a separate terminal with no arguments to open the interactive TUI dashboard. You’ll see your sandboxes displayed as cards with live CPU and memory usage. Press Tab to switch to the Network panel – a real-time log of every outbound connection the sandbox makes. This isn’t just monitoring. It’s your audit trail, built in by default.
Who Should Be Using Docker Sandboxes?
Individual developers who run coding agents regularly on their laptops get the most immediate benefit – no more worrying about a confused model touching your SSH keys or making unexpected network calls you can’t see.
Platform and DevOps engineers can use Docker Sandboxes to provide a standardized, governed execution environment for AI agents across an organization. Centralized network policy, centralized secret management, and audit logs by default.
Security teams get the structural guarantees and audit trail they need to sign off on agentic workloads without blocking developer velocity. The boundary is the hypervisor – not a policy document.
Enterprises operating AI agents at scale get an architecture designed to handle thousands of concurrent, governed agent sessions – making broad agentic deployment a tractable operational problem rather than an unbounded security risk.
What’s Next
Docker Sandboxes is part of a broader hands-on workshop that covers the full Docker AI developer experience – from Docker Model Runner (local LLM inference with GPU acceleration) to MCP integrations to multi-agent Agentic Compose workflows. The sandboxing module is Lab 8 in the Docker Workshop, and it includes exercises that systematically prove the isolation guarantees in ways you can verify yourself – including an “isolation proof” module where you try to break out of the VM.
If you’re running AI coding agents today without a sandbox, you’re accepting a risk you probably haven’t fully thought through. The agents are getting more capable every month. The infrastructure for running them safely has to keep pace. Docker Sandboxes is a serious, architectural step in that direction.
