From Dockerfile to Kit: the Docker Sandboxes Kit Specification

Docker just released the Sandbox Kit Specification v3, and it’s a quiet but meaningful shift in how we can package and deploy AI agents safely. Instead of thinking of sandboxes as temporary, throwaway environments, this spec treats them like first-class artifacts—complete with networking rules, credentials, and storage volumes baked into a standard OCI image. That means you can version, share, and reproduce an entire agent sandbox the same way you’d handle any containerized application.

Here’s how it works technically. Traditionally, when you run a container, you define its isolation rules at runtime through Docker flags or compose configurations. The Sandbox Kit flips this: those rules become part of the image definition itself. You write policies directly into an OCI image specification—things like which outbound ports an agent can reach, what credential stores it accesses, which volumes it can read or write. When someone pulls that image, they’re not just getting code; they’re getting the complete security posture and resource boundaries. This is especially powerful for AI workloads, where an agent might need to call APIs, access databases, or write logs—but only in specific ways.

For teams running AI agents in production, this addresses a real problem. Today, deploying an agent safely means cobbling together documentation about required IAM roles, network policies, and secret mounts. That fragmentation creates security gaps and operational friction. With Sandbox Kit v3, imagine shipping a customer service AI agent as a single OCI image that includes: read-only access to a knowledge base volume, credentials for your company’s support ticket API, network egress only to that specific API endpoint, and logging that streams to CloudWatch. Your DevOps team doesn’t have to reverse-engineer these requirements—they’re auditable and reproducible in the image itself.

The practical payoff compounds across three scenarios. First, for SaaS platforms offering AI agents: you can let customers deploy agents as sealed, verifiable packages without worrying they’ll accidentally misconfigure network access or escalate permissions. Second, for internal teams: you gain reproducibility—running the same sandbox image in dev, staging, and production guarantees identical isolation behavior, not just identical code. Third, for AI model serving platforms: you can enforce different sandbox policies for different model versions without rewriting deployment scripts. This specification is still early, but it’s the kind of infrastructure-level abstraction that tends to become foundational once tooling matures. If you’re building multi-tenant systems or shipping AI agents to production, it’s worth tracking.