Docker announced the availability of Cloud Sandboxes for running AI agents inside isolated microVM environments, allowing developers to start a task locally and then move the file system to Docker’s cloud infrastructure to continue long-running tasks before bringing the results back for review. The move comes alongside the publication of the Sandbox Kit specification under the Apache 2.0 license, with Docker committing to submit it to the Cloud Native Computing Foundation (CNCF) for neutral governance.
The company disclosed these developments during the WeAreDevelopers World Congress North America conference, held in San Jose from September 23 to 25, 2026, which was attended by more than 10,000 developers, AI application builders, and technology leaders, according to Docker.
A Separate Runtime Environment for Long-Running Tasks
Each Cloud Sandbox environment consists of a microVM, meaning a small virtual machine with its own kernel and Docker daemon. The agent inside it can install dependencies, build applications, and run containers, while Docker provides the necessary computing capacity. Developers use the same sbx command-line tool when working locally or in the cloud.
In practice, the service targets tasks such as software refactoring or migration, which can take longer than keeping a laptop open. Multiple tasks can run in parallel without loading local device resources, while work continues in the cloud even after the computer is closed. The service is currently available, and Docker charges for computing capacity by the second.
The local and cloud environments use the same agent packages, called Kits, but credentials and policies are configured separately in each environment. This means that moving a task does not automatically move all permissions; instead, it requires an explicit decision about which resources the agent is allowed to access.
An Open Specification for Describing the Agent and Its Permissions
Sandbox Kit defines the environment required to run an agent in a shareable and reviewable package. A Kit is an OCI image containing the agent and its tools, along with declarations for access to networks, credentials, and storage. Teams can build, push, pull, inspect, and install them using a digital fingerprint, just as they do with regular container images.
This model helps reproduce the environment and makes permission changes visible to reviewers. If a Kit requests a network destination or an additional credential, the change appears within the package, while the runtime decides what will actually be granted and enforces the policy outside the agent. Docker Sandboxes was the first runtime to implement the specification, while Nous Research participated as a launch partner using its open-source Hermes agent.
What Changes in Practice?
Docker believes that execution isolation alone is not sufficient to entrust agents with larger tasks. The company showed an example of an agent that managed to read a secret located on the host because the Docker socket was mounted into the container; this did not require a new vulnerability but resulted from the permissions granted by the configuration. In another demonstration, an attempt to access the host from inside a microVM failed.
Docker also demonstrated policies that prevent actions such as deleting a GitHub repository by default and record blocked decisions in audit logs. But the company acknowledged the limits of these controls: blocking an unauthorized network destination differs from detecting that an otherwise permitted message is addressed to the wrong customer. Therefore, narrow permissions—such as allowing messages to be read and drafted without sending them—remain necessary, while verifying that an action aligns with the user’s intent remains an open challenge.
The announcement’s significance lies in combining agent isolation, portability of its environment, and an open, reviewable format for describing its permissions. The questions left unresolved by the article concern the extent to which other runtimes will adopt the specification and how agent identity and policies will be standardized across organizations; Docker itself indicated that some of these points remain industry challenges.