In July, Docker, Snyk and Keycard published Agent Baseline , an open, vendor-neutral reference architecture that defines security outcomes for running AI agents in the enterprise. It grew out of conversations with industry leaders who want to adopt agents more broadly but need answers to three questions:
What is operating, with what capabilities? Is it staying inside approved boundaries? Can you prove what happened and stop it? Agent Baseline gave the industry a shared frame of reference for secure agent adoption by defining the security outcomes for safely deploying agents in organizations. Last week, we published the Secure Software Factory reference architecture, which applies those outcomes to one of the most common agentic workflows: the AI-powered software factory. Enter the Secure Software Factory
The Secure Software Factory was written by practitioners from Keycard, Socket, Docker, Tessl, Tracebit, Browserbase and Tailscale and shaped by conversations with security leaders at large enterprises in regulated environments such as finance and insurance. Over the past year, many engineering teams have started building software factories: systems where agents take a request, change code, run tests and hand the result to a human for review. Teams report faster delivery, but also agents doing things nobody asked for, like escaping sandboxes, dropping databases and pushing to production without approval. Teams need controls that limit what agents can access and do, and check their work at each step. The Secure Software Factory reference architecture shows how to apply Agent Baseline’s security outcomes across this workflow, covering:
The factory workflow , from inputs through design, assembly, build and verification, with controls at each stage. Architectural primitives for identity and access, supply chain, network controls, runtime isolation and orchestration. A maturity model with three levels , so teams can start where they are and improve over time. The paper’s central idea is that the more autonomy you give an agent, the less you can rely on it to police itself. An agent can be redirected at runtime by a prompt, a poisoned dependency or a malicious tool description. Controls have to work regardless of what the agent decides, which means they need to live in the environment it runs in. That means boundaries around credentials, tools, dependencies and network access, backed by evidence of what happened and a human accountable for the result. This is the part of the problem Docker solves. Containers isolate applications; sandboxes isolate actors. Docker Sandboxes are isolated MicroVMs that constrain agents, deterministically. Docker Sandboxes lets coding agents work autonomously in isolated microVM environments, locally or in the cloud, with explicit boundaries around the files, network destinations, and credentials they can access…
