Docker's Kit spec v3 writes an AI agent's access into an ordinary OCI image

A firewall rule gets opened because opening it was quicker than narrowing it. The author of Docker's announcement post lists that among the grants they give their own agents, beside a bind mount and a token with broader scope than the task needs ^[8]. "The holes are configuration, added on purpose, usually by me," the author wrote ^[9].

What teams tell themselves is that the sandbox is the control. A Docker Sandbox is a microVM with its own kernel, and the post argues that puts the boundary below anything the model can reach or rewrite ^[7]. What users do, by the author's own account, is widen that boundary one request at a time and lose the record of it. "No file records them. They live in shell history, dashboards, and my memory. I cannot hand that to a colleague or diff it against last week," the author wrote ^[10].

The spec goes after the record. A Dockerfile describes the software, and the post says the outside of it (networks, credentials, volumes, tools, context) has lived in docker run flags, Compose files, CI configs and someone's memory ^[13]. The Kit puts those declarations in one manifest annotation, vnd.docker.sandbox.kit.descriptor, while the image layers carry the content ^[3]. Pinning the digest pins both ^[5].

This is for the second person: the colleague who inherits an agent, or the reviewer who signs off on what it can reach. Distribution asks nothing new of them. Kits build with docker buildx build, pull with docker pull, and get scanned and signed by tooling teams already run ^[4]. The format itself has a cost. "The tooling and distribution path are free; the format is something you learn," the author wrote, and the list runs to a grammar, a page per capability type, provides and requires, and kind: set ^[12].

A declared grant is as broad as its author made it. In the post's GitHub CLI mixin, the allow rule for api.github.com lists six methods, DELETE among them, and the deny rule removes DELETE only for paths under /repos/** ^[11][16]. A reviewer can now see that choice in a diff. Whether DELETE should stay open anywhere else on that API is still the reviewer's call.

The post says a Kit means the same thing on any conforming runtime ^[14]. It does not name a conforming runtime other than Docker's own, and it includes no adoption figures.

I'd move an agent's grants into a Kit whenever someone other than the person who granted them will have to answer for them. The tradeoff is learning another capability page for each grant type in use. For the rest, two axes sort the agents a team runs: whether the grants sit in the image digest, and whether the agent runs in a microVM or in a container on the host kernel. Declared grants in a microVM are the case the spec was written for. Declared grants in a container give a reviewable record over what the post calls "the same kernel the actor is probing" ^[15]. An undeclared microVM keeps damage inside the sandbox boundary ^[7] but cannot be rebuilt on a colleague's laptop. The last box, undeclared and in a container, is where the author says their own grants lived: shell history, dashboards and memory ^[10].