Docker hands the CNCF an open format for governing AI agent permissions
On September 24, 2026, Docker published the Sandbox Kit Specification v3 under Apache 2.0 and moved it under CNCF governance: a Kit becomes an ordinary OCI image carrying the agent, its tools and the typed list of what it may reach. Teams running coding agents should adopt the model to turn implicit grants into a versioned, reviewable artifact.
September 24, 2026. At the WeAreDevelopers conference, Docker announces the Sandbox Kit Specification v3 and hands it to the CNCF. Apache 2.0. That is the license of the format, now open. Ten years ago, Docker made the same move: it donated its image format and the runc runtime to the Linux Foundation, and the OCI formed around them. Why it matters: the problem the OCI solved for containers — one portable format — is back, almost verbatim, for what an agent is allowed to do.
The same problem, ten years on
A container describes immutable software. The image is the application; to change it you rebuild it, and it behaves the same everywhere. That is why an image describes how software is built and says nothing about what it may do once it runs. For a web service that was enough: a network, a port, done.
An agent is the exact opposite. Claude Code and Codex install packages, call APIs and use credentials on your behalf. They change the environment they run in and decide what to do next. So every team writes its own rules for what the agent may reach — a network rule here, a token there, a volume mount to get a task done. Those rules live in shell history, in dashboards, in someone’s memory. A few months in, nobody can answer a simple question: what is this agent allowed to do?
That is the fragmentation the OCI was created to prevent, and the one Docker now wants to stop before it forms around agents.
The Kit: an OCI image, not a new artifact
The answer is a Kit. The concept is not new — Kits have been part of Docker Sandboxes as the way to package an agent, its tools and its reach into something a team can share. What changes in v3 is the artifact itself: a Kit is now an ordinary OCI image.
A Kit carries three things in one image: the agent, its tools, and a typed list of everything it asks to reach — hosts, credentials, volumes. Because that list is part of the image, pinning the image pins the agent and its requests together. The manifest holds the declarations in a single annotation, vnd.docker.sandbox.kit.descriptor; the layers hold the content. It is not a new artifact type and not a fork of any OCI spec: it uses an extension point OCI already defines.
The practical consequence is the decisive one: a Kit builds with docker buildx build, pulls with docker pull, and gets signed and scanned by tooling you already run — because it is an image like any other. “Adoption is free,” Docker puts it: every registry, scanner and signing tool you run already handles it, with nothing new to deploy.
Authority becomes code
Docker’s second post condenses the philosophy into three words: “Authority as Code.” Today, every grant to an agent is reasonable on its own — a read-write bind mount, a token scoped wider than the task, a firewall rule quicker to open than to narrow. Added together, those grants take back the isolation you thought you had — and none of them needed an exploit. The holes are configuration, added on purpose, usually by us.
A Dockerfile says none of that. It answers everything about the software — how it is built, what gets packaged, how it starts — but is silent about the outside: networks, credentials, volumes, tools, context. That half has lived in docker run flags, a Compose file, a CI config, and someone’s memory: unversioned, unreviewable. A Kit writes it down with the content.
The sandbox metaphor completes the picture. A container shares the host kernel; a Docker Sandbox is a microVM with its own kernel, so the boundary sits below anything the model can reach or rewrite. Inside one, you can hand an agent root and let it loose, because the damage stops at the boundary. But an empty sandbox is not an environment: something still has to say which agent runs, which tools it gets, and exactly what it may touch. That is what the Kit writes down.
The CNCF, and the ecosystem that follows
Docker is not keeping the format to itself. As it did with the image a decade ago, the format moves under CNCF’s neutral governance. That is the signal that matters: an agent-permission format is only worth anything if it is portable across runtimes — otherwise every vendor ships its own answer, and fragmentation returns.
The ecosystem has not waited. Docker says it has worked with AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks and Snyk — among others — to build Kits for their tools. Cloud, observability, security, artifact management, agent frameworks: every layer of the toolchain is represented. It is the same dynamic that made the Dockerfile win: anyone can write one, any registry can store the result, any runtime can run it.
For an SRE or a CISO, the promise is concrete. “What can this agent do?” stops being an investigation and becomes a read. A teammate can pull it, a reviewer can diff it, a conforming runtime can enforce it. When a new version asks for more — an extra host, another credential — the change shows up as added lines someone can refuse. Auditing agent security turns from a reconstruction nightmare into an ordinary code review.
What this changes, and what it does not
Keep the scope honest. The Sandbox Kit Spec does not fix a malicious agent or a model that decides to run wild: it makes the boundary you want to impose legible and enforceable. A format does not replace a policy; it materializes it. The distinction matters, because many teams still confuse “I have a sandbox” with “I govern my agents” — when the sandbox is only half the problem, the other half being the permission list itself.
The other limit is adoption. The format is open and free, but its value depends on how many runtimes and tools actually consume it. Snyk, Datadog and Palo Alto Networks in the partner list suggests the movement is underway; it remains to be seen whether competing runtimes — not just Docker Sandboxes — will support it. It is the exact bet the OCI won in 2015, and nothing guarantees the same outcome a second time.
Verdict
Docker’s move is the right one at the right moment: coding agents are leaving the individual sandbox and entering enterprise CI pipelines and cloud accounts, with no shared format for what they may do. If you run coding agents as a team, adopt the Kit’s core idea — the answer travels with the agent — even before your runtime implements it: version and review the list of hosts, credentials and volumes each agent receives, exactly as you do for code. If you already use Docker Sandboxes, migrate your .sbxenv.yaml environments to signed, digest-pinned Kits, and require signature verification on load. If you are evaluating multiple agent runtimes, make Sandbox Kit Spec support a selection criterion: it is the best guarantee available today that you will not rebuild a proprietary permission island you have to rewrite in eighteen months.