Docker Puts Agent Permission Slips Into Ordinary OCI Images
On September 24, 2026, Docker published Sandbox Kit Spec v3 under Apache 2.0 and moved the format toward CNCF governance so an agent, its tools, and what it may reach travel as one signed image.
Docker used WeAreDevelopers on September 24, 2026 to publish the Docker Sandbox Kit Specification v3 as open source under Apache 2.0 and to announce that it is bringing the format to the Cloud Native Computing Foundation for neutral governance. Company posts from Eli Aleyner, Srini Sekaran, and Christian Dupuis frame Kits as the missing half of agent sandboxes: not another proprietary sidecar, but an ordinary OCI image whose manifest annotation vnd.docker.sandbox.kit.descriptor carries a typed list of everything the agent asks to reach—hosts, credentials, volumes, ports, devices—while the layers carry the agent and its tools. Pinning the image digest therefore pins content and authority together.
The problem statement is deliberately familiar to anyone who has lived through container fragmentation. A decade ago, every vendor could have shipped its own image format; OCI won instead. Docker argues agents are recreating that fork. Coding agents install packages, call APIs, and hold credentials on behalf of a developer. Today those grants live in shell history, dashboards, Compose flags, and someone’s memory. A teammate cannot pull “what this agent may do,” a reviewer cannot diff last week’s grants against this week’s, and a runtime cannot enforce a portable contract. Kits answer that with one artifact that builds, pushes, pulls, signs, and scans like any other image because it is one—no new media type and no fork of the OCI specification.
The grammar splits Kits into workloads and mixins. A workload supplies the root filesystem and is the thing that runs; mixins are overlays that add a CLI, a credential binding, network rules, or agent context. Composition is a function of the dependency graph declared through provides and requires, not of flag order, so the same set always resolves the same way. Unsatisfied requirements fail resolution; incompatible requests error rather than silently shadow. A kind: set descriptor can name other Kits and publish them as one ordinary Kit after the same coherence checks. Docker’s companion technical post walks through a GitHub CLI mixin that allows github.com and most of api.github.com, denies DELETE under /repos/**, and injects a proxy-managed GH_TOKEN so the sandbox sees only a sentinel. Read as a permission slip, that is the point: a Kit asks; a conforming runtime grants or refuses.
Enforcement and review are first-class. Docker Sandboxes is described as the first conforming runtime, and the company is explicit that it should not be the only one under CNCF governance. Descriptor changes that widen authority—another host, a second credential, dropping a deny rule—show up as added lines a human can refuse, and runtimes can gate upgrades against a normalized grant set so a silent privilege creep fails closed. Two conformance suites ship with the repository: one judges whether an artifact is a conforming Kit, the other whether a runtime implements the capability pages. The normative grammar lives in docs/spec/SPEC-v3.md, with a BuildKit frontend dispatched by # syntax=docker/sandbox-kit:3, JSON Schema for editor validation, and examples under examples/. The LICENSE file is Copyright 2026 Docker, Inc., Apache License 2.0. The README marks the specification experimental, with a final version targeted for Q4 2026 after community feedback, and capability types version independently (network-policy@1 and @2) so evolution stays additive.
Ecosystem partners named in the announcement include AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, and Snyk—cloud, observability, security, artifact management, and agent frameworks represented in the Kits unveiled at the keynote. That list matters less as marketing than as a test of the thesis: MCP already standardized how an agent talks to a tool; Kits aim to standardize how the industry publishes the whole arrangement—agent, tools, and reachability—in one pullable image. Operators can start from docker/sandbox-kit-spec, install sbx, and run published Kits from Docker Hub’s verified publisher filter, or author local directories without a registry push.
For Writeble’s ai-agents desk, Kit Spec v3 is the rare September standard drop that is both dated and operational. It does not invent a new container format; it reuses OCI’s extension points so registries and scanners already work. Teams that already pin agent images can now pin the permission slip in the same digest, review authority the way they review Dockerfile diffs, and insist that “deny means deny” on any runtime that claims conformance—exactly the portable trust boundary agent fleets have been missing.
- #AI Agents
- #Open Standards
- #Docker
Author
Raj M
Contributor
AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.