Docker Contributes Sandbox Kit Spec to CNCF for AI Agent Permission Management

Standardizing AI Agent Permissions

Docker announced the contribution of its Sandbox Kit Specification to the Cloud Native Computing Foundation (CNCF). The goal of this move is to standardize the packaging and management of permissions for AI agents, making them as portable as the agents themselves. The Apache 2.0 licensed specification, now in version 3, integrates an agent, its tools, and a typed list of requested hosts, credentials, and volumes into a standard OCI image.

Addressing Fragmentation in Agent Access Management

AI agents often require access to system resources, such as installing packages, calling APIs, and using credentials. Currently, these grants (like bind mounts, broad tokens, and firewall rules) are typically managed in disparate locations like shell history or dashboards, rather than in reviewable artifacts. Docker argues that the Sandbox Kit Specification, by leveraging OCI, provides a unified approach to prevent each runtime vendor from developing their own proprietary solutions for managing agent access.

Technical Details of Sandbox Kit v3

In version 3, a Kit is no longer a separate artifact type; it lacks a custom media type and sidecar file. The manifest includes a specific declaration: `vnd.docker.sandbox.kit.descriptor`. This integration means Kits can be built using `docker buildx build`, pulled with `docker pull`, and scanned, signed, or used in `FROM` instructions, ensuring content and permissions are pinned together by the digest. Declarations are typed and versioned capabilities, such as `com.docker.sandbox/network-policy@2` and `com.docker.sandbox/credential@1`. For example, a Kit can allow access to `api.github.com` but deny `DELETE` operations on `/repos/**`, with deny rules taking precedence. Credentials can be proxy-managed, where a conforming runtime injects actual tokens into requests to named domains, while only a sentinel value exists within the sandbox.

Runtime Conformance and Launch Process

A Kit only requests permissions; the host environment determines whether to grant them. Without a conforming runtime, the annotations within the Kit are inert. If a required request cannot be fulfilled, the launch of the agent is refused. Docker Sandboxes, which execute agents in microVMs with their own kernels, is the initial conforming runtime for this specification. The launch process combines a workload Kit, providing the root filesystem, with multiple mixin overlays. Mixins are ordered based on a `provides`/`requires` dependency graph. Resolution fails if a `requires` is unmet or if duplicate names are provided by different Kits. Overlapping declarations are reconciled, with network rules being unioned, and incompatible declarations resulting in errors.

Ensuring Integrity and Conformance

Each descriptor in the specification reduces to a normalized set of grants. Runtimes that manage updates can record this set and prevent any new version that widens the grants, including those that remove a deny rule. Docker states that two conformance suites are provided with the specification: one for Kit artifacts and another for runtimes, to ensure consistent implementation and behavior.