Letting a coding agent run loose on your dev machine is a significant, unnecessary risk. The convenience of autonomous agents that can install packages, run tests, and modify your codebase is obvious, but the security model has been a major gap. A new tool provides the isolation that's been missing, making local agent execution a viable practice instead of a liability.
Docker Sandboxes provide a proper, hypervisor-based jail for your agents. This isn't just another container; it's a lightweight, purpose-built microVM that gives each agent its own kernel, filesystem, and network stack. The result is hard isolation from your host system, which should be the default for running any tool that executes autonomously.
the agent containment problem
The core issue is that powerful agents need broad permissions to be useful. They need to interact with your shell, your filesystem, and the network. A simple container shares the host kernel, which presents a large attack surface. We've seen multiple reports of agents from major labs breaching their testing environments due to misconfigurations. When an agent can write files and execute commands, a small mistake can lead to a compromised system.
The previous answer was a constant stream of permission prompts, which negates the entire point of autonomous workflows. Full virtual machines are too heavy and slow for the quick, disposable environments that agent-based development requires. This is the gap Docker Sandboxes are built to fill: providing the security of a VM with the ergonomics of a container.
how microvm isolation works
Unlike a standard container, a microVM (mVM) does not share your host machine's kernel. When you launch an agent in a sandbox, Docker spins up an mVM with its own dedicated resources. Your project directory is mounted in, but the agent cannot see or touch anything outside of that workspace. It can install packages, build containers, and even run rm -rf without affecting your host machine.
This architecture also provides critical security for networking and credentials. Network access is deny-by-default, forcing you to choose a policy like 'Balanced' or 'Locked Down'. This prevents an agent from unexpectedly exfiltrating data. Your LLM API keys are also protected; they are injected by a host-side proxy, so the agent itself never has direct access to the raw credentials.
getting started with the sbx cli
You interact with sandboxes through the sbx command-line tool. Installation is handled by standard package managers. For macOS, you can use Homebrew.
# Install the CLI on macOS
brew install docker/tap/sbx
# Authenticate with Docker
sbx login
# Navigate to your project and run an agent
cd ~/your-project
sbx run claude
The sbx run command launches the specified agent (support includes Claude Code, Gemini CLI, Copilot CLI, and others) inside its own sandboxed mVM. The first time you run it, you'll be prompted to set a default network policy. The 'Balanced' option is a sensible starting point, as it allows access to common package managers and code hosts while blocking other traffic.
There are also more advanced options, including a --dangerously-skip-permissions flag for when you need to grant an agent full autonomy within its sandbox. Use it with care, but recognize that this is the point: the danger is now contained entirely within a disposable environment.
a necessary piece of the stack
Agentic workflows are moving from a novelty to a core part of the development process. But until now, running them locally involved a direct trade-off between utility and security. Wrapping agents in isolated microVMs by default is the correct architectural pattern.
This makes experimenting with different agents and complex, multi-step tasks safer. If an agent corrupts its environment, you can simply destroy the sandbox and start over. This isn't just a new feature; it's a foundational piece of infrastructure for any engineer building with AI today.
Top comments (1)
The safer framing is not 'never automate' but 'make autonomy scoped and inspectable.' Agents need clear working directories, allowlists, reversible actions where possible, and logs that make it obvious what happened before trust expands.