Docker has released an open specification for packaging AI agents, their toolchains, and the explicit permissions they require, called the Docker Sandbox Kit Spec. The spec treats a Kit as a standard OCI image, meaning existing registries, scanners, and signing tools can handle it without any new infrastructure.
What changed?
The primary change is the definition of a portable artifact that bundles an agent together with a typed list of the resources it may access (hosts, credentials, volumes, etc.). This list is stored inside the OCI image itself, and the image format is extended via an existing OCI extension point rather than creating a new container type. The specification is open source under Apache 2.0 and is being submitted to the CNCF for neutral governance.
Why it matters to engineers
For AI, cloud, DevOps, and security practitioners the bundled permission list eliminates the current ad‑hoc practice of scattering access rules across shell history, dashboards, and undocumented team knowledge. Because the permissions travel with the image, a single pull provides both the executable agent and its guardrails. This enables:
- Deterministic builds – pinning a Kit image also pins the exact set of allowed accesses.
- Auditable changes – diffing two Kit images shows added or removed permission entries.
- Runtime enforcement – any conforming runtime can read the embedded list and block disallowed actions.
- Reuse of existing tooling – registries, vulnerability scanners, and signing workflows operate unchanged.
Architectural and operational implications
Adopting Kits does not require a new storage layer; they are stored as ordinary OCI images. Build pipelines only need to include the Kit spec files when constructing the image, after which the image can be pushed to any registry. Signing the image with existing tools also signs the permission list, preserving supply‑chain integrity.
Operationally, teams must provision runtimes that understand the Kit format and enforce the embedded permissions. Docker’s own Sandbox runtime already does this, but the CNCF governance model encourages other runtimes to implement support, reducing vendor lock‑in.
From a security perspective, the explicit permission list provides a single source of truth for what an agent can do, simplifying policy reviews and reducing the risk of undocumented credential leakage. However, enforcement is only as strong as the runtime; without a conforming runtime the list remains advisory.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Practitioners should start treating Kits as the default artifact for any AI‑driven automation that requires external resources. Update CI/CD pipelines to build and push Kits using the Docker Sandbox Kit Spec, and integrate diff checks into code‑review processes to surface permission changes. Evaluate existing runtimes for Kit support or plan to adopt a CNCF‑aligned runtime before relying on the spec for enforcement. Finally, monitor CNCF progress on the spec and community‑driven implementations to gauge broader ecosystem adoption.