NEW DELHI, September 27, 2026, 1:45 PM IST — Docker has launched Cloud Sandboxes, a managed service that lets developers run AI coding agents in isolated microvirtual machines after disconnecting their laptops, alongside a new open specification for packaging an agent, its tools and its access rules as a standard OCI image.
The release matters because software teams are moving from short, interactive coding prompts to agents that can spend hours refactoring applications, migrating dependencies and running test suites. That shift turns the agent’s execution environment into an infrastructure and security concern: platform teams must decide where autonomous code runs, what it can reach, which credentials it receives and how those permissions are reviewed.
Docker moves long-running agent work off developer laptops
Docker said Cloud Sandboxes use the same command-line interface, policy model and microVM isolation as its local sandboxes, but run on Docker-managed compute. Developers can start a workflow locally and move its filesystem state to the cloud, or begin directly in the cloud through the CLI or web console.
The service is available now on a pay-as-you-go basis for Docker Personal and Pro accounts. Docker lists configurations from one virtual CPU and 2 GiB of memory at $0.07 per hour to 16 virtual CPUs and 32 GiB at $1.12 per hour. Billing is metered by the second, paused sandboxes do not incur compute charges, and a session can run for up to 24 hours. Model inference is separate: users bring their own model-provider key.
Docker’s product announcement says cloud sandboxes can boot in the low hundreds of milliseconds and support parallel tasks without teams provisioning the underlying hosts. Prebuilt Kits are available for agents including Claude Code, Codex, GitHub Copilot, Google Antigravity, OpenCode and Hermes.
Those are vendor claims, not independent performance guarantees. Teams evaluating the service should measure startup time, dependency-cache behavior, data transfer, test duration and total model costs against their own workloads.
MicroVMs create a stronger boundary than a normal container
Docker positions each sandbox as a dedicated microVM with its own kernel and private Docker daemon. That design is intended to let an agent install packages, build images, run Compose stacks and execute shell commands without exposing the host’s Docker socket or sharing the host kernel.
The distinction is practical for DevOps teams. A conventional container remains useful for deterministic application workloads, but an autonomous coding agent is a probabilistic actor that may generate commands, fetch dependencies and alter its plan. Giving such an agent a mounted host socket or broad workstation credentials can enlarge the blast radius of a faulty instruction or prompt-injection attack.
Isolation alone does not make an agent trustworthy. A useful agent still needs some combination of source access, artifact repositories, cloud APIs, issue trackers and deployment systems. The security outcome therefore depends on the permissions around the sandbox as much as the virtualization boundary beneath it.
Sandbox Kits make agent permissions reviewable
Docker also published version 3 of its Sandbox Kit Specification under the Apache 2.0 license and said it plans to bring the specification to the Cloud Native Computing Foundation for neutral governance. A Kit is an ordinary OCI image that can carry an agent workload together with declarations for tools, network access, credentials, volumes and instructions.
Because Kits use OCI images, teams can build, pull, scan, sign and pin them with familiar registry tooling. A workload supplies the base environment and executable command, while reusable mixins add capabilities such as a command-line tool, credential binding or network policy.
The most useful idea for platform engineers is “authority as code.” A permission expansion can appear in a pull-request diff and be tied to the same immutable digest as the agent environment. Docker’s example allows selected GitHub API methods while explicitly denying repository deletion. The runtime, not the model, is responsible for enforcing that boundary.
There is an important limitation: the declarations grant nothing by themselves. Docker’s specification says they are requests that only have meaning when a conforming runtime enforces them, and Docker Sandboxes is currently the first such runtime. The project’s value as a portable standard will depend on CNCF governance, other runtime implementations and real-world interoperability.
What DevOps and platform teams should verify
Docker’s release notes describe cloud support as experimental and require an active Docker Agentic Platform subscription. The same notes document a recent fix for a credential-revocation issue in which a running proxy could remain authorized until the sandbox was recreated. That history reinforces a basic operational rule: sandboxing reduces risk, but teams still need short-lived credentials, revocation tests and audit logs.
A production evaluation should start with low-risk repositories and read-only integrations. Platform teams should define explicit egress allowlists, issue task-scoped credentials, separate build and deployment identities, cap runtime and spending, preserve execution evidence, and require human approval before an agent merges code or changes production infrastructure.
Teams should also test the local-to-cloud handoff carefully. Docker notes that local and cloud sandboxes keep separate secrets, templates and network policies. A moved filesystem is not proof that the destination has identical authorization, so policy parity should be validated before unattended work begins.
The launch fits a broader shift from treating coding assistants as editor features to operating them as managed workloads. That makes familiar disciplines—least privilege, immutable artifacts, workload isolation, observability and change review—central to AI-agent adoption. GravityDevOps readers can place those controls within a broader LLMOps operating model and connect agent-produced changes to the approval gates covered in our CI/CD tools comparison.
What remains uncertain
Docker has confirmed current availability, published pricing and opened the Kit specification, but it has not yet demonstrated broad multi-runtime adoption or provided independent evidence that Cloud Sandboxes meet every enterprise compliance requirement. Centralized enterprise governance is also described as coming soon rather than generally available.
For now, the release is best read as a significant infrastructure option, not a complete safety solution. Docker has made long-running agent execution easier to isolate and package; organizations still own the surrounding identity design, repository protections, deployment approvals, monitoring and incident response.
Sources
Docker’s Cloud Sandboxes announcement, product and pricing details, Sandboxes release notes, Sandbox Kit Specification overview, and independent reporting from The Register.
