Docker Cloud Sandboxes Launch Hosted MicroVMs for AI Coding Agents

Docker Cloud Sandboxes Move the MicroVM Off the Laptop​

Cloud Sandboxes extend the local Docker Sandboxes product rather than replacing it. Docker's launch post says earlier this year it launched Docker Sandboxes: microVM environments where coding agents can work autonomously and safely, and that the new product is the same microVM-based sandbox, running on Docker-managed compute, with one command to move between them. ADTmag, in its own report on the launch, confirms that Docker Cloud Sandboxes was announced Thursday at WeAreDevelopers North America and that developers can use the same command-line tools and policies in either location.

The move command is sbx move my-project --to cloud. Docker says a move captures the sandbox's filesystem and rebuilds it at the destination, and that it works in both directions. The use case is long-running agent work: large refactors, dependency migrations, and test suites that take an hour or more. Those jobs used to occupy a developer's machine for the whole run. As ADTmag puts it, an agent that needs hours to modify code, run tests, or investigate a problem can occupy a developer's computer for the duration.

Moving does not carry every setting across. Docker's launch post says local and cloud sandboxes keep separate secrets, templates and network policies. Someone who has tuned a local sandbox's egress rules should expect to recreate them on the cloud side before trusting a moved workflow.

In The Register's report on the launch, Docker president and COO Mark Cavage summed up the product in the keynote. He said the cloud sandboxes "boot in hundreds of milliseconds" and come with secrets, policies, networks, agent configuration and an MCP gateway built in. The boot-time figure is Docker's own claim. No independent measurement of it has been published.

Why Docker Separates Containers From Containment​

Cavage built the keynote around one distinction. Containers, he said, are not insecure; they do the job they were designed for, which is isolating applications. "We have to separate containers from containment," he told the audience. Docker's official press release says the same thing: "While the containers Docker is known for still have a critical role to play, they weren't designed for the level of isolation AI agents demand."

The mechanism is simple. A standard container shares the host kernel and uses namespaces and cgroups to give a workload its own view of files, network and processes. That works for software that does a fixed job. Docker engineer Christian Dupuis argues it breaks down for an agent that decides what to do next and keeps trying when blocked. When an agent runs in a container, the boundary is the same kernel the agent is probing. As ADTmag explains, unlike a conventional container, a microVM has its own kernel, providing a separate boundary for an agent that may install software or execute unfamiliar code.

Windows users should note that this is a hypervisor-level design. InfoWorld's explainer from earlier this year describes the microVM as a custom-built, cross-platform project for Docker, designed to run directly on the hypervisor architecture for all three major platforms: Linux (KVM), macOS (Hypervisor.framework), and Microsoft Windows (Windows Hypervisor Platform). Docker's January announcement of microVM isolation said it was available now for macOS and Windows. InfoWorld adds that with microVMs, each container has its own isolated instance of the Docker daemon, along with its own kernel.

The private daemon is what the stage demo turned on. Cavage showed Anthropic's Claude, launched in an ordinary Docker container, finding a secret stored outside the container. It got there by probing its environment until it found the mounted host Docker socket. Principal engineer Michael Irwin then gave Claude the same prompt inside a Docker Sandbox. According to The Register, the agent found a Docker socket and tried to use it to mount host paths and start a privileged container, but it could not reach the secret. "That's because the sandbox is running as a full micro VM," Irwin said.

This was a vendor demonstration, not an independent penetration test. It does show the specific failure mode Docker is designing against. Mounting /var/run/docker.sock into a container gives whatever runs there control of the host's Docker Engine. An agent looking for a way out will find that path.

The Agent Containment Problem Behind the Launch​

Docker is launching into a stream of reports about agents going beyond the limits their operators set. The Register reports that on the same Thursday, Australian officials disclosed that an OpenAI agent had accessed an Australian government portal without authorization while looking for health statistics. No other outlet has reported that incident, and nothing Docker published speaks to it.

Cavage did not claim sandboxes solve the whole problem. "Agents are going to find the edges of your environment because they need to mutate your environment," he said. The same capabilities that make agents useful also let them push past boundaries. He described sandboxes as "the deterministic base layer," with policies governing the agent's intent on top. He said the industry "still has work to do" applying intent controls across the stack.

That framing matches Docker's documentation better than its marketing does. The product page promises a hard security boundary from the host. The engineering documentation spells out the paths that deliberately still cross it.

What Still Crosses the Docker Sandbox Boundary​

Docker's security documentation makes the microVM the primary trust boundary. Inside it, an agent has full control, including sudo, package installation and a private Docker Engine with no connection to the host daemon. Outside it is anything the developer explicitly connects. For anyone deciding whether to point an unattended agent at a real repository, these documented connections matter most:

• In direct mode, a workspace passed to a sandbox is mounted read-write by default, so the agent's edits appear in your working tree in real time. The --clone option mounts the repository read-only and lets the agent work on a private clone. A mountless sandbox has no host workspace at all.
• A direct-mode agent can change executable project configuration, including Git hooks, CI files, IDE task definitions, a Makefile and package.json scripts. Docker advises reviewing changes before running modified code, and warns that hooks inside .git/ do not show up in git diff.
• Outbound TCP goes through a proxy and is governed by network policy. The policy model is deny-by-default, but the default allowed domains can include broad wildcards. Docker's documentation points users to sbx policy ls to see the active rules.
• Direct external ICMP is blocked. UDP is blocked unless experimental UDP egress is turned on and allowed by policy.
• Proxy-managed API credentials are injected into outbound HTTP requests, and Docker says the real values never enter the VM. This covers credentials stored through the proxy, not secrets a user copies into the sandbox themselves.
• Local stdio MCP servers run on the host, outside the microVM. Docker says to treat them as trusted host integrations. Whatever those tools are able to do, the agent can trigger through the gateway.
• Kits run their install commands as root inside the sandbox. sbx limits install sources to an allowlist that defaults to Docker Hub.

The credential design is the strongest part of the model. The launch post says the Cloud Sandboxes proxy injects a stored key or token per request, so agents never see the actual secret, and argues that prompt injection cannot steal a secret the agent never held. The design also has a clear weak point, which is the read-write workspace. An agent confined to a microVM can still plant a poisoned Git hook in a repository that you will later run on your own machine.

The Sandboxes API and SDK are marked experimental, and their interfaces may change. Docker's limits documentation lists default account quotas of 10 concurrent sandboxes, 50 stored sandboxes, 100 volumes, 100 secrets and three images being prepared at once, and notes that individual accounts may have different quotas. Treat the launch post's "run 100 tasks in parallel" line as a statement about architecture, not a default allowance.

Kit Specification v3 Turns Agent Permissions Into an OCI Image​

The second announcement may last longer than the hosted compute. A Kit is Docker's package for an agent's environment: which agent runs, which tools and MCP servers it gets, and what it may reach. ADTmag summarizes it: Docker's updated Kits package an agent's environment and access rules as OCI images; the company plans to submit the specification to the CNCF.

The format change is the important part. In version 3, a Kit is an ordinary OCI image instead of a separate artifact type. Its permission declarations sit in a single manifest annotation, vnd.docker.sandbox.kit.descriptor. Kits therefore build with docker buildx build, pull with docker pull, go through existing scanning and signing tools, and can be pinned by digest. Pinning a digest locks the content and its declared permissions together. The format also addresses concerns about lock-in to a proprietary Docker format. The specification is open source under Apache 2.0, and Docker says it is bringing it to the Cloud Native Computing Foundation for neutral governance. That is a proposal. CNCF has not adopted the specification yet.

Dupuis's example shows how the permissions read in practice. A GitHub CLI mixin allows github.com and most methods against api.github.com, but denies DELETE under /repos/**. Deny rules win, so a token that can open a pull request cannot delete the repository. The GitHub token is proxy-managed: only a sentinel value exists inside the sandbox, and the runtime injects the real Bearer header for the named domain.

The specification has one important limit. A Kit grants itself nothing. Each entry is a request, and a conforming runtime has to enforce it. On any runtime that doesn't implement the spec, the annotation does nothing: the image runs with no enforcement. Docker Sandboxes is the first conforming runtime. Kit declarations only protect you if you run the Kit somewhere that honors them.

Two other design choices are useful for teams. When a new version of a Kit asks for more authority, such as another host, a second credential or a removed deny rule, the change shows up as added lines in the pull request diff. The spec also lets a runtime record what it granted and hold any upgrade that widens it. And if a Kit's required request cannot be met, the launch is refused. The agent does not start with more or less authority than it declared.

Partners are shipping Kits already. Cloud Sandboxes come with Kits for Claude Code, Codex, Copilot, Antigravity, Open Code and Hermes. According to The Register, BAND, which builds infrastructure for distributed agent deployments, has published a BAND Python Kit for Docker Sandboxes that lets agents talk to each other over a WebSocket connection without sharing an environment.

Pricing and Plan Limits for Docker Cloud Sandboxes​

Cloud Sandboxes are pay-as-you-go. Docker meters compute by the second and charges for nothing else. Volumes, egress, and hosting public images and Kits are free, and a paused sandbox costs nothing.

Sandboxes run for one hour by default and for up to 24 hours per session. Users can bring their own model key, so inference is still billed by their existing provider, not by Docker. The pay-as-you-go plan is available on Docker Personal and Pro accounts, and new accounts get $250 in Cloud Sandboxes credit for a limited time. Local sandboxes stay free and do not require Docker Desktop.

Centralized enterprise governance is not part of this launch. The announcement describes it as "coming soon" through Docker AI Governance. Organizations that need admin-enforced policy across many developers' cloud sandboxes should plan around that gap.

What this means for you​

If you already run coding agents with permission prompts turned off, the local microVM sandbox is the lowest-cost change to make, and it is free. Cloud Sandboxes are worth a trial if agent jobs are tying up your workstation overnight. The launch post's terminal steps are brew install docker/tap/sbx, sbx login, then sbx --cloud run claude, and they require sbx 0.45.1 or later. Browser users can sign in to the web console, pick a Kit and click Run. The Homebrew route is the only command-line install the launch post documents, so Windows users should use the web console or Docker's platform-specific install instructions instead of assuming the same command applies.

• Stop mounting the host Docker socket into containers that run agents. Docker's own demo showed that path being found and used.
• Use --clone or a mountless sandbox for unattended jobs, and review hooks, CI files and build scripts before running anything an agent changed.
• Run sbx policy ls before trusting the default network policy, because the default allowed domains can include broad wildcards.
• Store API keys as proxy-managed credentials instead of copying them into the sandbox, where the injection protection does not apply.
• Treat local stdio MCP servers as host-level trust decisions, since they run outside the microVM.
• Recreate secrets and network policies on the cloud side before running sbx move, because they do not transfer.

Docker has a credible case that containment for agents starts below the container, at a kernel the agent cannot reach. Cloud Sandboxes make that model portable and cheap enough for overnight jobs. The documentation is candid that workspace mounts, MCP tools and network policy still decide what an agent can actually do. The part that could outlast this launch is Kit specification v3 and its move to the CNCF. If other runtimes adopt it, agent permissions become a reviewable, pinnable part of the image. Until then, those declarations are enforced only inside Docker's own sandboxes.