Docker’s WeAreDevelopers keynote: building trust around AI agents

At WeAreDevelopers North America, Docker President Mark Cavage presented a practical argument for teams adopting AI agents: an agent is not merely a workload that produces text or code. It can install dependencies, use tools, reach networks, access credentials, and continue operating after its developer has closed a laptop. The useful question is therefore not only whether a model is capable, but whether its operating environment, authority, and actions remain controlled and auditable.

Agents are actors, not ordinary containers

Containers were built to isolate applications. Docker’s keynote argues that an autonomous agent needs a boundary around the wider environment it can affect. In Cavage’s demonstration, the container behaved as intended, but the agent’s reach still required stronger containment. Docker Sandboxes address that by running each agent in its own isolated microVM with a separate kernel from the developer host.

The developer can select the agent, model, and tools for a job, then define access to files, networks, and secrets. Crucially, those policies remain outside the agent’s control. The result is a boundary that lets a team permit useful work without silently granting broad host access. Docker Sandboxes are available now as a free standalone CLI, allowing existing agent workflows to gain a dedicated isolation layer.

Making authority reproducible with Kits

The keynote also announced the next generation of Docker Sandbox Kits, built as standard OCI images. A Kit packages an agent, its tools, and the rules governing what its sandbox can reach into a versioned, shareable artifact. That matters to platform and security administrators because an agent permission change can be reviewed like an image or configuration change rather than being hidden in an ad-hoc setup.

Dockerfiles made software environments reproducible; Docker frames Kits as a way to make authority reproducible. Teams can distribute Kits through familiar image workflows, retain a version history, review changes to network or secret access, and reconstruct the exact environment after an incident. Docker is inviting ecosystem partners to shape the specification and says it will submit the Kits specification to the Cloud Native Computing Foundation. Its OCI basis is intended to make the format useful across the cloud-native ecosystem rather than tied to a single model provider.

Start locally, continue in the cloud

Some agent tasks finish on a laptop. Long-running work and parallel jobs need compute that remains available after the developer steps away. Docker Cloud Sandboxes bring the same microVM-based isolation model to Docker-managed cloud compute. Using the familiar sbx workflow, a developer can begin locally, move a job to cloud capacity with one command, and let it continue without personally provisioning or maintaining the underlying infrastructure.

Docker says Cloud Sandboxes are available with pay-as-you-go pricing. The keynote also promotes a limited-time $250 compute credit for new accounts. For an IT team, this does not remove the need for cost controls: durable capacity can make experimentation easier, but it also requires budgets, job limits, observability, and a clear owner for every cloud-running agent.

Choice with a shared trust layer

Docker used Nous Research and its Hermes agent as an example of the intended ecosystem: a third-party agent can run as a first-class Kit while Docker supplies the isolation and controls underneath. This distinction is operationally useful. An organization can choose an agent suited to a task without rebuilding the trusted execution layer for every vendor or model.

Practical checklist for administrators

• Begin with Docker Sandboxes and grant only the files, network routes, and secrets a task requires.
• Package the agent, tools, and access rules in an OCI-based Kit; review every version and policy change.
• Keep secrets outside prompts and images; issue them through policies the agent cannot alter.
• Separate code-read, code-write, deployment, and production permissions.
• Before Cloud Sandboxes, set budget limits, runtime limits, logging, and ownership for long-running jobs.
• Test the local sbx workflow before moving parallel or persistent work to cloud capacity.

Conclusion

Cavage’s announcements form one operating model: Sandboxes provide a deterministic boundary, Kits make the environment and authority repeatable, and Cloud Sandboxes extend that model to durable cloud capacity. The point is not that an agent becomes safe by default. The point is that teams retain control over what it can access and change while still allowing useful autonomy.

Source

Docker Blog — Manufacturing Trust for AI Agents; Docker Sandboxes documentation.