Docker and the CNCF will partner on an open spec to make agent permissions portable
Docker Sandbox Kits let you package an AI agent together with exactly what it is allowed to do, so anyone can pull the same agent with the same limits, review changes to those limits, and enforce them. Now, Docker has published the Docker Sandbox Kit Spec, the open specification behind Kits, under Apache 2.0 and is committing to contributing the spec to the Cloud Native Computing Foundation for neutral governance.
A Kit is an ordinary OCI container image that carries three things: the agent, the tools it uses, and a typed list of everything it asks to reach, such as network hosts, credentials, and volumes. That list lives inside the image, so pinning the image pins the agent and its requests together. A Kit builds, pushes, pulls, signs, and scans like any container image, because it is one.
“Standards are what let an ecosystem move fast without fragmenting, and few companies understand that better than Docker. By delivering Sandbox Kits as standard OCI images, Docker is giving the industry an open, repeatable way to package an AI agent, its tools, and its guardrails as one artifact. OCI is the foundation the cloud native ecosystem is built on, so a standard for agents that builds on OCI reaches the whole ecosystem at once. The CNCF welcomes this, and we’re excited to work with Docker and the community on making it broadly adopted.”
Chris Aniszczyk, CTO of the CNCF
Why the OCI image is not enough on its own
An OCI image tells a runtime how to build and start a piece of software. It has no place to state which hosts that software may call, which credentials it may use, or which files it may keep between runs. Those decisions are made outside the image, at launch: in docker run flags, a Compose file, a CI job, an onboarding doc. For a web service, that was fine. The program was fixed, it needed a network and a port, and the flags rarely changed.
Agents are different. Claude Code and Codex decide at runtime what to do: install packages, call APIs, use credentials, change the environment they run in. So the access they need is granted piece by piece, by hand, usually to get a task unblocked. A few months in, nobody can answer a simple question: what is this agent allowed to do? The answer is spread across shell history, dashboards, and someone’s memory, and it cannot be handed to a teammate or compared with last week.
Every team answers that question on its own today, and every runtime vendor could ship its own format for the answer. That is the fragmentation OCI was created to prevent, and it is why Docker is now proposing one artifact, built on OCI, governed in the open by the CNCF community.
How a Sandbox Kit Spec fills the gap
The Sandbox Kit Spec does not fork or replace any OCI specification. It uses the annotation extension point OCI already defines to carry the agent’s requests in the image manifest. Nothing in a registry, scanner, or signing tool needs to change.
Kits began as a feature of Docker Sandboxes, Docker’s product for running agents inside isolated microVMs, where a Kit defined one sandbox: the agent, its tools, and what it could reach. The Sandbox Kit Spec turns that definition into a standard OCI image and opens the format so any runtime can implement it. Docker Sandboxes is the first runtime that enforces it. It should not be the only one, and under Linux Foundation governance it will not be.
Two things follow for anyone running agents. The answer travels with the agent: a teammate can pull it, a reviewer can diff it, and a conforming runtime can enforce it. And when a new version asks for more, the change shows up as added lines someone can refuse.
Kits from across the ecosystem
Kits for tools from AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, and Snyk are available now, covering cloud, observability, security, artifact management platforms and more.
That is what a shared format makes possible. A database vendor can publish a Kit that connects any agent to its service with the scope it recommends. An agent maker can publish its own Kit, so the request list comes from the people who built the agent. A platform team can publish one for the company, and every engineer starts from the same place.
Containers made software portable. Kits make authority portable: the set of things you deliberately hand an agent travels with the agent, in the same image, and means the same thing wherever a conforming runtime opens it. Docker looks forward to formally submitting Kits to the CNCF and working with the community to ensure Kits further the goal of secure, reliable agentic AI and AI governance.
Build a Kit
If you make a tool that agents use, publish a Kit for it. If you run agents, start from one and share it with your team. The Docker Sandbox Kit Spec, its capability pages, and a worked tour of a real Kit are available at docker/sandbox-kit-spec. If there is a Kit you cannot express, or a rule a runtime cannot implement, open an issue.
