Docker announced an open specification that standardises how AI agents and their required tools are packaged together with a declaration of the resources they need inside a sandbox. The change matters because it lets teams describe an agent’s required network hosts, credentials, volumes and other capabilities once, and then reuse that description across any sandbox runtime that implements the spec, while keeping the declaration version‑controlled and reviewable.
Open Sandbox Kit Specification for AI Agent Sandboxes
The new format, released under the Apache 2.0 licence, defines a Sandbox Kit as an OCI image that contains either the agent workload or supporting components. Inside the image, a descriptor lists the exact resources the agent expects – network endpoints, secret mounts, volume paths, and similar capabilities. By leveraging existing OCI image tooling, teams can build, store, sign and scan these kits with the same pipelines they already use for containers.
Impact on Build, Sign, and Scan Pipelines
Because the access declaration is baked into the OCI image, any change to the agent’s authority appears as a change to the image itself. Practitioners can pin a kit to a specific image digest, ensuring that the code and its declared permissions move together. CI/CD systems that already verify image signatures or run vulnerability scans can now apply the same checks to Sandbox Kits without additional tooling. If a new version of a kit requests an extra host or credential, the diff is visible in the image metadata, allowing automated gates to block or flag the change for manual review.
Operational Review and Containment Considerations
The specification does not alter the underlying container isolation model; it simply makes the agent’s intended authority explicit. Docker’s demo with Claude showed that an agent can exploit a configuration mistake – mounting the host Docker socket – to reach a secret file. The spec does not prevent such misconfigurations, but it does surface them: the required host socket would be listed in the descriptor, making the risk visible before the kit runs. Runtime implementations that enforce the declared capabilities can therefore stop a kit from accessing resources that were not part of the original declaration.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Adopting the open Sandbox Kit spec means you can:
- Define an AI agent’s environment and permissions once, then reuse the definition across Docker Sandboxes and any future CNCF‑backed runtimes.
- Leverage existing OCI signing and scanning tools to verify both code and declared access in a single step.
- Integrate permission reviews into your change‑management process by treating kit updates like any other image change.
- Watch for CNCF adoption and additional runtime implementations, which will broaden the ecosystem support for the spec.
In the short term, evaluate your current sandbox configurations for implicit permissions such as host socket mounts, and consider converting any ad‑hoc agent deployments into formally described Sandbox Kits. Over the next few months, monitor the CNCF submission process and be prepared to update your runtime policies once other vendors ship compatible implementations.