Docker Put an Agent’s Permissions Inside the Image It Runs

Docker has made what an AI agent is allowed to touch part of the image it runs, then handed the format to a neutral foundation. The Sandbox Kit Spec packs an agent, its tools, and a typed list of its requests into one Open Container Initiative image. Docker released the spec as open source and brought it to the Cloud Native Computing Foundation, which will govern it. The bet is that authority should travel with the agent.

That is a small sentence with a large consequence. It converts a question every platform team answers in private into an artifact anyone can pull, read and refuse.

Containers never described what software may do

A container image describes how software is built. It says nothing about what the software may do once it runs. For a web service that was fine. It got a network and a port, and that was enough.

Agents are different. They install packages, call APIs and use credentials on the team’s behalf. They change the environment they run in, and they decide what to do next. So each team writes its own rules for what an agent may reach. One network rule here, one token there, one volume mount to finish a task. Those rules end up in shell history, in dashboards, and in someone’s memory. A few months in, nobody can answer a simple question. What is this agent allowed to do?

A Kit answers that in one place. It carries three things in a single image. The agent. The tools the agent runs. And a typed list of everything the agent asks to reach, the hosts, the credentials and the volumes. A build, push, sign and scan all work on it unchanged, because a Kit is an ordinary OCI image. Docker says it uses an extension point OCI already defines, so it is not a new artifact type and not a fork of the spec.

The request list is the part you can review

Because the list sits inside the image, pinning the image pins the agent and its requests together. That is the change that matters for a platform team. A teammate can pull the image. A reviewer can diff it. When a new version asks for more, the extra asks arrive as added lines someone can refuse.

Adoption adds nothing to deploy. Every registry, scanner and signing tool already handles OCI images. Docker built Kits with AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks and Snyk. The company draws the parallel to the Model Context Protocol, which gave agents a standard way to talk to a tool. A Kit publishes the whole arrangement instead, the agent, its tools, and what it asks to reach. The specification and a worked example live in the sandbox kit spec repository.

A standard is only as strong as the runtimes that enforce it

The catch is enforcement. A list of requests helps only if the runtime holding the agent refuses anything outside it. Docker Sandboxes is the first runtime that reads the list that way, and Docker says plainly it should not be the only one. A format owned by the vendor that sells the runtime is worth less than a format governed in the open. That is the reason this went to the foundation rather than staying a product document.

It is the same path the container image took. Docker donated its image format and the runc runtime to the Linux Foundation, and the Open Container Initiative grew around them. The pitch now is that a Kit built anywhere can describe what an agent may do anywhere, provided conforming runtimes keep appearing to read it.

Until they do, treat a Kit as a review surface rather than a cage. It gives you one place to look at what an agent wants, which is more than most teams have today.

Three questions for your own environment. Who approves what an agent may reach, and where is that recorded? If an agent’s request list changed tomorrow, who reads the diff? And which runtime would enforce that list if you shipped it today?

Related reading. Our case for giving every AI agent its own kernel, and why agent state does not belong in etcd.