Image: “CERN Computer Center 09.jpg” by SimonWaldherr, licensed CC BY-SA 4.0, source: Wikimedia Commons On the same topic, we previously covered the Plugin4Shell security flaw threatening AI coding agents, which shows just how real these attack vectors already are.
An AI coding agent kicks off a task at 11 p.m., watches the developer’s laptop shut down, and keeps working until morning anyway: that’s exactly the scenario Docker’s newest product addresses. On September 24, 2026, at WeAreDevelopers North America, Docker introduced Docker Cloud Sandboxes, extending its local sandbox technology into the cloud specifically for autonomous AI agents that need to run long and unattended. For web developers and DevOps teams increasingly weaving AI agents into production workflows, this marks an important shift: isolation is becoming a core infrastructure question, not an afterthought.
The launch lands at a moment when the question “what should an AI agent actually be allowed to touch?” keeps getting louder. Autonomous coding agents access file systems, run shell commands, call APIs, and install dependencies, often without a human reviewing every step. This is precisely where Docker Cloud Sandboxes come in: a managed, isolated cloud environment that applies the same security principles as local sandboxes, but scales without teams having to run their own infrastructure.
Table of Contents
Key Takeaways
- Docker Cloud Sandboxes were announced on September 24, 2026 at WeAreDevelopers North America, extending Docker’s local microVM sandboxes into the cloud.
- Each sandbox runs in its own microVM with a dedicated kernel and Docker daemon, isolated from the host’s file system and network.
- Boot times sit in the low hundreds of milliseconds, scaling from 1 to 16 vCPUs, fully managed by Docker.
- Docker simultaneously unveiled the next generation of “Kits”: an open specification for packaging an agent, its tools, and its access rules as a standard OCI image compatible with Docker Hub.
- Docker plans to submit the Kits specification to the CNCF, a move welcomed publicly by CNCF CTO Chris Aniszczyk.
Why isolation is becoming a core issue for AI agents
Classic containers were never designed for autonomous, potentially unpredictable software agents. They isolate processes but typically still share the kernel and network stack with the host. For an AI agent that writes code independently, runs commands, and reaches out to external services, that often isn’t enough. Docker President Mark Cavage put it bluntly: modern agentic workflows require a fundamentally different approach to isolation than classic containers. That statement accompanied the Cloud Sandboxes announcement and underlines that Docker treats this as an architectural necessity, not a cosmetic feature.
The industry has spent months debating how autonomous coding agents might, accidentally or through faulty instructions, gain access to systems well outside their intended scope, such as internal APIs, production databases, or sensitive repositories. Reports like these have dampened many teams’ trust in uncontrolled agent execution. Docker responds with a model that routes network access through a configurable proxy layer, keeps credentials outside the sandbox, and uses policies to control exactly which hosts or internal services an agent may even contact.
Chief Product Officer Mat Velloso frames the underlying tension this way: the biggest unsolved problem is how to capture AI’s productivity gains safely, with the right guardrails. That exact equation, more agent autonomy paired with stricter control, runs through the entire product launch.
What Docker Cloud Sandboxes actually deliver
Docker Sandboxes already existed as a local solution: each sandbox runs in its own microVM with its own kernel and Docker daemon, creating a hard security boundary that goes beyond classic container isolation. These local sandboxes suit tasks where an agent works directly with files and hardware on the developer’s machine.
Docker Cloud Sandboxes carry over the same isolation model but shift execution to Docker-managed cloud infrastructure. Concretely, that means:
- No local virtualization needed: developers don’t have to provision or maintain their own VM infrastructure.
- Persistence beyond sessions: agents keep running even after the laptop is closed.
- Same CLI, same policies: switching between local and cloud happens through the same
sbxcommand line, with no new tooling to learn. - Fast provisioning: boot times in the low hundreds of milliseconds allow elastic scaling of individual agent instances.
- Flexible scaling: compute scales from 1 to 16 vCPUs depending on the workload.
This combination of speed and isolation is deliberately tailored to agent workloads that need compute irregularly but intensely, such as complex multi-agent pipelines or longer-running coding sessions.
Architecture at a glance
| Feature | Local Sandbox | Docker Cloud Sandboxes |
|---|---|---|
| Execution location | Developer machine | Docker-managed cloud infrastructure |
| Isolation | microVM with own kernel/daemon | Same microVM model, extended cloud-native |
| Availability after shutdown | Ends with the device | Keeps running independently |
| Scaling | Bound to local hardware | 1 to 16 vCPUs, dynamic |
| Control | sbx CLI |
Same sbx CLI |
Kits: standardized packages for agents and their access rules
Alongside Cloud Sandboxes, Docker introduced the next generation of “Kits.” A Kit is an open specification that packages an agent together with its tools and the rules governing what it’s allowed to touch into a single, shareable artifact. Crucially, it’s a standard OCI image, compatible with Docker Hub, with no proprietary format involved.
For DevOps teams, that means:
- Reproducibility: a Kit can be versioned, distributed, and wired into CI/CD pipelines just like a familiar container image.
- Least-privilege by design: access rules ship directly inside the artifact instead of being managed separately.
- Portability: since Kits build on open OCI standards, they run both locally and in Docker Cloud Sandboxes without modification.
Docker has announced it will formally submit the Kits specification to the Cloud Native Computing Foundation (CNCF). CNCF CTO Chris Aniszczyk publicly welcomed the move, a signal that Kits aren’t meant to stay a Docker-internal tool but could become an industry-wide standard. For teams already invested in open cloud-native technologies, that significantly lowers the barrier to entry, since it avoids lock-in to a single vendor’s ecosystem.
Where this fits in the broader market
Docker isn’t alone in concluding that AI agents need their own execution layer. Other major cloud providers are working on comparable concepts for secure agent execution on their own infrastructure. The trend is clear: isolation, policy enforcement, and secure credential handling are becoming baseline requirements industry-wide for production AI agent systems, not a niche concern of individual vendors.
For web developers, this has a practical upshot: anyone integrating AI agents into development workflows today should build in isolation from the start rather than bolting it on later as a security feature. Docker Cloud Sandboxes lower that barrier meaningfully, since no dedicated VM infrastructure needs to be built.
Practical relevance for web developers and DevOps teams
Where do Docker Cloud Sandboxes fit in practice? Typical scenarios:
- Unattended coding agents: an agent works through a large refactoring ticket overnight, without a developer needing to stay online.
- Multi-agent pipelines: several specialized agents work in parallel on different subtasks, each in its own isolated environment.
- CI/CD integration: agents test, build, or review code in reproducible, isolated cloud instances before changes reach production pipelines.
- Regulated environments: teams with compliance requirements benefit from clear network and access rules enforced via policy rather than manual configuration.
Because the same CLI and the same policies apply as with local sandboxes, teams already using Docker Sandboxes face no additional learning curve. Moving from local to cloud execution is more of a configuration decision than an architectural overhaul.
“Modern agentic workflows necessitate a fundamentally different approach to isolation than classic containers.” — Mark Cavage, President, Docker
Conclusion and next steps
Docker Cloud Sandboxes answer a question that’s becoming more pressing as AI agents grow more autonomous: how can productive, unattended agent work happen without losing control over systems and data? Docker’s answer combines proven microVM isolation with cloud scalability and an open Kits specification on its way to the CNCF. For development teams, that’s a practical foundation for testing or running agents in production without building their own sandbox infrastructure.
As a next step, interested teams should install the sbx CLI and try local sandboxes on a small scale, then deliberately evaluate which agent workloads suit the cloud variant, while keeping an eye on the Kits specification on GitHub (docker/sandbox-kit-spec) to benefit early from standardization. Anyone already running AI agents in daily development work should treat isolation and access control as a fixed part of the architecture, not an afterthought.
References
[1] Docker Sandboxes – https://www.docker.com/products/docker-sandboxes/
[2] Get Started – https://docs.docker.com/ai/sandboxes/get-started/
[3] Sandboxes – https://docs.docker.com/ai/sandboxes/
[8] Docker Launches Cloud Sandboxes, Extending Secure AI Agent Isolation Beyond the Laptop – https://www.docker.com/press-release/cloud-sandboxes-extending-secure-ai-agent-isolation-beyond-the-laptop/
[9] Why AI Agents Need Isolation – https://www.docker.com/blog/why-ai-agents-need-isolation/
[10] Architecture – https://docs.docker.com/ai/sandboxes/architecture/
[11] Building AI Teams with Docker Sandboxes – https://www.docker.com/blog/building-ai-teams-docker-sandboxes-agent/
[14] Docker Sandboxes FAQ – https://docs.docker.com/ai/sandboxes/faq/
[15] Docker Sandboxes FAQ – https://docs.docker.com/ai/sandboxes/faq/
