Ask a platform team which credentials their coding agent actually held during last Tuesday's CI run. The answer gets assembled out of three places: a runtime flag in a workflow file, two environment variables from a secrets manager, and a network egress rule someone set in a dashboard six months ago. The job went green, the container exited, and the authority that agent carried is now recoverable only by archaeology. Docker's proposal, announced on 24 September 2026 at WeAreDevelopers 2026, puts that authority inside the image. The Docker Sandbox Kit specification makes an OCI image declare what the process inside it may do, and Docker is submitting the spec to the CNCF so the format is not Docker's alone to change.
Two announcements, one argument
The first is a product. Docker Cloud Sandboxes went generally available at docker.com/products/docker-sandboxes, extending Docker's local sandbox isolation into Docker's cloud so an agent keeps working after you close the laptop. It uses microVM isolation, applies the same policies as the local sandbox, boots in hundreds of milliseconds, scales from 1 to 16 vCPUs, is fully managed by Docker, and is built for hours-long unattended runs with workflows that move between local and cloud. Pricing was not disclosed in the announcement. Mark Cavage, President at Docker, framed the reasoning bluntly: "containers weren't designed for the level of isolation AI agents demand".
The second is the part worth arguing about. Docker is taking the Sandbox Kit Specification to the CNCF for neutral governance, comparing the move to donating the image format to the OCI a decade ago. The spec is Apache 2.0. It has been submitted, not accepted, and the difference matters to anyone planning around it.
Take the AI agent isolation claim seriously
Cavage's line reads as marketing but points at something real. A container isolates a process that does a predictable thing, and at build time you know roughly what it reaches, because you wrote the code doing the reaching. An agent inverts that. It decides at runtime what to touch, and the point of running it is that you did not enumerate the steps in advance. So the useful question stops being "what can this process reach" and becomes "what authority did we hand this thing, and can we prove it afterwards". Namespaces and seccomp answer the first question. Neither produces an artifact you can show an auditor.
Which makes the interesting claim one about where permissions live, not how strong the sandbox is. A runtime flag holds authority for one invocation. A dashboard holds it until someone quietly changes it. A digest holds it permanently, and that is what makes agent authority diffable and reviewable in a pull request. The same shift happened when environments moved from a wiki page of click-throughs to Terraform in version control, and the value was never the tooling. It was that changing an environment became a diff someone had to approve.
What a Docker Sandbox Kit actually declares
A Kit is an ordinary OCI image that declares what an agent may do. There are two roles: a workload, which runs and supplies the root filesystem, and mixins, overlays that supply a CLI, credentials, network rules or context. Any launch is exactly one workload plus any number of mixins.
These OCI image permissions ride in the manifest under the annotation vnd.docker.sandbox.kit.descriptor, and that one choice carries most of the practical weight. Pinning the digest pins the content, the declarations and the metadata together, so you cannot run the code you reviewed with permissions somebody widened afterwards. It builds with docker buildx build and pulls with docker pull. Because it is not a new artifact type, existing scanners and signing tools work on it unmodified, which is the difference between a format your DevSecOps pipeline already understands and one you spend a quarter integrating. Capabilities are typed and versioned independently, with @1 and @2 suffixes, so network policy can evolve without a rewrite of every credential declaration.
Reading the capability block
Here is Docker's own GitHub CLI mixin, trimmed:
capabilities:
- type: com.docker.sandbox/network-policy@2
config:
runtime:
allow:
- github.com
- hosts: [api.github.com]
methods: [GET, HEAD, POST, PATCH, PUT, DELETE]
deny:
- 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"}
Two lines do the real work. The deny block revokes DELETE against /repos/** even though the allow block above grants DELETE on the same host. Deny beats allow, always, and that ordering is normative rather than convention. You can hand an agent broad API access and carve out the operations you will not let it find on its own, without an allow list that goes stale the moment the API adds an endpoint.
proxyManaged: true is the other. The real token never sits in the image. The runtime injects it into outbound requests to api.github.com as they are made, so the image carries the credential's shape (name, domain, header format) rather than the secret. An agent that exfiltrates its own environment gets a placeholder. That is the same failure class as the GitLab incoming-email token push-to-main issue: a credential with more reach than the task required.
How agent authority is handled today
Approach | Where the authority lives | Who can change it | What you can audit afterwards |
|---|---|---|---|
Runtime flags on the invocation | One command line, one run | Anyone who can edit the job or type the command | Shell history and CI logs, if retained and if the flags were not built from variables |
Environment variables from a secrets store | Injection config plus the store's policy | Platform team, plus anyone with write access to the store | That a secret was fetched, not what the agent did with it |
Dashboard toggles and org policy | Vendor console | Console admins | A change log nobody reviews, rarely tied to a specific run |
Ad hoc personal access tokens | Scopes set once at creation | The token's creator | Token scopes, if the token is still identifiable. Usually shared and long-lived |
A Docker Sandbox Kit | The image manifest, under a digest | Whoever can merge a change to the image | The declared permission set for that digest, reviewable as a diff before it ran |
The right-hand column is the argument. Every row but the last tells you only that a secret existed. The last one tells you what the agent was allowed to do.
Resolution, updates and conformance
Mixins are ordered by a dependency graph built from provides and requires, not by the order you typed them. Resolution is strict: every requirement must be satisfied or the launch fails, exactly one workload is allowed, and incompatible requests error instead of one mixin silently overriding another.
Declarations reduce to a normalised set of granted permissions, so a runtime can compare one version against another. Updates that stay inside the authority you already granted apply automatically. Anything that widens the grant needs approval, and removing a deny rule counts as widening. That last detail will catch implementers out, and it is the correct call.
The spec ships a normative grammar and two conformance suites: one checks whether an artifact is a conforming Kit, one checks whether a runtime behaves as specified. Docker Sandboxes is the first conforming runtime, installed with brew install docker/tap/sbx:
sbx run ./hello --kit ./gh .
Collaborators named by Docker include AWS, Palo Alto Networks, Snyk, Datadog, Dynatrace, Box and JFrog, plus the agent frameworks NanoClaw and OpenClaw.
What is unproven
A specification is only as good as its enforcement, and today there is exactly one conforming runtime, written by the company that wrote the spec. The conformance suites are the right hedge, but a suite only one implementation has ever passed is not yet a portability guarantee. Neutral governance has been submitted, not granted.
The governing principle, that Kits ask for permissions and hosts decide what to grant, cuts both ways. The security property depends entirely on the host being strict. A permissive host that grants whatever a Kit requests turns the mechanism into documentation, which is a different product from the one being pitched.
MicroVM isolation inside Docker's cloud is a vendor boundary, with what that implies for data residency and incident response, and the pricing is undisclosed. That matters when the pitch is hours-long unattended runs. An agent that ran for six hours because nobody stopped it is a cost story before it is a security story.
Nor does any of this stop an agent misusing authority it was legitimately granted. A Docker Sandbox Kit is a scoping and auditing mechanism, not behaviour control. An agent with POST access to your issue tracker can still write nonsense into three hundred issues, and the Kit will faithfully record that it was allowed to.
A signed, pinned image that declares its own authority answers the same class of problem as malicious providers in the Terraform registry: you pulled something and could not say in advance what it would reach for. The caveat is identical. A signature proves origin, not intent, and a declared permission set narrows what a hostile artifact can do without telling you it is benign.
Should you care yet
If you are already running agents against real credentials in CI, meaning tokens that can merge, deploy or spend, build a Kit for one of those workflows this month. The value arrives before the ecosystem does, because writing the declaration forces you to enumerate authority you currently grant implicitly. Teams usually find their agent holds push access it has never used.
Everyone else should wait for a second conforming runtime. Until something other than Docker Sandboxes passes the runtime suite, adopting the format is a bet on one vendor's implementation with a spec attached: fine for a team with an acute problem, poor for a team building a standard into a platform others depend on. The same patience applies to Docker Cloud Sandboxes, since undisclosed pricing on long unattended runs is hard to design around. Our notes on restoring GPU state instead of reloading it and the rest of our AI infrastructure coverage take up the same cost question.
What to watch
Four signals tell you whether this becomes infrastructure or stays a product feature.
Whether this becomes an accepted CNCF specification, and at what level. The governance terms will say more than the announcement did.
A second conforming runtime from someone other than Docker. Strongest signal on the list, and until it exists the portability claim is untested.
Whether strict host-side policy tooling appears. The format needs hosts that reject over-broad requests by default, because a permissive host is the failure mode that makes all of this decorative.
Whether the scanner vendors surface capability declarations in their output. If Snyk and JFrog show you the granted permission set next to CVEs, the format is real. If they do not, the annotation is a string nobody reads.
