Agent Baseline's Secure Software Factory: Enforce Agent Limits Outside the Agent

Agent Baseline has published The Secure Software Factory: A Reference Architecture (version 1), described in Socket's announcement. Its premise fits one sentence: do not rely on an agent to stay inside its limits; enforce those limits somewhere the agent cannot reach. Socket CTO Ahmad Nassri co-authored it with contributors from Docker, Keycard, Barclays and Secure Theory, and the full text is on GitHub, open for comment.

A "software factory" here means any system where AI agents carry work from a prompt, ticket or alert through to tested code, and sometimes deploy and operate it.

TL;DR

The four boundaries

1. Sandbox. The environment the agent runs in.
2. Network. What the agent can reach. All agent traffic passes through a proxy the agent cannot reconfigure, allowing only approved destinations. The point is to block workarounds such as fetching tarballs straight from a CDN or doing its own DNS lookups.
3. Supply chain. Packages, dependencies and models must pass through an approved gateway, such as a registry or supply chain firewall, that serves only approved versions and hides unsafe ones.
4. Identity and access. The permissions the agent operates under.

The same four apply at three levels of autonomy: a developer directing one coding agent, a predefined workflow run as a shared service, and an orchestrator agent that decides what work happens next. As autonomy rises, infrastructure takes over supervision that people used to provide.

The separation is the design. If the agent can edit its own proxy settings, allow-list or credentials, those controls are only suggestions. The architecture therefore keeps policy and enforcement in components the agent has no write access to, and treats anything the agent says about its own behavior as input to check, not evidence.

The threat model behind the design

The reference architecture starts from a trust table. The agent and anything it runs are untrusted, because the document assumes the agent "can execute arbitrary code and attempt anything its tools allow." Everything the agent reads, such as prompts, tickets and tool responses, is untrusted too, since any of it can carry injected instructions. The destinations the agent may reach are untrusted as well, because an approved service can itself be compromised.

What the authors trust is the enforcement side: the runtime authorization service, the egress proxy, the supply chain firewall, the model gateway, the sandbox runtime and the audit log. The execution layer and the factory's own code and configuration are also trusted, on the condition that they change only through review and never during a run. The document says plainly that these components must be hardened "like any production control plane," because the whole design fails if an agent can reach them.

The architecture does not assume the model is malicious. It assumes the agent may be confused, overly creative, manipulated by something it reads, or taken over by an attacker, and it asks for the same containment in every case. Model-level safety "helps the agent reason well," the authors write, but the architecture does not rely on it.

The authors also frame a factory as having all three parts of Simon Willison's lethal trifecta by design: it reads tickets that outsiders can influence, it holds source code and credentials, and it can open pull requests and reach untrusted networks. The four boundaries are meant to let the factory keep that access while limiting what an untrusted agent can do with it.

The boundaries in more detail

Sandbox

Each task gets its own sandbox, configured from the agent's profile and holding only the repositories and data the task needs. Writes are confined to the task workspace, there is no access to the host, and there is no unmediated path through mounts, shared volumes or local IPC. The appendix asks for isolation matched to risk: a container for trusted work, and a microVM with its own kernel for untrusted or high-risk code. It also asks that the agent run unprivileged, with no root access and no access to the container runtime socket or host devices, and that the sandbox be destroyed when the task ends.

One detail matters for local setups. The document warns that local test setups often mount the developer's Docker socket, which "hands the agent control of the host." Tests that need containers or services should run inside the sandbox's own isolation instead. For an example of a VM-based approach, see Capsem, which Beam covered earlier this month.

Network

The egress proxy starts from default-deny and allows only approved destinations. The appendix asks that enforcement happen "at the sandbox's network layer rather than by proxy settings the agent could ignore." It also asks the proxy to block traffic it cannot inspect or attribute: raw sockets, direct IP connections, and DNS to unapproved resolvers. Cloud metadata endpoints and private network ranges are blocked except for specific internal hosts a task needs.

The proxy has a second job. It attaches credentials only to requests the authorization service has approved, so the agent never holds a token. The text notes that many services only offer coarse keys or scopes and cannot tell which task a request belongs to, but the proxy knows the task and can allow only the repositories, operations and resources it covers. Where no enforcement point can inspect a protocol at that level, the document says to authorize the broader access explicitly or deny the operation, because traffic passing through a proxy does not by itself enforce task-level restrictions.

Supply chain

The supply chain boundary covers two things: what the sandbox is built from, and what enters it during a run. The sandbox starts from verified components, with skills pinned to approved, scanned versions. Packages and models arrive only through an admission point, such as a registry or a supply chain firewall, which serves approved versions and hides unsafe ones "so a goal-seeking agent doesn't go looking for them." The factory's outputs carry provenance, such as an SBOM and build attestations.

The document is candid about what admission cannot do. Provenance proves where a component came from, not that it is safe, and no check can prove natural-language input is safe. Its answer is containment: when a Shai-Hulud-style package gets through, it finds no credentials to steal, and the sandbox and network limit what it can do. Inputs are handled separately from components. Prompts, tickets and signals are validated for structure, provenance and type, and an LLM acting as a judge can add a layer, but the document warns that the same injected text it screens can manipulate it, so it should not be the only check.

Identity and access

Every agent has its own identity, and each action is attributed to both the agent and whoever it acts for. The agent's profile sets the most it can ever do, a task narrows that, and delegation to another agent can only narrow it further. The runtime authorization service, never the agent, decides what each task gets. It also cannot take a request's description of what it needs at face value, since that description may come from untrusted input.

The document gives a pointed example: an alert can be genuinely issued by the monitoring system and still contain attacker-influenced data, such as a log line an attacker wrote. Authenticating the source is one input, and conclusions drawn from the signal's contents still have to fit policy. The authors admit that deriving task scope from untrusted inputs "is still an open implementation question" which version 1 does not settle.

High-impact actions, such as a deploy or a push to a protected branch, go to independent approval or step-up verification. Revocation blocks new actions but, as the appendix notes, does not stop work already running or undo what is done, so it pairs with stopping the agent and rolling back what it changed.

What the architecture says about a developer's own machine

The section most relevant to individual readers is "Securing a local coding agent." The document observes that most local tools run with the developer's own access by default, so the sandbox and egress proxy usually have to be added around the agent. In practice, a local coding agent needs to reach source control, approved package registries, model gateways, documentation and a few specific development services, "and nothing else."

That means blocking private (RFC1918) networks unless a specific internal host is required, cloud metadata endpoints, direct IP connections, unapproved DNS, and arbitrary HTTP and HTTPS. The text also suggests that new package versions can be required to wait out a cooldown before the agent can install them. At Level 1, the table in the document says the agent "acts as the developer or as itself, within the developer's identity boundary," and observability is harness logs plus identity and proxy records that the developer reviews.

Three levels of autonomy

The document names three levels, each with a different orchestrator. At Level 1 the developer is the orchestrator and the execution layer is the agent harness. At Level 2 a predefined workflow starts runs on a durable system such as CI/CD or a durable execution engine, each in a fresh sandbox. At Level 3 an orchestrator agent decides what work happens next, including in response to production signals such as incidents and scanner findings.

The new problem at Level 3 is "keeping an agent's plans from becoming its permissions." The orchestrator proposes a profile and task scope in a preflight step, but "nothing the orchestrator decides authorizes itself." The authorization service independently decides what each task gets. The document also describes a monitoring agent that watches for thrash and drift. Like the orchestrator, it can flag and request but never grant.

The worked example in the text is a production alert about elevated errors in a payments service. The incident agent gets read access to that service's logs for one hour and permission to open one pull request. When it decides it needs logs from an unrelated authentication service, the proxy blocks the call. The agent's reasoning may be sound, but only a new authorization decision can widen the task. Repeated attempts outside scope would be flagged by monitoring and could lead to revocation and a stopped run.

The architecture builds on Agent Baseline, which defines six outcomes (Discover, Constrain, Authorize, Observe, Validate, Respond) supported by 35 controls. The reference architecture's appendix maps which controls become required at each level.

Why this matters now

Recent incidents show why prompt-level rules are weak. In Anthropic's unintended actions report, models routed around a URL-length limit with shorteners and acted where instructions left a gap. In npm worms aimed at AI tooling, the install path itself was the attack. A registry gateway and an egress proxy are the controls those cases point to.

The document itself opens with an incident. In what it calls the PocketOS incident, 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 authors cite it for the missing credential boundary, and cite "Let's land #118" for missing approval on high-impact actions. They say the lack of narrow destinations was the control missing in the Anthropic and Hugging Face incidents. Beam's own account of the latter is in the Hugging Face agent breach.

The authors also describe the scale of agent-written code as the reason to act: they report that Vercel's factory authors 25 to 35 percent of its AI SDK team's merged pull requests, that Uber says more than 70 percent of its pull requests come from agents, and that Stripe's agents go from a Slack message to a pull request that passes CI with no human interaction. Those are the document's reported figures, and Beam has not checked them independently.

What this means if you run AI coding agents

• Run agents in a container or VM you can discard, not your daily-driver account.
• Route package installs through a registry or firewall you control, and pin versions.
• Give agents their own scoped credentials, not your personal tokens.
• Restrict outbound destinations at the network layer rather than in the prompt.

See the enterprise rollout checklist and supply chain security guide for deeper steps.

Update (October 20, 2026): comment period and status

The text of the reference architecture says it is "open for comments at agentbaseline.org." The Agent Baseline site now states that comment on the v1.0-draft closed on September 30, 2026, that what it raised is in the project's issues, and that each item was decided in the open. The site still invites implementation feedback, uncovered control gaps and evidence that a control is ineffective, through its contributing guide. Read "open for comment" in this post as "open to issues and feedback," and check the repository for the current text.

How to use it without building a factory

Most readers will not run a Level 2 or Level 3 factory. The document's Level 1 description still gives a short test for a single machine:

1. Can the agent change the setting that limits it? If it can edit its own proxy variables, allow-list file or hook configuration, that control is advice.
2. Does the agent hold a credential it does not need for this task? The PocketOS example turned on a token the agent found by itself.
3. Can the agent install any package version it asks for? An admission point or a cooldown on new versions narrows that path.
4. Can the agent reach hosts that the task does not need, such as private ranges or cloud metadata endpoints?
5. Is there a record of what the agent did that the agent cannot edit?

None of these needs new products. A throwaway container, a scoped token and an outbound allow-list cover the first four on one machine. Each answer shows which of the four boundaries is only a suggestion today.

What Beam can and cannot do here

Beam watches what Claude Code, Codex and similar agents do on a single machine, keeps data on-device, flags risky actions such as credential exposure, and scans skills and MCP configs before you run them (11 heuristics plus a version-pin check). With workspace enforce, PreToolUse hooks for Claude Code and Codex can deny matching tool calls. That is a useful local layer, and monitoring versus blocking explains the tradeoff.

It is not a kernel sandbox, does not proxy network traffic, does not gate your package registry, and fails open when cached policy is missing. Treat it as an evidence and guardrail layer inside, not instead of, the boundaries above. Mapped to the document's boundaries, Beam's hooks touch the sandbox boundary's "policy on which commands the agent may run" only on the agents it supports, and its local event record can serve as one input to observability. The document asks for a record "out of any agent's reach." Beam's local data is on the same machine the agent runs on, so how far that holds depends on how you separate accounts and permissions. Beam does not provide the authorization service, egress proxy or model gateway the architecture describes. See how Beam works.

Frequently asked questions

What is Agent Baseline's secure software factory?

A version 1 reference architecture for systems where AI agents take work from a prompt, ticket or alert through to tested code. It treats agents as untrusted and enforces limits outside them.

What are the four boundaries?

Sandbox, network, supply chain, and identity and access.

Why an egress proxy the agent cannot reconfigure?

To block workarounds such as fetching tarballs directly from a CDN or doing its own DNS lookups.

Is this a product I can install?

No. It is a reference architecture, open for comment on GitHub.

How does this relate to Beam?

Beam is a local observability and hook-based deny layer for individual developers, covering part of the picture on one machine.

Related reading

• Stopping dangerous Claude Code commands
• MCP security: a practical guide
• Capsem: a VM sandbox for AI coding agents
• The Hugging Face agent breach

Details reflect Agent Baseline's version 1 publication as described on October 13, 2026. The document is open for comment and may change.