Docker Brings Sandbox Kit Specification to CNCF to Standardize AI Agent Permissions

Docker announced it is bringing the Sandbox Kit Specification to the CNCF, with the goal of making what an AI agent can access as portable as the agent itself. The announcement took place on September 24 at the WeAreDevelopers event; the spec uses the Apache 2.0 license and is currently at version v3.

To understand the weight of this move, one must first look at the status quo it targets. Agents like Claude Code and Codex install packages, call APIs, and use credentials on users' behalf, and the authorizations that make them truly useful—bind mounts, broad tokens, opened firewall rules—are usually scattered across shell history, consoles, and people's memories rather than existing in an auditable artifact. Docker's argument is that this is exactly the fragmentation OCI was created to prevent; otherwise every runtime vendor might invent its own answer.

Sandbox Kit's response is direct: package an agent, its tools, and a typed manifest of requests (host, credentials, volumes) into an ordinary OCI image. Permissions are no longer a verbal agreement or a console configuration, but part of the image contents.

The most notable design decision in v3 is "subtraction." In v3, a Kit is no longer a standalone artifact type; there is no custom media type and no sidecar file, and the manifest contains only a single declaration, vnd.docker.sandbox.kit.descriptor.

What this trade-off buys is compatibility with the existing toolchain: a Kit can be built with docker buildx build, pulled with docker pull, and also scanned, signed, or used in FROM. More critically, pinning the digest pins both content and permissions—once the image digest is locked, the permission set is locked along with it.

The declarations themselves are typed, versioned capabilities, such as com.docker.sandbox/network-policy@2 and com.docker.sandbox/credential@1. The GitHub CLI example given in the spec shows how rules combine: the Kit allows access to api.github.com but denies DELETE on /repos/**, because deny rules take precedence. Credentials can be proxy-managed—a conforming runtime injects the real token into the specified domain, and only a sentinel value exists inside the sandbox.

The cost is equally clear: the descriptor syntax and per-capability semantics are entirely new and require additional learning. Existing registries, scanners, and signing tools can handle Kits without modification, but people must relearn a way of expressing things.

The most easily misread point in this design is that a Kit only requests permissions; the host decides. Without a conforming runtime, the annotation is inert; if a required request cannot be satisfied, startup is refused.

In other words, the permission manifest written into the image itself constitutes no enforcement whatsoever. It is a portable, signable, auditable declaration of intent, but what turns it into actual isolation is the runtime.

Docker Sandboxes runs agents in a microVM with its own kernel and is the first conforming runtime. This is also the biggest current boundary of the approach: the number of conforming runtimes is only one, and portability across different runtimes has yet to be verified. The "as portable as the agent itself" that the spec promises remains a proposition to be tested until the runtime ecosystem takes shape.

A single launch consists of one workload Kit that provides the root filesystem plus any number of mixin overlays. Mixins are ordered by the provides/requires dependency graph rather than by command-line flag order—the order is determined by dependencies, not by the sequence in which a person types commands.

The resolution rules are hard: if requires is unsatisfied, or two Kits provide content with the same name, resolution fails. Overlapping declarations are reconciled, network rules are unioned, and incompatible declarations produce an error.

More noteworthy is the convergence mechanism: each descriptor is reduced to a normalized grant set. A runtime that controls updates records that set and blocks any version that expands it—including a version that deletes a deny rule. This turns "permissions can only tighten, never quietly loosen" from a convention into an enforceable check.

Two categories of information need to be distinguished. What is confirmed is the state of the spec itself: the Apache 2.0 license, version v3, the September 24 announcement, OCI images carrying permission declarations, and Docker Sandboxes as the first conforming runtime.

Two items belong to Docker's own account and await third-party verification: first, Docker says the spec comes with two conformance test suites, one for Kit artifacts and one for runtimes; second, Docker says it built the Kit together with companies including AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, and Snyk. At the evidentiary level, these two can only be treated as source claims, not as verified facts.

There is also a gap at the governance level: the report does not say whether the spec has been accepted by a CNCF project, nor which maturity level it would enter. Until a governance change occurs, the spec remains maintained by Docker.

In addition, Docker encourages feedback on Kit or runtime responsibilities that currently cannot be expressed, which itself indicates that the spec's capability boundaries may still change.

Sandbox Kit's real contribution is not inventing a new permission model, but demoting permission declarations to a part of an ordinary OCI image, thereby reusing the existing mechanisms for building, pulling, scanning, signing, and digest pinning. This is a pragmatic entry point: it does not require the ecosystem to first accept a new artifact type, only to keep handling images.

But "portable" is currently only half done. Declarations can travel with the image anywhere, yet enforcement takes effect only in a conforming runtime, and there is only one such runtime. Until a second conforming implementation appears and cross-runtime behavior is actually verified, the more accurate positioning of this spec is a well-designed, toolchain-friendly permission expression standard that has not yet been validated by the ecosystem.

For engineering teams, the actionable judgment today is: if you are already using Docker Sandboxes, the Kit offers a realistic path to bring permissions into the image review process; if you depend on other runtimes, the Kit is currently more like a readable intent document than a dependable isolation boundary.