Docker Turns Agent Permissions Into a CNCF-Governed OCI Standard

Docker’s own engineers describe the problem in the first person. “I run a lot of agents,” Docker’s Christian Dupuis, a senior principal software engineer, wrote in a blog post published today. “They write code, run tests, install dependencies, call APIs, and work on infrastructure while I do something else. None of it happens without access, so I grant it one piece at a time: a bind mount, a token with broader scope than the task needs, a firewall rule that was quicker to open than to narrow.” Each grant is reasonable on its own. Together, as Dupuis puts it, “they take back the isolation I was relying on, and none needed an exploit. The holes are configuration, added on purpose, usually by me.”

Today at the WeAreDevelopers North America conference, Docker published the Docker Sandbox Kit Specification v3, an open standard, under Apache 2.0, that turns those ad hoc grants into a single, ordinary OCI container image. And in a companion post, Docker said it is handing control of that specification to the Cloud Native Computing Foundation, the same governance move it made with the container image format itself roughly a decade ago.

An Empty Sandbox Still Needs Rules

Docker Sandboxes already solve half the containment problem. A conventional container shares the host kernel and uses namespaces and cgroups to give one fixed workload its own view of the filesystem, network, and processes, which is fine for software that runs, does its job, and touches only what it was handed. An AI agent is different: it decides what to do next and then does it, to a filesystem, a network, credentials, and a cloud account, on its own initiative. A Docker Sandbox addresses that by running the agent inside a microVM with its own kernel, so the isolation boundary sits below anything the model can reach or rewrite.

But, as Dupuis writes, “an empty sandbox is not an environment.” Something still has to say which agent runs there, which tools and MCP servers it gets, which skills and instructions shape it, and exactly what it may touch. A Dockerfile has never answered that question. It describes how software is built, a format that was never itself standardized; OCI standardized only the image a Dockerfile produces and how registries distribute it. Either way, none of that says anything about the outside world: the networks, credentials, volumes, and context an agent needs once it is running. That half of the picture has lived in docker run flags, a Compose file, a CI config, and, as Dupuis puts it, “someone’s memory.” Unversioned. Unreviewable.

A Kit Is Now Just Another OCI Image

Docker’s answer is a “Kit,” a packaging concept that has existed inside Docker Sandboxes since the sbx command-line tool shipped, but is only now standardized as a public specification. The change in version 3 is structural: a Kit is no longer its own artifact type with a bespoke media type and sidecar file. It is an ordinary OCI image. The declarations that describe what an agent may reach live in a single manifest annotation, vnd.docker.sandbox.kit.descriptor, while the layers carry the actual content. That means a Kit builds with docker buildx build, pulls with docker pull, and gets scanned and signed by whatever tooling a team already runs, because to every one of those tools, it just is a container image.

The specification defines two kinds of Kit. A workload runs and supplies the root filesystem, the agent itself. A mixin is an overlay: a CLI tool, a network rule, a credential binding, or context, layered on top. A single sandbox launches exactly one workload and any number of mixins. The specification’s own repository publishes a real GitHub CLI mixin as a worked example. It pins the tool to a specific release, [email protected], and its capability declarations read like this (the file also declares a third capability and metadata fields, omitted here for length):

capabilities:
  - type: com.docker.sandbox/network-policy@2
    config:
      runtime:
        allow:
          # gh reaches release assets and arbitrary repository paths,
          # and no path set narrows that usefully.
          - github.com
          - hosts: [api.github.com]
            methods: [GET, HEAD, POST, PATCH, PUT, DELETE]
          - hosts: [uploads.github.com]
            methods: [POST, PUT]
        deny:
          # Deletes under the repository tree, the repository itself
          # among them, are the one thing the injected token should
          # not reach. Deny wins, so this carves the verb back out.
          - hosts: [api.github.com]
            methods: [DELETE]
            paths: [/repos/**]

  - type: com.docker.sandbox/credential@1
    optional: true
    config:
      service: github
      phase: runtime
      apiKey:
        name: GH_TOKEN
        proxyManaged: true
        inject:
          - {domain: api.github.com, header: Authorization, format: "Bearer %s"}
          - {domain: uploads.github.com, header: Authorization, format: "Bearer %s"}

“Read it as a permission slip,” Dupuis writes. The file’s own comments make an admission most permission systems skip: the mixin’s author acknowledges the network grant could theoretically be scoped tighter, since the sandbox boundary can already read encrypted git-over-HTTPS traffic and tell a clone apart from a push, but left it as a broad host grant anyway because gh legitimately reaches “release assets and arbitrary repository paths, and no path set narrows that usefully.” The honesty is the point: when a Kit cannot scope a request down further, it says so in the file instead of hiding the gap behind a vague allow-all. The deny rule is where the real teeth are. Deletes under /repos/** are blocked outright, so the token that can open a pull request cannot delete the repository, and because deny wins over allow, that carve-out holds no matter how the broader grant is written. The credential entry is proxy-managed too: a conforming runtime injects the real API key into outbound requests to the GitHub-owned domains named in the file, while the sandbox itself only ever sees a placeholder value. Dupuis is careful about the two words doing the most work in his own explanation: “asks” and “conforming.” A Kit grants itself nothing. Each entry in the manifest is a request, and the host, the runtime that opens the Kit, decides whether to honor it.

Composition Is a Graph, Not a Sequence of Flags

Multiple mixins stacked on one workload raise an obvious question: what happens when two of them disagree? The specification resolves that deterministically rather than by whichever order a command line happened to list them in. Mixins declare what they provide and what they require, and the runtime resolves that dependency graph the same way regardless of typed order, so the same set of Kits always composes to the same result. The resolver is strict: every requires has to be satisfied from inside the declared set, or resolution fails outright rather than silently fetching something to cover the gap. Exactly one workload is allowed per sandbox, and two Kits that both try to provide the same named capability fail the build instead of one quietly overriding the other. Network rules union together, hooks run in dependency order, and, per the specification, an incoherent set of requests “fails at your build, not at someone else’s launch.”

The Diff Is the Review, and a Second Gate Behind It

The specification’s most consequential idea is not the OCI packaging. It is what that packaging makes possible for review. Because a Kit’s declared authority lives inside the image, in the same pull request as any other code change, a version bump that asks for a new host or a second credential shows up as added lines in a diff, something a human reviewer can simply refuse. That alone would be an improvement over shell history and dashboards. But the specification does not rely on a human catching every diff. Every descriptor reduces to a normalized set of everything the host would have to grant, and a runtime that gates updates records that set and compares each new version against it automatically. A version that stays inside what was already granted can apply without asking. Any request that widens the granted set stops and asks first, and the specification treats removing a deny rule as a widening too: if a future version of that GitHub mixin quietly dropped the rule blocking deletes under /repos/**, a conforming runtime would hold the upgrade rather than apply it silently.

Handing the Spec to a Neutral Referee

The part of today’s announcement with the most institutional weight is not the format. It is where Docker is sending it. In a second post, Docker’s Eli Aleyner and Srini Sekaran frame the decision as a direct rerun of the company’s own history: “Docker donated its image format and the Runc runtime to the Linux Foundation, and the Open Container Initiative (OCI) formed around them,” they write, adding that Docker is doing “the same kind of answer” for agent permissions now: “one artifact, built on OCI, governed in the open.” Docker’s post describes that original donation as happening “ten years ago.” The Open Container Initiative was actually established in June 2015, closer to eleven years before this announcement, a small rounding in an otherwise accurate parallel.

Chris Aniszczyk, CNCF’s chief technology officer, endorsed the move in a quote included in Docker’s post: “Standards are what let an ecosystem move fast without fragmenting, and few companies understand that better than Docker. By delivering Sandbox Kits as standard OCI images, Docker is giving the industry an open, repeatable way to package an AI agent, its tools, and its guardrails as one artifact. OCI is the foundation the cloud native ecosystem is built on, so a standard for agents that builds on OCI reaches the whole ecosystem at once. The CNCF welcomes this, and we’re excited to work with Docker and the community on making it broadly adopted.” Aniszczyk’s own framing includes an honest limit on the claim: “Docker Sandboxes is the first runtime that enforces it. It should not be the only one, and under CNCF governance, it will not be.” As of today, Docker Sandboxes remains the only conforming runtime that actually exists.

Docker says it built the specification with input from companies across several distinct parts of the ecosystem: AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks, and Snyk, spanning cloud platforms, observability, security, artifact management, content, and agent frameworks. The company frames the Kits unveiled at today’s keynote as the first batch of many, built specifically for those partners’ own tools. The docker/sandbox-kit-spec repository itself is brand new. GitHub’s own record shows it was created on September 16, 2026, just eight days before today’s public announcement, and had accumulated 14 stars and zero forks at the time of writing.

Part of a Bigger Keynote

The specification was one piece of a larger keynote. Docker President Mark Cavage used a 30-minute onstage demo to show what happens when an agent pushes past a plain container’s limits before connecting that to Kits, to Docker’s newly launched Cloud Sandboxes (which extend the same microVM isolation to Docker-managed cloud compute on a pay-as-you-go basis, using the existing sbx workflow to move work from a laptop to the cloud with one command), and to new ecosystem partnerships. Nous Research joined Cavage onstage to run its Hermes agent as what Docker calls a “first-class Kit” inside a Docker Sandbox, a live demonstration of a third-party agent slotting into someone else’s trusted execution layer. sxz.io covered Nous Research’s Hermes Agent earlier this month in the context of the wider agent-harness ecosystem, where its GitHub star count already outpaced more heavily publicized rivals.

The timing lines up with a leadership change Docker made last month. Docker named Mat Velloso as chief product officer on August 18, 2026, after a 15-year career at Microsoft, a stint leading developer growth at Google AI Studio, and time helping shape API strategy for Meta’s next generation of AI models. “Docker has been preparing for this moment since the day it was founded,” Velloso said at the time. “Because we have the stack to securely and seamlessly deploy any agent harness, and then control what it can and cannot do with deterministic policies, Docker can unlock the productivity boost promise of AI agents without giving away control or compromising on security.” A specification for exactly what an agent is allowed to do, expressed as a set of deterministic, machine-checkable policies, is what that quote was describing weeks before it existed as a public standard.

Docker’s Answer to Its Own Warnings

The Kit Specification reads like Docker’s own institutional response to arguments the company has been making in public for months. Docker has previously argued that once an AI agent can take thousands of machine-speed actions, manual review of each individual action stops being possible, so containment has to be engineered rather than checked after the fact. It has also argued that the fix for over-permissive “YOLO mode” agent defaults is an isolated boundary, not fewer approval prompts. The Kit Specification operationalizes both points at once: a portable execution boundary (the sandbox itself) paired with a portable, typed, diffable declaration of exactly what that boundary allows through (the Kit), instead of permissions accumulated one flag at a time and remembered by nobody in particular.

Docker’s own framing extends the idea beyond agents entirely. “Ordinary workloads have always arrived with unwritten expectations: the endpoints they call, the credentials they need, the volume that must survive a restart,” Dupuis writes. “That knowledge has lived in a Helm chart, a runbook, or a colleague.” Agents simply made the gap urgent enough to force into the open first.

An Early, Unproven Standard

Everything about today’s announcement is Docker’s own account, published on its own blog, on the same day the specification, its GitHub repository, and its governance handoff were all disclosed at once. No independent security researcher or competing runtime vendor has weighed in publicly yet, and the repository’s 14 stars reflect a project that is, as of this writing, hours old in the public record. Docker’s parallel to the Open Container Initiative is a genuinely apt one: OCI did become the format every registry and runtime actually implements. But that outcome took years of competing vendors choosing to build against a shared specification instead of their own. Whether “Kit” follows that path, or becomes a well-designed format that only Docker Sandboxes ever fully implements, depends on exactly the kind of adoption CNCF governance is meant to attract and that no announcement, by itself, can guarantee.