Docker Cloud Sandboxes: isolation, permissions and pricing

You want to hand off dependency updates or refactoring that take hours to Claude Code or Codex. But if you run them on a developer's PC with confirmations skipped, your source code, SSH keys and cloud credentials all stay within reach. Even if you put them in a sandbox, engineering leads cannot decide without knowing what gets isolated and what remains, how much running in the cloud costs, and whether the company can sign up for it.

On September 24, 2026, Docker released "Cloud Sandboxes," which lets the Docker Sandboxes previously available locally also run in the cloud, and "Sandbox Kit Specification v3," which distributes agent permissions as OCI images. This article is document research based on Docker's official blog, the original documentation in the docker/docs repository, and the docker/sandbox-kit-spec repository, checked on October 4, 2026. Only the diff evaluation of Kit permissions was verified by running the specification repository's code in the editorial team's environment.

What was released, and at what stage

The announcement covers the following.

• Cloud Sandboxes: Runs the same microVM sandboxes as local ones on Docker-managed compute. sbx move moves a sandbox, including its file system, between local and cloud
• Sandbox Kit Specification v3: Defines a Kit bundling agents, tools and permission requests as a standard OCI image. Released under Apache 2.0
• Contribution to CNCF: Docker announced it will move the Kit specification to CNCF's neutral governance. As of October 4, GOVERNANCE.md in the specification repository says, "Docker maintains this specification."

The release stage differs between local and cloud. The release notes for Docker Agentic Platform, the foundation of Cloud Sandboxes, describe September 24 as an "experimental public release." The CLI's cloud features page also says, "experimental. Features and behavior may change." The Kit specification's README likewise states, "This specification is experimental," and sets a target of Q4 2026 for the stable version. Meanwhile, local Docker Sandboxes are explicitly free for both the CLI and local compute, and commercial use is permitted.

What a local sandbox isolates and what it leaves exposed

According to the documentation, each sandbox runs as a microVM with its own Linux kernel and its own Docker Engine inside. Agents can even use sudo inside the VM, but cannot reach the host's Docker daemon. This is where it differs from setups that pass the host's Docker socket into a container.

Note that changes to a directly mounted workspace are reflected on the host as is. The documentation warns that .git/hooks/, CI configuration, and AI tool configuration files such as .claude/settings.json can be rewritten and may be executed on the next commit or build. Git hooks do not appear in git diff. How instruction files for agents are read is also covered in the conditions under which Claude Code does not read AGENTS.md. For an internal standard, it is safer to start from --clone, which cannot write to the original repository.

Organization-wide policy distribution (network, files, MCP), audit logs and enforced sign-in with organization accounts are a "separate paid subscription," and you are directed to contact sales. Pricing is not listed in public materials.

What changes when you move to the cloud

Permissions do not carry over

Cloud sandboxes use a separate secret store and network policy from local ones. Moving with sbx move does not copy local rules or credentials. Only credentials written to files may be included in the snapshot, so the documentation advises deleting them before moving.

Another major point is that restrictions by HTTP method or path (L7 filtering) are not available in the cloud. Rules such as "the GitHub API can be used, but repositories cannot be deleted" only take effect locally. If you try to move a sandbox that has such rules, sbx move warns you and asks for confirmation. Local host paths and GPUs are also unavailable from the cloud.

Pricing and contract terms

The pricing on the official blog is pay-as-you-go, billed per second. Stopped sandboxes are not billed, and volumes, outbound traffic, and storage for public images and Kits are said to be free. Model usage fees are separate, and you bring your own API keys.

The default run time is one hour, and a single session can last up to 24 hours. Even with extensions, it cannot exceed 24 hours from creation. When the limit is reached, sandboxes that can be resumed are stopped and the rest are deleted.

The contract unit is a hurdle for company adoption. The blog lists eligibility as "Docker Personal and Pro accounts," and the documentation says that even if you belong to an organization, you sign up with a personal Docker account and are billed separately from your Docker subscription. The FAQ describes the initial release as "for individual use," and team sharing or joint ownership is not supported. The blog says new accounts get $250 in credit for a limited time, but check the conditions and expiration on the sign-up screen. As for the required sbx version, the blog says 0.45.1 or later and the documentation says 0.45.0 or later.

Turning permissions into reviewable diffs with Sandbox Kit

A Kit is an OCI image that records "where the agent connects and which credentials and volumes it uses" in the image manifest annotation vnd.docker.sandbox.kit.descriptor. It can be handled with your usual registries, scanners and signing mechanisms, and pinning it by digest pins both its contents and its permission requests together. Below is part of the GitHub CLI Kit in the repository.

- 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/**]

Because deny takes precedence over allow, this token can create pull requests but cannot delete repositories. Credentials are proxyManaged: true, so the actual values never enter the sandbox. However, a Kit only declares requests; enforcement is up to a runtime that follows the specification. Currently, only Docker Sandboxes has announced support.

The specification requires asking the user for approval when a Kit update broadens its requests. The editorial team modified the GitHub CLI Kit in four ways and had the Go package in the specification repository (commit 129be2f) evaluate them (Linux, Go 1.26.8).

Removing a deny rule was also treated as an expansion of permissions. Conversely, changes that reduce permissions pass without approval. This is the judgment of the specification's library; we did not check the actual update screen in Docker Sandboxes. If you distribute Kits internally, managing Kit definitions in Git and making diffs to destinations, credentials and deny rules subject to pull request review fits well with this mechanism.

What to decide before adopting it (editorial team's proposal)

1. How to provide the workspace. Default to --clone, and limit direct mounts to specific repositories. Keep secrets such as .env outside the working directory
2. Network defaults. Either start from Locked Down and add the destinations you need, or scrutinize the Balanced list with sbx policy ls. Disable SSH agent forwarding if you do not use it
3. Scope of work sent to the cloud. Configure credentials and policies separately on the cloud side, and keep work that relies on L7 rules local. Since contracts are with personal accounts, decide in advance how costs are reimbursed and whose API keys will be used
4. Kit sources. By default, remote Kits can only be pulled from Docker Hub (kit.allowedSources), and local Kits are allowed (kit.allowLocalKits). Decide where internally built Kits will be stored and who will review them

For how far to delegate permissions, see the case of an evaluation AI escaping its sandbox; for whether to host your own execution environment, see our article on drawing the line for AI execution environments.

On October 4, 2026, we directly opened and cross-checked Docker's official blog (the Cloud Sandboxes announcement, the Kit specification explainer, the CNCF collaboration, and the WeAreDevelopers recap), the Docker Sandboxes and Docker Agentic Platform pages in the docker/docs repository (commit 1cb9a4d), and the docker/sandbox-kit-spec repository (commit 129be2f). The Kit diff evaluations are the results of running the specification repository's Go package once each in the editorial team's environment. Because KVM is not available in this environment, we did not start a local sandbox, and we did not verify signing up for or running Cloud Sandboxes, billing, the behavior of Kits containing L7 rules in the cloud, or pricing for organizational governance.

For designing development setups that use coding agents, or planning automation including how to divide permissions, contact GleamHub.

Sources

• Introducing Cloud Sandboxes: Start on Your Laptop, Finish in the Cloud — Docker Blog
• From Dockerfile to Kit: the Docker Sandboxes Kit Specification — Docker Blog
• Docker and CNCF partner on an open spec for agent permissions — Docker Blog
• Trust Docker for the agents you don’t — Docker Blog
• Docker Sandboxes — docker/docs (content/manuals/ai/sandboxes)
• Compare local and cloud sandboxes — docker/docs
• Security model / Isolation layers — docker/docs
• Docker Agentic Platform release notes — docker/docs
• Sign up for Docker Agentic Platform — docker/docs
• Docker Agentic Platform FAQ — docker/docs
• docker/sandbox-kit-spec — README
• docker/sandbox-kit-spec — examples/gh/gh.yaml