AI agents are getting good at probing the boundaries developers put around them. Their ability to improvise makes them hard to contain.
“You ask for something in a very high-level, vague-at-best way. You walk away, and you come back to a remarkable pile of mostly working software. But you then realize that you gave a probabilistic machine access to your life and your systems,” said Docker President and COO Mark Cavage, speaking to the crowd at the opening session of the WeAreDevelopers North America conference in San Jose Thursday.
During his keynote, Cavage unveiled a new specification for packaging an AI agent and its tools together with a declaration of the access it requests from a sandbox. He also announced that Docker plans to contribute the new specification to the Cloud Native Computing Foundation.
A Common Format for Agent Sandboxes
Published under the Apache 2.0 license, the specification is meant to give developers and sandbox providers a common format they can use across different sandbox runtimes. The goal is to let developers define an agent environment once rather than recreate its configuration and access requirements for each sandbox platform.
In Docker’s model, a Sandbox Kit packages either an agent workload or supporting components for use inside a sandbox. Under the new format, those Kits are packaged as OCI images, with descriptors listing the network hosts, credentials, volumes and other capabilities they request. Docker says using existing OCI mechanisms lets teams build, store, sign and scan Kits with the same tools they already use for containers.
Docker already offered Sandbox Kits through Docker Sandboxes, but the new open specification is for implementation by runtimes outside Docker’s own. Cavage said the planned CNCF contribution will be formally submitted later this fall, with the goal of putting the specification’s development under neutral governance with contributions from agent developers, model companies, sandbox vendors and others.
Containers vs Containment
Cavage framed the need for stronger controls around the way coding agents work, since they do not simply execute a predefined workload. To complete a task, they may install dependencies, run code, call external services and probe the environment for capabilities they can use.
On stage, he demoed the problem by running Claude inside a Docker container with a secret file stored on the host. The agent discovered that the host Docker socket had been mounted into the container and used it to reach the file. Cavage stressed that Claude had not found a zero-day. Instead, it had used a configuration he described as one of the longest-running critiques of Docker: mounting the host Docker socket into a container, giving workloads inside the container access to the host Docker daemon.
Cavage used the demo to distinguish between containers and containment. The agent had not defeated Docker’s isolation. It had found access that the container configuration already exposed. Containers were designed to isolate application workloads, he argued, while agents make decisions about how to use the capabilities available to them. “We have to separate containers from containment,” he said.
Reviewing Access Before Agents Run
Because those access declarations live inside the OCI image, changes in an agent’s authority can also be reviewed. Pinning a Kit to a specific image digest pins its contents and access declarations together. If an update asks to reach another host or use another credential, that expansion can show up for review, while runtimes that gate updates can stop it for approval.
Docker Sandboxes is currently the first conforming runtime to implement the specification. If other sandbox runtimes implement it and agent and tool vendors adopt it, DevOps teams could gain a common way to review both what an agent runs and what authority it requests before it runs.
