Coding agents do more than write code. Agents can install dependencies, access networks, use credentials, and keep working after we’ve moved on to something else. Agents need access to get real work done. But the more access they have, the bigger the impact of a mistake. The challenge is building enough trust into the system to give agents more freedom without giving them access to everything. 

At WeAreDevelopers North America, Docker President Mark Cavage laid out Docker’s answer: give every agent a strong boundary, make its environment and authority reproducible, and let the work run where it makes sense, from a developer’s laptop to the cloud. 

In 30 minutes, Mark demonstrates what happens when an agent pushes beyond a container’s limits and how Docker Sandboxes create a stronger boundary. He then connects that foundation to Kits, cloud capacity for work that needs to continue beyond the laptop, and new partnerships helping developers put agents to work safely. 

Agents are actors, not workloads

Containers were built to isolate applications. Agents do more. They make decisions and act on the systems around them, so the boundary needs to extend to the environment they can reach. 

Mark’s onstage demo makes that clear. The container worked as designed. What the agent needed was containment around its full environment. Docker Sandboxes provide that containment. Each agent gets its own isolated microVM and kernel, separate from the developer’s host environment. 

Developers can choose the agent, model, and tools that fit the job, then define the sandbox’s access to files, networks, and secrets. Those policies stay outside the agent’s control. Together, the sandbox and its policies create a trusted environment for autonomous work. 

Docker Sandboxes are available today through the free, standalone CLI, so developers can bring stronger isolation to the agent workflows they already use. 

Make the agent and its authority reproducible

A strong boundary gives an agent a safe place to work. Developers also need a repeatable way to define what runs and what it can access. 

In the keynote, Mark announced the next generation of Docker Sandbox Kits, now built as standard OCI images, and invited ecosystem partners to help shape the specification as Docker works towards neutral governance. 

Docker Sandbox Kits package the agent, its tools, and the rules for what the sandbox can reach into one versioned, shareable artifact. Developers can share Kits through the same workflows they already use for container images, while keeping changes to an agent’s authority visible and reviewable. 

The result is a common foundation for the agent ecosystem, built on an open standard. 

Dockerfiles made software reproducible. Kits make authority reproducible

Start on your laptop. Finish in the cloud.

Some agent work begins and ends on a developer laptop. Longer-running or parallel work needs capacity that stays available when the developer steps away. In the keynote, Mark announced Docker Cloud Sandboxes, bringing the same microVM-based isolation from the laptop to Docker-managed cloud compute. 

Using the familiar sbx workflow, developers can start locally, move their work to the cloud with one command, and let it continue after they close their laptop. They can also run tasks in parallel without provisioning or maintaining the infrastructure themselves. 

Docker Cloud Sandboxes are available today with pay-as-you-go pricing.

An ecosystem built around trust

An open agent ecosystem needs both: choice for the developers and shared standards the industry can build on.

Nous Research joined Mark onstage to show Hermes running as a first-class Kit in Docker Sandboxes. The demo showed what choice looks like in practice: a third-party agent packaged for a common environment, with Docker providing the underlying isolation and controls. Developers can choose the agent that best fits their work without having to rebuild the trusted execution layer around it.

Choice also depends on shared standards that the wider ecosystem can adopt. Docker has committed to submitting its Kits specification to the Cloud Native Computing Foundation (CNCF), the open source, vendor-neutral hub of cloud-native computing.

Together, these partners show what an open agent ecosystem can look like: choice at the agent layer and a shared format for packaging an agent’s environment and authority. Docker provides the trusted foundation underneath, whether agents run locally or in the cloud.

Trust comes from the system around the agent

Taken together, the announcements in Mark’s keynote form one system. Sandboxes provide a deterministic boundary. Kits make the agent’s environment and authority reproducible. Cloud Sandboxes extend the same trust model to durable cloud capability. 

They give developers the freedom to choose their agents and more autonomy, while retaining control over what they can access and change. 

As agents take on bigger jobs, the infrastructure around them matters more. Docker provides the trusted foundation they need to work locally or scale in the cloud, while developers continue to stay in control of what ships.  

Ready to try Cloud Sandboxes?

For a limited time, new accounts can claim $250 in compute credit to get started.

Watch, Explore, Build

• Start Locally: Run an agent in a Docker Sandbox 
• Scale in the Cloud: Read the announcement and get started with Docker Cloud Sandboxes 
• Build with Kits: Read the technical deep dive and explore the open kit specification. 

Run agents on your laptop, in the cloud, and move between them with one command, all safely. Earlier this year, we launched Docker Sandboxes: microVM environments where coding agents can work autonomously and safely. 

Since then, agents have started taking on long-horizon work: tasks that run for hours, not minutes. Agents need a new place to work. Today, we’re introducing Cloud Sandboxes: the same microVM-based sandbox, running on Docker-managed compute, with one command to move between them. 

The most important change in coding agents over the past year is that they can work for much longer. Tasks that used to need a developer checking in every few minutes (a large refactor, a dependency migration, a test suite that takes an hour) you can now hand off and review when they finish.

When agents worked in short bursts, the question was whether the model could hold a task together. Now that they work in hours, the question is where those hours happen. A laptop is built around a person. It sleeps when the lid closes, slows down on battery, and disconnects when you move. None of that matters for a task that takes thirty seconds. All of it matters for a task that takes all night.

We built Docker Sandboxes to answer the first question about agents: is it safe to run unattended? In Docker Sandboxes, agents run in a microVM with its own kernel and Docker daemon, isolated from your machine, so they can work autonomously while your files, network, and secrets are protected if an agent steps out of line.

Today, we’re introducing Cloud Sandboxes to answer the second question: how do I run a dozen agents at once, for five, ten, or 21 hours each, without watching any of them? Cloud Sandboxes is the same microVM, running on Docker-managed compute. The isolation model is identical. The CLI is identical. What changes is that the machines underneath are always on, and there are as many of them as you need.

Here’s what that means for you:

Close your laptop and keep the work going. Start an agent in the cloud before you leave for the day, disconnect, and review what they did in the morning.

Start local and move to the cloud when your task outgrows your laptop. Iterate with an agent on the code in front of you, then hand off long tasks and loops to a background agent.

$ sbx move my-project --to cloud

A move captures the sandbox’s filesystem and recreates it on the other side, so your work carries over. This works in both directions.

Run 100 tasks in parallel with nothing to provision. Docker runs the compute. You point your agents at it. Each one gets its own microVM, its own secrets, and its own network policy.

Try things cheaply. Run a pre-built agent for an hour to test an idea, then spin it down.

Everything an agent needs to run on its own

Agents that do long-horizon work without you need three things:

1. A way to start with nothing to install
2. Tools to do their jobs
3. Limits on what it can reach

Cloud Sandboxes ship with all three. You can spin up and manage Cloud Sandboxes from the CLI or from the web console.

Kits. A kit is a pre-configured, pre-built sandbox for an agent. The leading coding agents are ready today, including Claude Code, Codex, Copilot, Antigravity, Open Code and Hermes. Or, you can easily add your own. It’s easy to spin up. sbx –cloud run codex starts one, for example. 

MCP. Connect the MCP servers your agents need (Jira, Linear, Grafana, incident.io, or any streamable HTTP endpoint) once, and all your agents can reach them through a single gateway whether they’re running in the cloud, locally, or in other clients like the ChatGPT desktop app.

Secrets. Store keys or tokens once. Cloud Sandboxes proxy injects it per request, so agents don’t see the actual secret. Prompt injections can’t touch secrets your agents never had in the first place.

Policies. Set network policies on what endpoints agents can access by defining them once. Centralized governance is coming soon for enterprises through Docker AI Governance.

You can access and manage all of this through the web console.

Why one sandbox in two places

We could have built Cloud Sandboxes as a separate product with its own commands. We didn’t, and the reason is simple: how much you can trust your agent shouldn’t depend on where it happens to be running.

As far as we know, no other agent sandbox works this way. We think the right answer to using agents is one strong isolation model that runs in both surfaces (locally and in the cloud), and an easy way (one command) to move between them.

These aren’t two tiers of one product. Interactive work belongs on your laptop. Work that takes hours belongs in the cloud. Most developers need both, and now you don’t have to pick.

Pricing

Cloud Sandboxes are pay-as-you-go. We meter compute by the second, and nothing else. A paused sandbox costs nothing. Volumes, egress, and hosting public images and Kits are free. You can bring your own model key and keep your existing provider for inference.

Sandboxes run for one hour by default and up to 24 hours per session.

Get started

From the browser: sign in to the web console, choose a kit, and click Run. 

From the terminal:

$ brew install docker/tap/sbx
$ sbx login
$ sbx --cloud run claude

You’ll need sbx 0.45.1 or later and the pay-as-you-go plan, available on Docker Personal and Pro accounts. Docker Sandboxes on your laptop remain free and standalone, with no Docker Desktop required. Local and cloud sandboxes keep separate secrets, templates, and network policies, so read the differences in the docs before you move a local workflow.

For a limited time, new accounts get $250 in free Cloud Sandboxes credit. Claim it here.

We think the way software gets built is changing. Developers will spend less time typing and more time directing: handing agents real tasks, stepping back, and reviewing what comes back. For that to work, agents need environments that are safe enough to run unsupervised and durable enough to run for hours. That’s what Docker Sandboxes is for, and as of today, it runs on your laptop and in the cloud.

Start one before you close your laptop tonight.