# Docker Sandboxes Give AI Agents Their Own Kernel to Wreck > Source: > Published: 2026-08-10 12:14:08+00:00 Docker launched Sandboxes this week — disposable microVM environments where AI coding agents can install packages, rewrite configs, and make network calls freely, without touching your actual laptop. It hit the top of [Hacker News with 285 points](https://news.ycombinator.com/item?id=49239751). The pitch is blunt: if your AI agent is going to run in YOLO mode anyway, give it its own kernel to destroy. ## The Problem With Running Agents on Your Laptop AI coding agents running in unsupervised mode are genuinely dangerous to your system. The `--dangerously-skip-permissions` flag that Claude Code and others use is convenient — agents don’t pause to ask permission, they just do. But “just do” means agents can write a malicious `.git/hooks/post-commit` script that runs on your machine at the next commit, install packages from sketchy registries, or make outbound network calls to anywhere. [Docker’s own documentation](https://www.docker.com/blog/untrusted-autonomous-workload-ai-sandboxes/) flags the data exfiltration angle directly: “Allowing broad domains like github.com permits access to any content on that domain, and agents could use these as channels for data exfiltration.” A sandboxed agent on an allowlisted domain could quietly write to a public GitHub gist. Standard container isolation doesn’t stop any of this — containers share the host kernel, and a container escape in an agentic context is a bad day. ## What Docker Sandboxes Actually Are (Not Containers) The most important thing to understand: Docker Sandboxes does not use container isolation. It uses libkrun-based microVMs, backed by platform-specific hypervisors — Hypervisor.framework on macOS, Windows Hypervisor Platform on Windows, KVM on Linux. Each sandbox gets its own kernel, its own Docker daemon, its own network stack. That’s a fundamentally different security boundary than `docker run` . **Hypervisor boundary**— each sandbox runs its own OS kernel; container escapes don’t reach the host** Isolated Docker Engine**— the agent’s`docker build` runs against a private daemon inside the VM; images don’t escape**Network policy and credential proxy**— outbound traffic routes through a host proxy; your API keys stay in your OS keychain and never enter the VM** Shared workspace**— agents write to your actual project directory by design, which is also the residual risk Performance overhead is essentially zero. Docker’s own tests on a production Astro codebase show the sandbox build completing in 1:28 versus 1:44 on the host — within noise margin, and if anything slightly faster. ## Getting Started With the sbx CLI The `sbx` CLI is the new entry point, available in [Docker Desktop 4.60+](https://www.docker.com/products/docker-sandboxes/). Install and run: ``` # macOS brew trust docker/tap && brew install docker/tap/sbx sbx login sbx run claude # Claude Code in isolated microVM # Windows winget install Docker.sbx sbx login sbx run codex # Codex in isolated microVM # Linux (Ubuntu) curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh sudo apt-get install docker-sbx sudo usermod -aG kvm $USER && newgrp kvm ``` Six agents work natively out of the box: Claude Code, Gemini CLI, GitHub Copilot CLI, Codex, OpenCode, and Kiro. Docker also ships Docker Agent — a companion tool that lets you define multi-agent teams in YAML, with a product manager agent delegating to engineer, designer, and QA agents, each running in its own isolated sandbox. One friction point: Sandboxes requires login. The HN thread was not pleased. It’s an annoyance for something that should feel like plain infrastructure, but the auth layer underpins the enterprise governance product — org-wide network policies, SIEM integration, centralized MCP controls. Individual developers get the isolation free; teams pay for the control plane. ## The Catch: Shared Workspace Risk The sandbox protects your host system from the agent’s kernel-level activity. It does not protect your project files — because agents need to write code you actually keep. That shared workspace is intentional, and it’s also where the residual risk lives. A rogue agent can still write a malicious git hook. Git hooks don’t show up in diffs. They execute on your host with your permissions the moment you run `git commit` . Two checks to run after every agent session: ``` git diff .git/hooks/ # any new or modified hooks? cat package.json | jq '.scripts' # any scripts you didn't write? ``` Linux users have an additional gap: the Linux version uses legacy container-based isolation, not microVMs. That’s a weaker boundary than what macOS and Windows users get. The [Docker documentation](https://docs.docker.com/ai/sandboxes/) doesn’t highlight this prominently. ## Why This Matters Beyond Docker Docker Sandboxes isn’t novel in isolation — Firecracker, E2B, gVisor, and Kata Containers have all landed on the same architecture. What’s new is that microVM-based agent isolation is now a first-class tool in the Docker ecosystem, which means it’s how most developers are going to encounter this pattern for the first time. The industry is in its third major isolation transition: bare metal to VMs for multi-tenancy, VMs to containers for developer ergonomics, now containers back to VMs for autonomous AI workloads. Not because containers failed — because the new tenant, an agent that does whatever it decides, needs more. More looks like a hypervisor again. Docker Sandboxes is the right architecture for this moment. The login requirement is friction that should go away. The Linux isolation gap is real and worth knowing. And the shared workspace covert channel deserves more attention than Docker’s official docs give it. Run your agents in sandboxes — just don’t stop reviewing what they write to your project directory.