Docker's Sandbox Kit Spec puts Agent Permissions inside the container image

TL:DR Docker released version 3 of the Sandbox Kit Spec, moving agent permissions directly inside OCI images to bridge the agentic container gap and standardize agent governance. Supported by industry leaders and AAIF members, the spec enables versioned, verifiable security controls and auto-approval of non-escalating update permissions.

As agentic AI matures, the main questions are shifting from what agents can do to what we allow them to do and how we structure the environment they run in. Docker recently published version 3 of the Docker Sandbox Kit Spec under the Apache 2.0 license at docker/sandbox-kit-spec. The spec defines a standard way to declare what an agent is allowed to access, and it could become a basic part of how teams govern agents. Docker is an Agentic AI Foundation (AAIF) Gold member, and we like to highlight work from our members that takes on open problems in agentic AI.

The agentic container gap

An OCI image records an application's content and launch configuration, but it has no field for what the application may access once it runs. Whatever launches the image sets that access, e.g., docker run flags, a Compose file, a Kubernetes network policy, or a sandbox tool's own configuration. None of those are stored in the image, so pinning an image digest does not pin the access that goes with it. For a web service that does the same thing on every run, the gap causes little trouble. For an agent, which decides at runtime what to install, call, and use, the gap means the most important security information about the agent is kept apart from the agent itself. We call that the agentic container gap.

An agent's access list is its main security control. Keeping the list outside the image means a team can't sign, version, or review it together with the agent, and a different runtime can't read it. Docker's earlier Kit formats described agent permissions in a file distributed separately from the agent's image. Version 3 moves the permissions into the image itself and publishes the format as an open specification.

The problems the spec addresses are ones AAIF's working groups are already working on. Security & Privacy is studying how to contain agents that act on their own. Identity & Trust is asking how an agent can use a credential without ever seeing it. Governance, Risk & Regulatory Alignment needs agent permissions that can be versioned, reviewed, and audited. Observability & Traceability needs a record of how an agent's authority changes from one release to the next. A signed permission list that can be compared line by line is useful to all four groups.

How a Kit works

A Kit is an ordinary OCI image. A single manifest annotation holds the Kit's declarations, and the layers hold the content, so existing registries, scanners, and signing tools handle Kits without changes. A workload Kit supplies the agent's filesystem, and mixin Kits add tools or credentials on top of it.

Each declaration is a typed, versioned request for something such as a network host, a credential, a volume, or a port. The Kit grants itself nothing. The host approves or refuses each request, and a required request that can't be met stops the launch. Network rules can name HTTP methods and paths, and deny rules override allow rules, so Docker's GitHub example lets an agent open pull requests but blocks it from deleting repositories. Credentials can be held by a proxy outside the sandbox, so the agent sees only a placeholder value.

When Kits are combined, the runtime checks that every requirement is met by a Kit in the chosen set. It also fails if two Kits provide the same component, instead of silently letting one replace the other.

Changes in access are caught at update time

The spec reduces each Kit to a list of everything the host must grant. A runtime that gates updates compares each new version against the list it already approved. A version that stays within the approved list can apply without asking. A version that asks for more, including one that removes a deny rule, must stop for approval.

Status and available Kits

The spec ships with two conformance suites, one for Kits and one for runtimes. Docker Sandboxes is the first conforming runtime, and Docker's documentation labels Kits as Early Access. Docker has committed to submitting the spec to the Cloud Native Computing Foundation.

Docker worked with AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, and Snyk on Kits for their tools, and Snyk is demonstrating its Evo Agentic Development Security Sandbox Kit this week. Nous Research joined Docker onstage at WeAreDevelopers for a live demo of its Hermes agent running as a Kit in Docker Sandboxes, and a Hermes Kit is available in Docker's community repository, which holds more Kits in the earlier v2 format. The spec repository includes a Claude Code Kit as a worked example.

Docker, AWS, and Datadog are all AAIF members, and the Kits they built together show members collaborating on a shared format rather than each shipping its own. AAIF's future depends on members building new answers to open problems in agentic AI and working together to make those answers common ground, and the Sandbox Kit Spec is an example of both.

Continue the conversation in San Jose. AGNTCon + MCPCon North America takes place October 22 and 23 at the San Jose McEnery Convention Center. It brings together the people building, securing, and governing agents in production. If you are working on agent sandboxing, permissions, or the security of the agent supply chain, come compare notes with our working group members and with the teams building Kits. Standard registration ends October 7. Register here.