Evidence note: everything attributed to Docker in this article comes from Docker’s own blog posts and product pages. Those are primary sources — the company is the authority on what it announced and shipped — but they are not independent corroboration, and no third-party testing, benchmark, or security audit of Sandboxes, Cloud Sandboxes, or the Sandbox Kit Specification is cited here because none was available. Figures labelled as playagit’s own records come from this site’s production pipeline ledger; they are first-party measurements of a different system entirely, used here as a point of comparison, never as verification of Docker’s claims.
The keynote: isolation and reproducible authority as one story
At WeAreDevelopers, Docker presented three things together — Sandboxes, Kits, and Cloud Sandboxes — and framed them as the means of giving AI agents strong isolation and reproducible authority (Docker’s own keynote recap; company announcement, not independently corroborated). The framing matters more than any one product in it. "Isolation" is the old container pitch. "Reproducible authority" is new, and it is a claim about permissions: that what an agent is allowed to touch can be fixed, shipped, and re-created the same way twice.
Docker also ran a Docker Pavilion at the event, hosting partner and customer sessions on AI, security, and development (Docker’s own session listing; company announcement).
A Sandbox is a disposable microVM, and it shipped before the keynote
Docker describes Sandboxes as disposable, isolated environments for AI agents — microVM environments in which coding agents can work autonomously in a safe way (Docker’s product page; vendor description, not independently tested). Docker launched Sandboxes earlier in the year, before Cloud Sandboxes arrived (Docker’s own announcement; company statement).
The sequencing is worth noting because it tells you what the keynote was actually for. The runtime already existed. What was added was reach and a specification.
Cloud Sandboxes: the same agent, laptop or cloud, one command
Docker introduced Cloud Sandboxes at WeAreDevelopers: agents run on a laptop or in the cloud and move between the two with a single command (Docker’s launch post, event recap; both company announcements, not independently verified). No public third-party measurement of migration latency, cost, or state fidelity across that move is available, and Docker’s posts do not publish those numbers.
What the Sandbox Kit Specification packages
Docker introduced an open Sandbox Kit specification at the same event (Docker’s own post; company announcement). According to Docker, the specification packages an AI agent’s network rules, credentials, and volumes as an ordinary, pinnable OCI image, and is built on OCI precisely so that agent permissions become a neutral standard rather than one vendor’s format (Docker’s own post; company statement, not independently corroborated).
That design choice is the interesting part. OCI images already have registries, digests, signatures, and tag-pinning. Expressing a permission set as one of those artifacts means a permission set gets a content-addressable identity for free: the same digest, the same declared authority. It also means a permission set inherits every operational habit the industry has around images, including the bad ones — floating tags, stale pins, and images that nobody can say who built.
The reproducibility claim, examined
Docker’s case is that Sandboxes can make AI evaluation workflows more reproducible through consistent execution, structured artifacts, and runtime evidence (Docker’s own post on reproducible evaluation workflows; company claim, no independent benchmark available).
Read the three terms precisely, because they are not equivalent. Consistent execution is about the environment: same image, same kernel boundary, same filesystem. Structured artifacts are about output format: results that a later process can parse instead of a human re-reading a log. Runtime evidence is about what was observed while the thing ran. All three are real properties, and all three are upstream of the question most evaluation work actually fails on, which is whether the thing being evaluated was right.
What playagit’s own continuous pipeline counted instead
This site runs a continuous content pipeline with its own quality gate, and its ledger counts a different kind of failure. In playagit’s own pipeline runs (161 runs, 28 August to 3 October 2026, as of 3 October 2026), the quality gate reviewed 1,217 drafts: 998 published, 135 sent back to revise, and 84 rejected — a 82.0% publish rate, with 18.0% stopped or returned (own measurement, n=161 runs; not independent verification). Over the same window the ledger records 1,049 posts published, of which 321 were new and 284 updated (same records, same window) — the gate counter and the publishing counter track different objects, so the two totals are not meant to reconcile, and that gap is a derived observation rather than a recorded metric.
The pipeline’s execution environment is stable across all 161 of those runs. Same code, same model routing, same gate. Execution reproducibility was never the thing that sent 219 drafts back or out. Earlier work on this site reached the same conclusion from a smaller sample — see the account of what 23 pipeline runs taught about defining "correct", where verification, not execution, was the bottleneck.
Where this site’s record says reproducibility actually breaks
The sharper number is in the research layer. In playagit’s own pipeline runs (161 runs, 28 August to 3 October 2026), across 4,841 research dossiers holding 27,111 claims, 5,948 were primary-attested and 1,529 were independently cross-checked (own measurement; not independent verification of anything but itself).
As shares: 21.9% of claims had a primary source behind them, and 5.6% survived independent cross-checking (derived from the figures above). Roughly 5.6 claims per dossier on average (derived). Nothing about a microVM changes those ratios. A sandbox can guarantee that the same fetch, the same parse, and the same scoring pass run identically on every host. It cannot make a second, independent source exist for a claim that only one party has ever stated.
That is the division this announcement sits on. Docker’s three terms — consistent execution, structured artifacts, runtime evidence — all describe the run. The 5.6% figure describes the world the run was reading about. A reproducible run over a single-sourced claim reproduces the claim, including its weakness.
The number inside the specification: version 3
Docker states that the Sandbox Kit Specification is at version 3 (Docker’s own posts; company statement, not independently corroborated).
A specification arriving in public at version 3 is a disclosure in itself: the permission model it encodes has been through at least two prior shapes. Docker’s available posts do not detail what changed between versions 1, 2, and 3, and sources do not confirm whether earlier versions were ever published, used in production, or only internal. Whether version 3 artifacts remain readable by tooling built for earlier versions is likewise not addressed in the material available.
Pinning a permission model that is still moving
Docker committed to bringing the Sandbox Kit Spec to the CNCF for neutral, vendor-independent governance (Docker’s own announcement; company commitment). A commitment is not a completed donation, and the available sources do not state a timeline, a target project stage, or which CNCF process the specification would enter.
Here is the tension a developer inherits. Pinning is only as good as the stability of what it points at. An OCI digest makes a permission set exactly reproducible; it does not make it exactly interpretable three spec versions later. A pinned version-3 Kit is a frozen declaration of authority evaluated by a runtime that will keep moving.
Neutral governance at a foundation would plausibly help with one half of that: a vendor-independent body is the normal mechanism for versioning discipline, deprecation policy, and multiple competing implementations of the same format. What it would not settle is whether the permission vocabulary is the right one — whether network rules, credentials, and volumes are a sufficient description of what an autonomous agent can do. Governance decides who controls a schema. It does not decide whether the schema covers the risks. No public analysis of that coverage question was available at the time of writing.
Developer takeaway: reproducible execution is not reproducible evidence
If the work is "run this agent the same way on any machine, and prove what it touched," the Sandboxes and Kits story addresses it directly, on Docker’s own account of the design. Treat the Kit image like any other pinned dependency: record the digest, track the spec version it was authored against, and expect to re-author it when the spec moves.
If the work is "trust what the agent concluded," the sandbox is the wrong layer. In playagit’s own pipeline runs (161 runs, 28 August to 3 October 2026), of 35,450 scored topics, 15,379 were rejected, 13,816 were held before production, and 6,255 went to production — 17.6% reaching production (own measurement, derived share; not independent verification). Upstream of that, 30,001 topic candidates were discovered across 4 categories from 223 distinct source hosts (same records).
That filtering is all judgement about content, not environment. It is the same shape of problem that shows up when an agent is left to assess its own output — see what 303 agent runs across three Roblox games did and did not record. The practical rule: budget separately for the two. Sandboxing is an infrastructure line item and it is now close to solved-looking. Evidence quality is an editorial or review line item, and nothing announced at this keynote touches it. The broader pattern — evaluation harnesses growing faster than the code they check — was visible across this week’s agentic delivery tools too.
A test not yet run
The obvious experiment has not been performed and nothing in this article should be read as having tested it: take this site’s own pipeline — the same 161-run configuration that produced the figures above — package its network rules, credentials, and volumes as a Sandbox Kit, and execute a fixed batch of topic candidates inside a Cloud Sandbox against the identical batch run on the existing host.
The measurements worth taking would be: per-run wall-clock and cost difference; whether the published, sent-back, and rejected split shifts at all; whether the primary-attested and cross-checked ratios move by more than run-to-run noise; and whether the laptop-to-cloud move preserves the ledger state that the current counters depend on. The honest prediction, from this site’s own records rather than from any test, is that the first two numbers move and the third does not — but that is a hypothesis, and until the batch is run it stays one. The prior pipeline write-up, how 7,436 topic candidates became 75 published posts, documents the baseline such a comparison would have to beat.