Docker hands CNCF a spec that makes an agent's permission list part of the image

An engineer who inherits a running agent has one question and nowhere to look up the answer. Docker wrote that the rules each team writes for what its agent may reach "live in shell history, in dashboards, and in someone's memory" ^[15], and that a few months in, nobody can answer what the agent is allowed to do ^[16]. The reason sits in the container model. An image describes how software was built; what it may do once it runs is outside the format ^[13], while agents such as Claude Code and Codex install packages, call APIs and use credentials on a user's behalf ^[14].

The concrete gain is pinning. Because the request list is part of the image, pinning the image pins the agent and its requests together ^[4], and a version that wants a new host or a new credential shows up as added lines someone can refuse ^[8]. That review happens in the same place a team already reviews a dependency bump.

The earlier donation included a runtime. Docker's image format and runc both went to the Linux Foundation, the Open Container Initiative formed around them, and an image built anywhere now runs anywhere ^[12]. This donation is a format for describing requests. Of a Kit's request list, Docker's post says, "A conforming runtime can enforce it" ^[7], and the runtime it names is its own: Kits already exist inside Docker Sandboxes as the way a team packages an agent, its tools and what it may reach ^[9]. A Kit pulled somewhere else stays readable and diffable. Whether anything refuses the credential it asks for depends on that runtime implementing the field.

Kits sit one layer above MCP in Docker's framing, since MCP standardised how an agent talks to a tool and a Kit publishes the whole arrangement in one image anyone can pull ^[17]. Three parties can publish that arrangement, according to the post: a database vendor with the scope it recommends, an agent maker so that the request list comes from the people who built the agent, and a platform team with one Kit every engineer in the company starts from ^[18]. The post does not describe a conformance test, or say whose list wins when a tool vendor's recommended scope and a platform team's company Kit disagree ^[19].

Two things separate the states a team should care about here: whether the agent's request list sits in an artifact you can pin and diff, and whether anything refuses a request at runtime when the list says no. Kits handle the first with tooling already in place, because every registry, scanner and signing tool that handles an OCI image handles a Kit, and Docker says there is nothing new to deploy ^[6]. The second is decided by the runtime. If a Kit asks for a credential and the runtime ignores the field, the team still has a written record of the agent's request list and a reviewer in the pull request.