Analyst(s): Mitch Ashley, Vikram Rathnam
Publication Date: October 1, 2026
At WeAreDevelopers World Congress North America, Docker introduced Cloud Sandboxes and an OCI-based Kit specification that packages an agent’s tools, credentials, and reach as a versioned artifact. The move extends Docker’s build-ship-run model from code to agent authority. It also puts Docker into the contest to own the surface where enterprise agents execute.
What Is Covered in This Article:
- Docker introduced Cloud Sandboxes, a hosted service that runs AI-agent workloads in Docker-managed, isolated microVMs.
- The updated Sandbox Kits, built on Kit Specification v3, package an agent, its tools, and its access rules for networking, credentials, and volumes as an OCI (Open Container Initiative) image.
- Docker said it is inviting ecosystem partners to shape the Kit specification and is working with the CNCF toward an open permissions specification.
The News: At WeAreDevelopers World Congress North America in September 2026, Docker announced Docker Cloud Sandboxes, a hosted service for running AI-agent workloads in Docker-managed, isolated microVMs. Docker positioned the service for longer-running or compute-heavy agent tasks that continue after a developer closes a laptop, and said it uses the same sandboxing model across the laptop and cloud compute, so a workload moves between them without reworking its environment.
Docker also updated its Sandbox Kits under Kit Specification v3. A Kit packages an agent, its tools, and the rules governing its access, including networking, credentials, and volumes, as a reusable OCI image rather than a proprietary package format. Docker said it is inviting ecosystem partners to help shape the Kit specification as it works toward neutral governance, and its blog frames related work with the Cloud Native Computing Foundation (CNCF) around an open, vendor-independent permissions specification.
Mark Cavage framed the keynote message as manufacturing trust for agents: give an agent a strong isolation boundary, define and reproduce the environment and authority it receives, and run execution locally or in cloud infrastructure as appropriate.
Docker Reruns the Container Playbook, This Time for Cloud Sandbox Kit
Analyst Take: Docker packaged an agent’s runtime authority as a versioned OCI artifact, and that puts it into the agent control plane contest. Under Kit Specification v3, a Kit declares an agent’s tools, mounts, credentials, and network access as a deployable object. Cloud Sandboxes gives that object a place to run, in Docker-managed microVMs on the developer’s machine or in the cloud.
This is a playbook Docker has run before. The original Docker made the container a portable, reproducible unit for software. It won by owning that unit; the infrastructure under it belonged to others. Kit Specification v3 runs the same playbook one layer up, and the Kit becomes the portable, governed unit for agent authority. A Kit records what an agent runs and what it may reach, which makes agent permissions and execution policy part of the software supply chain.
Docker enters the agent control plane contest
That places Docker in a fight already underway. IDE, cloud, CI/CD, and runtime vendors are each moving to own the surface where agents execute, and Docker is entering from the packaging and execution layer it already holds. Docker’s stated thesis matches the pattern we track. Agent deployment moves at the pace of what an organization can observe, control, and prove, and safe execution with accountable authority is the constraint Docker is selling to. Mark Cavage called it manufacturing trust.
A Kit is built to be inspectable and reproducible. A versioned artifact that records what an agent may reach is the kind of evidence a governance or audit process needs, and it gives platform and security teams an authoritative record they can inspect and version.
What Docker needs to get right this time
Docker gets this right only by winning enforcement where agents actually run, not on the laptop but on Kubernetes, hyperscaler runtimes, and managed sandbox services such as E2B and Modal. If the Kubernetes Agent Sandbox and the GKE and Red Hat builds enforce Kits natively, the format wins the layer, and Docker holds a place in the control plane; if they do not, Docker owns a developer tool while someone else owns production. That is the Swarm pattern again, with Docker holding the dev experience and Kubernetes holding where the money and the risk live. The spec also has to solve what the container era never faced: an image is self-contained, but a Kit only declares what an agent asks for and the host grants it, so the standard has to carry portable, enforceable authority semantics, grant, deny, revoke, audit, and credential brokering, and interoperate with MCP, agent identity, and the OWASP and NIST governance work, or it just adds one more manifest to an already fragmented layer.
The honest complication is that the layer Docker is reaching for sits much closer to where Kubernetes and the hyperscalers already won than the image format ever did. Winning the format again is achievable and keeps Docker in the conversation, but winning the layer, an actual moat, requires Docker to make its format the enforced standard inside runtimes it does not control, which is a coalition and governance problem more than a product one. That means giving the spec away through CNCF while it still has leverage, getting security, cloud, and CI/CD vendors co-authoring it and passing the conformance suites Docker already ships, rather than lending keynote logos, and keeping the developer default decoupled from Cloud Sandboxes so the runtime is never the toll booth on the format. Last time Docker gave away the format and tried to keep the control layer, and lost the layer to Kubernetes; this time, the format is the Kit, and the layer is enforcement.
Docker’s playbook worked the first time because the container became a shared standard that ran everywhere, and Docker built an ecosystem on top of it. The same condition applies to agent authority. If the Kit becomes a unit, the larger ecosystem packages the same way; Docker owns a layer. If it does not, the Kit stays a Docker feature.
What to Watch:
- Whether the Kit specification reaches neutral CNCF governance or stays under Docker’s control, which decides if the format becomes a portable standard or another vendor-controlled surface.
- How cloud, CI/CD, and IDE vendors respond, since competing agent control plane formats would fragment the packaging layer and push governance and integration debt onto buyers before any format settles.
- Whether enterprises adopt the Kit as an inspectable authority record for governance and audit, or only as a packaging convenience, because the first use is what turns it into a control point.
For more information, see the keynote post on Docker’s website.
Read the full press release on Docker Cloud Sandboxes on the company’s website.
Disclosure: Futurum is a research and advisory firm that engages or has engaged in research, analysis, and advisory services with many technology companies, including those mentioned in this article. The author does not hold any equity positions with any company mentioned in this article.
Analysis and opinions expressed herein are specific to the analyst individually and data and other information that might have been provided for validation, not those of Futurum as a whole.
Other Insights From Futurum:
NVIDIA Wants Agent Safety Enforced in Silicon
Author Information
Mitch Ashley is VP and Practice Lead for the CIO & Technology Buyers and Software Lifecycle Engineering practices at The Futurum Group. A multi-time CIO and CTO with 30+ years leading technical organizations, Mitch built and operated production systems spanning cybersecurity for the U.S. Department of Defense, PKI services for the broadband and 5G industries, SaaS platforms, large-scale telecom and banking systems, and a national broadband network. His work with AI began early, developing expert systems that diagnosed and repaired complex mainframe environments. That operator foundation grounds his analysis in operational consequence, covering the technology buyer's world of software engineering, cybersecurity, DevOps, cloud, and AI.
Vikram Rathnam is Research Director, Software Lifecycle Engineering at The Futurum Group. His research examines how software is built, tested, secured, and operated as AI agents move from assisting developers to doing the work. His coverage includes observability, platform engineering, and the control planes that govern agents. Before joining Futurum, he spent 24 years on the vendor side: ten in engineering at Silicon Labs and fourteen in product and partner strategy, with roles at Cisco, Secureworks, Dell, and CMIT Solutions. Across those roles, he managed B2B cybersecurity, IoT, and AI products, with partner and channel ecosystems as the common thread. At CMIT Solutions, he led product strategy across a franchise network of 180 locations. He reads a vendor’s roadmap as someone who has had to ship one and take it to market.
