Docker puts AI agents in pay-as-you-go cloud sandboxes

Docker has launched Cloud Sandboxes, a hosted microVM service designed to keep autonomous AI agents away from the host environment. The important shift is practical: developers can run agents with access to tools and code while placing the riskiest execution inside a stronger cloud boundary than an ordinary local container.

Watch Desk analysis

What happened

Docker’s new service provides isolated microvirtual machines managed through the Docker CLI, Console, REST API or a TypeScript/JavaScript SDK. The Register reports that the sandboxes are intended to block agents from reaching host environments, after demonstrations showed that local containers could fail under probing by models such as Anthropic’s Claude.

Cloud Sandboxes can be used with pre-configured agent kits, Model Context Protocol integrations, SSH and GitHub connections. Docker is also updating its Kits specification to use standard OCI images, supporting packaging and communication between multiple agents.

The service is experimental and requires Docker’s Agentic Platform subscription. Compute is charged by the second according to runtime and resource settings, while model-inference costs are billed separately by the relevant model provider. That distinction may save surprises later, although “pay by the second” remains one of technology’s more elegant ways to turn curiosity into an invoice.

Why it matters

AI agents are increasingly being given the ability to write files, run commands, access repositories and call external services. A normal container can reduce the blast radius, but Docker’s reported demonstrations suggest it should not automatically be treated as an impenetrable wall when an agent is actively looking for a way out.

The cloud sandbox approach moves the containment boundary away from the developer’s main machine and into managed microVM infrastructure. That could make experimentation safer for teams building coding agents, MCP tools and multi-agent workflows, especially where a model may execute untrusted or unpredictable code.

It does not make an agent trustworthy by magic. Credentials, network access, mounted repositories and approval flows still determine what damage a compromised or misbehaving agent could cause. Isolation is a useful seatbelt, not a driving licence.

Our read

This is a meaningful computing and AI-security development because it addresses a specific operational problem: agents need enough access to do useful work, but not enough access to turn a developer laptop into an incident report.

Docker’s approach is promising, particularly if the same workflow can move between local development and cloud isolation without forcing teams to rebuild everything. The unresolved question is whether the security boundary holds under a broad range of real workloads, integrations and escape attempts. The Register’s account describes Docker’s demonstrations, not an independent security audit or proof of production safety.

For developers, the sensible starting point is to treat Cloud Sandboxes as a containment layer to test, not as permission to hand an agent every credential in the cupboard. Start with narrow scopes, disposable resources and explicit network rules. The machines may be virtual. The consequences are not.

What to watch

• Independent testing of the microVM boundary against capable coding and tool-using agents.
• The permissions, network controls and credential-handling defaults in real deployments.
• Whether Docker publishes incident, escape-attempt or performance data from the experimental service.
• The total cost of running long-lived agents once compute, storage and model inference are combined.

Discussion spark: Should AI agents be allowed to run with broad tool access inside managed microVMs, or should production systems require a person to approve every consequential action regardless of the sandbox?

Watch Desk is operated by WittyWires as an independent cross-cutting AI news tracker. It does not speak for the organisations or people it covers.