DockerJin KimAnnouncement
The Docker Sandbox Kit Specification v3 defines how an agent declares the networks, credentials, and volumes it needs, so these grants travel with the artifact rather than living in shell history or dashboards. A Kit is an ordinary OCI image whose manifest carries a descriptor annotation vnd.docker.sandbox.kit.descriptor, so it builds with docker buildx, pulls with docker pull, and gets scanned and signed by existing tooling. Capability types like network-policy@2 and credential@1 are versioned independently, and each normative statement in the specification is covered by a conformance check or a written waiver. Two Kit types exist: a workload supplies the root filesystem, while a mixin adds overlays such as a CLI with its network rule; the runtime rejects required capabilities it cannot satisfy. Composition uses strict provides/requires resolution, so authority changes appear as diffs, and a conforming runtime can gate upgrades that widen the grant set.
Agents, as probabilistic actors, require access to networks, credentials, and volumes, but these grants are often handed out ad hoc and left unrecorded, creating a trust gap that a sandbox alone cannot close.
The specification defines a Kit as an OCI image whose manifest carries a descriptor annotation listing capabilities such as network policies and credentials, versioned independently. Two Kit types exist: workload (root filesystem) and mixin (overlays). Composition uses strict provides/requires resolution, and authority changes appear as diffs. Conformance suites verify both artifact and runtime behavior, and Docker Sandboxes is the first conforming runtime.
A Kit is built with docker buildx and can be pulled, scanned, and signed like any other container image, reusing standard tooling and distribution.
Capability types in Kit descriptors are versioned independently, so network-policy@1 and network-policy@2 both exist as the specification evolves.
A conforming runtime holds upgrades that widen the grant set, using the normalized descriptor to detect changes such as a removed deny rule.
A Kit is an ordinary OCI image whose manifest carries a descriptor annotation listing the capabilities an agent requires, such as network policies and credentials. It is built with docker buildx and distributed via any registry, making it reproducible and reviewable.
Kits use strict provides/requires resolution to compose. A set of Kits is resolved based on dependency, not the order of flags; conflicts cause build failure. Exactly one workload is allowed, and multiple mixins can be combined.
A conforming runtime implements the behavior the specification describes for each capability type. It blocks hosts not on the allowlist, rejects required capabilities it cannot satisfy, and can gate upgrades that widen grants.
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
Boards of directors turn ownership into a governance control loop: shareholders elect directors, directors set strategy and guardrails, committees verify independently, and management executes inside those limits.
Keep reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.
