Agent Baseline Publishes Security Reference Architecture for Software Factories
Agent Baseline’s new reference architecture shows how to secure software factories with four boundaries enforced outside the AI agent.
- Sarah Gooding
Agents now write a large share of the code at some of the biggest engineering organizations. Uber says more than 70% of its pull requests are attributed to local or cloud agents, and its weekly agent requests grew 9.4 times between February and August. Stripe’s internal coding agents, which it calls Minions, write more than a thousand of the pull requests Stripe merges each week, and engineers can start one from a Slack message. Vercel’s factory for maintaining its AI SDK authored 25 to 35% of the pull requests merged to main each week during its first four weeks.
These systems, which the industry has started calling software factories, take work from a prompt, a ticket, or an alert and carry it through to tested code, and the most advanced ones deploy and operate what they build.
Every agent in those systems makes decisions a developer used to make: which commands to run, which packages to install, and which services to call. Most security models still assume a person is making those calls. Agent Baseline today published The Secure Software Factory: A Reference Architecture, which lays out how to secure a factory when the agent itself can’t be relied on to stay within its limits. Socket CTO Ahmad Nassri co-authored it with contributors from Docker, Keycard, Barclays, and Secure Theory.
The reference architecture enforces limits outside the agent
The paper opens with the PocketOS incident from April, in which a coding agent on a routine staging task found an API token in an unrelated file and used it to delete the company’s production database, along with the backups stored with it, in nine seconds. The reference architecture treats the agent as untrusted and enforces its limits from outside its decision loop.
Four boundaries, covering the sandbox the agent runs in, the network it can reach, the supply chain it draws from, and the identity and access it acts under, are held by infrastructure the agent can’t configure or reach.
The agent proposes, policy authorizes, and infrastructure enforces. The numbers mark the four boundaries: 1 sandbox, 2 network, 3 supply chain, 4 identity and access. Figure from The Secure Software Factory: A Reference Architecture, Agent Baseline, CC BY 4.0.
The paper applies those boundaries at three levels of autonomy, from a developer directing a single coding agent, to a predefined workflow running the factory as a shared service, to an orchestrator agent that decides what work happens next. The boundaries stay the same at every level, and the infrastructure takes on more of the supervision people used to do as the factory becomes more autonomous.
Socket focuses on the supply chain boundary, which limits agents to the components and sources the organization has approved. Packages, dependencies, and models that enter during a run have to come through an admission point, such as a registry or a supply chain firewall, that serves approved versions and hides unsafe ones so a goal-seeking agent doesn’t go looking for them.
Ahmad described the behavior behind that requirement on the Insecure Agents podcast, where he explained that agents denied a package have gone to the CDN for the tarball, rewritten the registry configuration, or run their own DNS lookups to reach npm or PyPI directly. In the Secure Software Factory reference architecture, an egress proxy that the agent can’t reconfigure closes off those routes, since all of the agent’s traffic passes through it and it allows only approved destinations.
Version 1 of the paper is available at agentbaseline.org/reference-architecture and is open for comment on GitHub.
