Docker's Cloud Sandboxes Isolate AI Agents by the Second

Docker spent the last few years teaching developers to stop running random shell scripts on bare metal. Now it wants to teach AI agents the same lesson, and it's charging by the second to do it.

On September 24, at the WeAreDevelopers conference, Docker launched Cloud Sandboxes, a hosted extension of its local Sandboxes product that lets coding agents like Claude Code, Codex, and Copilot run for hours in microVM-isolated cloud compute after a developer's laptop goes to sleep. It's a small feature on paper - a --cloud flag on an existing CLI - but the launch doubles as Docker's pitch for what agent infrastructure should look like once agents stop being toys and start running unattended for a full workday.

The Demo That Sells the Pitch

Docker did not lead with a slide about isolation guarantees. It led with a failure. According to The Register, Docker president Mark Cavage demonstrated Claude probing its own environment inside a standard Docker container, finding the host's mounted Docker socket, and using it to reach a secret stored outside the container completely. No exploit, no CVE - just an agent doing what agents do: poking at the edges of its environment until something gives.

Cavage then reran the same agent inside a Cloud Sandbox. Docker principal engineer Michael Irwin explained why the second run held: the sandbox runs as "a full micro VM" with its own kernel and Docker daemon, so there was no host socket to find in the first place.

"Sandboxes are the deterministic base layer, while policies govern the agent's intent." - Mark Cavage, Docker

It's a convenient demo for Docker to stage, but the underlying point holds regardless of who's holding the microphone: a container namespace isn't the same security boundary as a virtual machine, and agents that run for hours unsupervised will eventually find the difference.

Docker's pitch: one CLI, one isolation model, whether the sandbox runs on a laptop or in Docker's cloud. Source: docker.com

What's Actually Running Under the Hood

Local Docker Sandboxes already isolated agents in per-session microVMs on the developer's own machine. Cloud Sandboxes is the same isolation model relocated to Docker-managed infrastructure, with one addition: work can keep running after the laptop closes.

Moving Work From Laptop to Cloud

The whole feature is built around a single command:

$ sbx move my-project --to cloud

That captures the sandbox's filesystem state and recreates it on Docker-managed compute, same kernel model, same CLI, same network policy. Getting started with a fresh cloud agent is just as terse:

$ sbx --cloud run claude
$ sbx --cloud run --detached codex --name overnight-refactor

According to Docker's announcement post, sessions default to one hour and can run up to 24, agents can run in parallel across dozens of sandboxes, and a paused sandbox costs nothing while it sits idle.

Kits: Pre-Baked Environments as OCI Images

The second piece is "Kits" - prebuilt sandbox images that ship with an agent's tooling already installed, so sbx --cloud run codex doesn't spend its first five minutes on apt install. Six agents get official Kits at launch: Claude Code, Codex, Copilot, Antigravity, Open Code, and Hermes, with support for MCP servers and a centralized secrets proxy that injects credentials into a request without the agent ever seeing the raw key.

Authority as Code: Docker's Permissions Play

The more interesting long-term bet is not the compute, it's the permissions format underneath it. In a companion post, Docker engineer Christian Dupuis laid out the problem Kits are actually trying to solve: agent permissions today live scattered across shell history, dashboards, and whoever's memory happens to be freshest.

"Everything that makes an agent useful is a grant... Each grant is reasonable on its own. Together they take back the isolation I was relying on, and none needed an exploit. The holes are configuration, added on purpose, usually by me." - Christian Dupuis, Docker

Docker's answer, in the Sandbox Kit Specification v3, is to package a Kit as an ordinary OCI image with its permission grants written into a single manifest annotation - network rules, credential scopes, volume access - all pinnable by digest and diffable on upgrade:

capabilities:
  - type: com.docker.sandbox/network-policy@2
    config:
      runtime:
        allow:
          - github.com
          - hosts: [api.github.com]
            methods: [GET, HEAD, POST, PATCH, PUT, DELETE]
        deny:
          - hosts: [api.github.com]
            methods: [DELETE]
            paths: [/repos/**]

That YAML is a real example from Docker's docs: a GitHub-access grant that lets an agent read and write to a repo but explicitly can't delete it. "A Kit grants itself nothing," the spec insists - the host still decides what a request actually gets. Docker has published the spec under Apache 2.0 and says it'll bring it to the CNCF as a vendor-neutral standard, which is the part worth watching: if it lands, "authority as code" could become as unglamorous and load-bearing as the Dockerfile itself.

The Sandbox Kit Specification repository, published under Apache 2.0, days ahead of the Cloud Sandboxes launch. Source: github.com

Where It Falls Short

The pitch is clean. The verification is not there yet.

Every data point in this launch, including the container-escape demo, comes from Docker itself. No independent security researcher had audited Cloud Sandboxes' microVM boundary as of publication, and Docker didn't benchmark itself against Cloudflare's own Sandboxes, which reached general availability in April with a similar pitch of persistent, isolated compute for agents.

The isolation model also only covers what happens inside the VM boundary. As InfoQ's write-up of the launch noted, reaction on Hacker News and Reddit converged on a real gap: agents still need outbound access to package registries, git hosts, and APIs to do useful work, and that access is itself an attack surface no VM boundary closes. One commenter argued that object-capability models limiting exactly what an agent can reach will matter more, long-term, than where it runs. Anthropic's own Claude Cowork sandbox escape earlier this year was a reminder that isolation boundaries usually fail through configuration mistakes, not missing hypervisors - the exact problem Kits' permission diffing targets, but hasn't been battle-tested against.

The 24-hour session cap is also worth flagging for anyone picturing fully autonomous, multi-day agent runs: Cloud Sandboxes is built for long tasks, not indefinite ones.

None of that makes the underlying architecture wrong. Running an agent in a microVM with its own kernel is a materially stronger boundary than a shared-kernel container, and pricing it by the second removes the excuse to skip it. But "materially stronger" is not the same as "solved," and the real test of Cloud Sandboxes won't be Docker's own demo - it'll be the first credible red team report that tries to break out and publishes what it found.

Sources:

• Docker: Introducing Cloud Sandboxes
• Docker: Sandbox Kit Spec - Authority as Code
• The Register: Docker's new sandboxes aim to contain AI agents for real
• InfoQ: Docker Cloud Sandboxes Provide a Consistent Sandbox Abstraction
• docker/sandbox-kit-spec on GitHub
• Docker Sandboxes product page