Docker announced it will bring the Sandbox Kit Specification to CNCF, turning permissions of AI agents into a portable artifact. The Apache 2.0 specification, now at v3, packs an agent, its tools and a typed list of requested hosts, credentials and volumes into an ordinary OCI image. The move was announced at WeAreDevelopers on September 24. The point for business is simple: access rights stop living in shell history and dashboards and become a reviewable package.
How Sandbox Kit v3 packages permissions
In v3 a Kit is no longer a separate artifact type, with no custom media type and no sidecar file. Its manifest carries one declaration, vnd. docker. sandbox. kit. descriptor, so it works with familiar operations. A Kit can be built with docker buildx build, pulled with docker pull, and also scanned, signed or used in a FROM instruction. Pinning the digest pins content and permissions together, which simplifies audit and version control.
Permissions are expressed as typed and versioned capabilities, such as com. docker. sandbox/network-policy@2 and com. docker. sandbox/credential@1. The GitHub CLI example in the specification allows api. github. com but denies DELETE on /repos/**, with deny taking precedence. Credentials support proxy management: a conforming runtime injects the real token into requests to named domains, while only a sentinel value exists inside the sandbox. That design keeps secrets out of the agent environment.
The background is fragmentation of agent grants. Agents such as Claude Code and Codex install packages, call APIs and use credentials on behalf of users, while bind mounts, broad tokens and opened firewall rules remain scattered. Docker argues this repeats the problem OCI was created to solve, with each runtime vendor able to invent its own answer. The company draws a parallel to its donation of the image format and runc that led to OCI, and CNCF CTO Chris Aniszczyk welcomed the move as an open and repeatable way to ship an agent with guardrails.
What this means for companies running agents
A launch combines one workload Kit supplying the root filesystem with any number of mixin overlays, ordered by a provides and requires dependency graph rather than flag order. Resolution fails when a requires entry is unmet or two Kits provide the same name, while overlapping declarations reconcile and network rules are unioned. For operating teams this means composable environments with predictable failure instead of silent conflicts, though building correct dependency metadata becomes a new duty.
A Kit only requests permissions, and the host decides the outcome. Without a conforming runtime the annotation is inert, and if a required request cannot be satisfied the launch is refused. Every descriptor reduces to a normalized set of grants, so a runtime that gates updates can record that set and stop any version that widens it, including removal of a deny rule. Two conformance suites ship with the specification, one for Kit artifacts and one for runtimes, which gives buyers concrete questions about enforcement.
The marker to watch is acceptance into a CNCF program and appearance of a second conforming runtime beyond Docker Sandboxes, which runs agents in microVMs with their own kernel. The posts do not state acceptance status or maturity level, and portability across runtimes has not yet been demonstrated. Docker says it built Kits with AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks and Snyk, while examples can be tested with the sbx CLI. Until governance changes, Docker maintains the specification at the docker/sandbox-kit-spec repository.
