Clarion Street

Portable Authority: How OCI Kits Turn Agent Permissions Into a Supply-Chain Artifact

·9 min read

On September 24, at the WeAreDevelopers conference, Docker published version 3 of its Sandbox Kit Specification, released it under Apache 2.0, and committed to contributing it to the Cloud Native Computing Foundation. The company is not subtle about which moment it thinks it is repeating. In 2015 Docker donated its image format and the runc runtime to the Linux Foundation, the Open Container Initiative formed around them, and a Docker image built anywhere running anywhere became the assumption the industry builds on. Docker’s argument now is that agent permissions sit where container images sat in 2015: fragmented, undocumented, and held together by habit.

The specific mess is familiar to anyone who has watched an agent work. Claude Code and Codex install packages, call APIs, and spend credentials on the user’s behalf. Every team that runs one ends up inventing its own rules for what the agent may touch, and those rules, in Docker’s phrasing, live in shell history, in dashboards, and in someone’s memory. There is no shared format for them and no artifact you can pin, sign, or review.

Docker’s answer is the Kit.

What a Kit actually is

Kits are not new. They have shipped inside Docker Sandboxes, the company’s microVM product for running coding agents, as a way to bundle an agent, its tools, and its reach into one unit. What version 3 changes is the artifact. A Kit is now an ordinary OCI image instead of a proprietary format, and it carries three things: the agent, its tools, and a typed list of everything the agent asks to reach. Hosts, credentials, volumes. The list travels in a single manifest annotation, vnd.docker.sandbox.kit.descriptor, with the content in the image layers, so a Kit builds, pushes, pulls, signs, and scans like any other image, with nothing new to deploy in the registry or the scanner.

Because the request list lives inside the image, pinning the image pins the agent and its requests together. What the agent may do stops being a reconstruction and becomes a value with one answer, one that a teammate can pull, a reviewer can diff, and a conforming runtime can enforce.

What a Kit is not

I want to be careful about the distinction, because the easy misreading is to treat a Kit as another capability-packaging standard. We covered the Agent Skills standard here in September: a skill packages what an agent can do, the instructions, scripts, and reference material (The Skill Standard). A Kit packages what an agent may reach, the hosts, credentials, and volumes. Those are different questions. Confusing them is how a reader walks away thinking Docker shipped another skills format. They compose rather than compete. Docker’s spec repo ships skills/ directories inside Kits, so a Kit can wrap a skill and add the permission list on top.

How enforcement works

The mechanics matter, because a format that only documents intent is a comment rather than a control. Docker is careful on this point. A Kit grants itself nothing. Every entry is a request the host decides whether to honor, and only a conforming runtime blocks hosts that are not on the list. Without one, the annotation is inert. Docker Sandboxes is the first conforming runtime, and the spec ships two conformance suites, one judging artifacts and one judging runtimes.

Credentials go through a proxy rather than sitting in the sandbox. A conforming runtime injects the real value into requests to named domains and leaves only a sentinel inside, so a token that can open a pull request cannot delete the repository. On overlapping rules, deny wins. Composition is a function, not a sequence. Mixins are ordered by a dependency graph through provides and requires, strict resolution fails on any unsatisfied requires, exactly one workload is allowed, and duplicate providers fail rather than silently shadowing each other.

Two kinds of Kit exist. A workload supplies the root filesystem. A mixin is an overlay carrying a CLI, its network rule, a credential binding, or agent context. You launch one workload plus any number of mixins.

The boundary and the list

Docker also draws the line between a container and an agent, and the line matters. A container packages immutable software. An agent is, in Docker’s phrasing, “a probabilistic actor” that changes its environment as it works, so it needs two things at once: a microVM boundary and a written permission list. We have covered the boundary half on this site, both the kernel-level enforcement (Beyond the Sandbox) and the isolation model (Caging the Agents). The Kit is the other half, the written permission list, and that is the part that has been missing a format.

The diff is the review

The claim I take most seriously is the one Docker compresses into a slogan: the diff is the review. A new host or credential in a new version of a Kit is a change in authority, not a software update, and it shows up as added lines a human can refuse. The spec also defines a machine gate on top of the human one. A runtime reduces each descriptor to a normalized grant set and holds upgrades that widen it, including the removal of a deny rule. That maps onto something we have argued here before, that authorization belongs outside the agent’s own loop rather than in the model’s judgment (Certifying the Loop). A Kit is a concrete place to put that policy, versioned and reviewable.

The supply-chain story

For a security team that already audits container images, the shape of this should feel like an extension rather than a new discipline. The permission list becomes a pinnable, signable, diffable artifact. Docker’s docs already wire in the standard tooling. sbx supports cosign and Sigstore signatures with a keyless default, kit.requireSignature rejects unsigned kits, and kit.allowedSources restricts which publishers’ kits may install, with install commands running as root inside the sandbox. That last detail deserves a pause, because it means the signing gate and the publisher allowlist are carrying a lot of the security weight, and the gaps in what gets signed matter more than they otherwise would.

The ecosystem and the MCP comparison

The ecosystem part of the announcement is short and easy to over-read. Partners named as having built Kits include AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, and Snyk. CNCF CTO Chris Aniszczyk described the move as giving the industry an open, repeatable way to package an AI agent, its tools, and its guardrails as one artifact. The framing that stuck with me is the MCP comparison: MCP gave agents a standard way to talk to a tool, and Kits give the ecosystem a standard way to publish the whole arrangement. That positions Kits as the complement to MCP rather than a replacement, and it extends a line of thinking we have tracked in the MCP governance coverage (The Rise of MCP Governance).

The threat model landed the same week

The timing is not an accident. The same week supplied the threat model. On September 24 Darktrace published research on what it calls an agent hijack. Agentic harnesses store conversation history client-side without checking that stored responses were actually produced by the model. An attacker who poisons that history can convince a frontier model it is an authorized red-teamer, and Darktrace confirmed the pattern across Claude Code, AWS Kiro-CLI, OpenAI Codex, and the open-source Pi. In one lab run, 78 fabricated turns of prior exploitation flipped a refusal into immediate execution and produced full Active Directory compromise inside a sandboxed lab. Darktrace’s proposed fixes are mostly provider-side, cryptographically signing responses and verifying them server-side, and it says plainly that defenders cannot deploy the signing fix themselves. What remains for defenders is behavioral monitoring.

On the endpoint side, the same problem is already productizing. Keeper extended its Endpoint Privilege Manager to evaluate agent actions at the operating system level, regardless of whether they arrive through MCP, a direct API, or a local tool, and it applies identity, approval, and audit policy to agents as principals. Keeper’s CEO Darren Guccione put it as, AI agents are not assistants, they are principals. That is the one-sentence version of a point worth sitting with.

What the format does not do

The caveats matter here, because the announcement invites more credit than the artifact has earned yet.

A Kit does not fix a malicious agent or a model that decides to run wild. The independent analysis from ETTAYEB puts it cleanly: the spec makes the boundary you want to impose legible and enforceable, and a format does not replace a policy, it materializes it. I read that as the honest version of the pitch. A Kit is a request, not a grant, and it does nothing without a conforming runtime.

The governance story is also still in progress. Docker maintains the spec today and says it should not stay under a single vendor, but the CNCF handoff is a commitment, not a completed transfer. Committed to contributing is the right verb. Docker Sandboxes is currently the only conforming runtime, and the whole bet is adoption. ETTAYEB calls it the exact bet the OCI won in 2015, with nothing guaranteeing the same outcome a second time.

The signing coverage has holes I should name. The signature covers spec.yaml and files/ but not mutable dependencies, meaning image tags and anything an install or startup command downloads. ZIP-form Kits cannot carry verifiable signatures at all. The supply-chain story is real but narrower than the slogan suggests. The permission list itself is signable and pinnable. Where kit.requireSignature is true, sbx rejects unsigned or untrusted kits, but that flag does not pin anything. Mutable dependencies need their own digest or checksum pin, and the signature never reaches them.

Bottom line

Docker’s parallel is not subtle. Containers standardized how software is built and shipped. Kits standardize what the shipped thing may do once it runs. For a team already running registries, scanners, and cosign, a Kit extends that exact pipeline to agent authority, turning the permission list from a reconstruction into an artifact. The claim I would defend is smaller and more durable than the marketing. A Kit does not make agents safe. It makes the permission boundary into something you can see, pin, sign, diff, and refuse. That is the same modest thing the Skill standard did for capability, and it matters for the same reason. Governance needs an artifact to point at.

Sources

  1. Hijacking Agentic Harnesses to Attack an Organization — Darktrace
  2. Keeper Security Extends Agentic AI Governance to Endpoint Privilege Manager — Tech Partner News
  3. Docker Brings Sandbox Kit Spec to the CNCF — Docker blog
  4. From Dockerfile to Kit: the Docker Sandboxes Kit Specification — Docker blog
  5. docker/sandbox-kit-spec — GitHub
  6. Docker Launches Cloud Sandboxes — Docker press release
  7. Docker Commits to Bringing the Sandbox Kit Spec to the CNCF — Linux.com
  8. Docker docs: Kits — Docker documentation
  9. Docker hands the CNCF an open format for governing AI agent permissions — ETTAYEB