A reference architecture for agent security, and how Bromure maps to it
Engineers from Docker, Keycard, Barclays, Socket and Secure Theory have published The Secure Software Factory, a reference architecture for running coding agents safely, built on the Agent Baseline controls. It is a good start, and we are glad to see it. Here is how Bromure Agentic Coding covers its four boundaries and where it goes further on observing and responding.
On 13 October, a group of engineers published The Secure Software Factory, a reference architecture for organizations that let coding agents write, test and ship code. It is drafted by Eli Aleyner, Ranti Familusi and William Manning (Docker), Allie Howe and Ian Livingstone (Keycard), Andy McMahon (Barclays), Ahmad Nassri (Socket) and Aaron Stanley (Secure Theory). It builds on Agent Baseline, a set of 35 controls grouped into six outcomes, which Keycard convened with engineers from Docker and Snyk.
We are happy to see it. It is a public, versioned draft with stable control identifiers, licensed CC BY 4.0, open for comment on GitHub, and meant to be donated to a community body once it matures. Vendors and the teams that buy from them can now point at the same controls.
What the architecture asks for
Its core idea fits in one line: "the agent proposes, policy authorizes, and infrastructure enforces." The agent is treated as untrusted, whether it is confused, manipulated by something it read, or taken over, so its limits have to be enforced outside its own decisions. The document draws four boundaries:
- Sandbox: agent code runs only in an isolated sandbox it can't change or escape.
- Network: "nothing gets in or out except through paths the agent can't reconfigure or bypass."
- Supply chain: components come only from approved sources, and nothing entering the sandbox carries credentials.
- Identity and access: an agent uses only the access granted for its task, never holds credentials, and needs approval it can't give for high-impact actions.
These hold across three levels of autonomy: a developer steering an agent (Level 1), a workflow running agents as a shared service (Level 2), and an orchestrator agent deciding what happens next (Level 3). Around them sit an execution layer that can stop any agent, and an audit trail out of every agent's reach.
It grounds this in real incidents. In one, a coding agent on a staging task found an API token in an unrelated file and deleted a production database with it in nine seconds. In the Shai-Hulud worm, malicious packages harvested whatever credentials they found on the machine that installed them.
How Bromure covers the four boundaries
Bromure Agentic Coding runs on your Mac and puts each agent workspace in its own Linux VM. Here is how that lines up.
| Boundary | The architecture asks | Bromure |
|---|---|---|
| Sandbox | Isolation matched to risk, up to a microVM with its own kernel; no host access; tests run inside the same isolation; stop on demand and keep the state as evidence | A full Linux VM per workspace, with its own kernel and its own Docker for tests. With an OpenShell policy, Landlock and seccomp confine the agent inside it. A machine can be paused, and Save for Investigation exports its disks before it is wiped |
| Network | All traffic through an egress proxy enforced at the network layer, not by proxy settings; per-operation enforcement | The Mac's virtual switch checks every connection, and diverts web traffic into Bromure's proxy even when a tool ignores the proxy settings. Rules can limit HTTP methods, and with an OpenShell policy, paths and MCP, GraphQL and WebSocket operations |
| Supply chain | Packages only through an admission point; new versions wait out a cooldown; nothing entering the sandbox carries credentials | Installs from eight ecosystems go through Bromure's checks: a two-day age gate on new versions, on by default, plus optional OSV and socket.dev lookups. A package with no verdict is held for your decision |
| Identity and access | The agent never holds credentials; they are attached at the proxy; high-impact actions need approval | The VM only ever holds stand-in tokens; the proxy swaps in the real ones for the right host. SSH keys stay on the Mac, and AWS requests are re-signed outside the VM. Writes such as a git push can require a click, and agent branches merge only when you approve |
The credential boundary matters most for incidents like these. A Shai-Hulud package harvesting a Bromure VM finds only stand-in tokens, useless outside Bromure's proxy. (Socket, where one of the authors works, is also one of the package checks Bromure can use.)
The levels map as well. A developer running agents in sessions is Level 1. Automations that start an agent on a schedule, or when a GitHub pull request or Linear issue arrives, each in a fresh git worktree and optionally in a disposable clone of the machine, are Level 2. Agents delegating work to other agents, with every message relayed by the host, screened for prompt injection and logged, are the start of Level 3.
Where Bromure goes further
The draft is candid about its own weak spots. Its provenance statement says that of the six outcomes, Discover, Observe and Respond "are not sold by any convening organization" and "are correspondingly less developed", and calls that asymmetry "a defect". It also says that by the baseline's own test, none of the three convening companies is a complete implementation. That is an unusually honest thing to put in writing.
Observe and Respond are where we put the most work:
- Watching from inside the kernel. The architecture asks the sandbox runtime to record process, file and network activity. Bromure's kernel sentry does that from inside the guest kernel and streams it to the Mac over a channel that root in the VM can't close. If anything tries to silence it, that counts as tampering.
- Intent to outcome. Agent Baseline's control OBS-05 asks for evidence that links what an agent meant to do with what it did. Bromure's lineage traces every connection back through the processes that opened it to the agent's tool call and the reasoning the model gave for it. When a dependency's install script tries to send data out, you see the install that ran it and why the agent ran that install.
- Screening the inputs. The architecture treats everything an agent reads as
untrusted. Bromure can scan tool results and rules files such as
CLAUDE.mdfor prompt injection on your Mac, screens every message between agents, and always screens the text of a GitHub or Linear event before an automation acts on it. - Data sent for inference. Bromure's PII protection swaps names, emails, account numbers and similar data for stand-ins before a request reaches a cloud model, and restores them in the reply.
- Responding with the evidence intact. When Bromure sees a credential leaving where it shouldn't, it pauses the VM. You can shut it down, or save its disks for investigation, after which the machine refuses to boot until it is wiped. With OpenShell policies, a burst of refused operations quarantines the workspace: network cut, VM paused.
- Traces out of reach. Each machine's trace of model requests, tool calls, commands and file activity is stored on the Mac, encrypted, outside the VM.
There is one more difference in where it runs. The architecture is written for factories, and Level 1, a developer with a local agent, gets a few paragraphs. That is where most agents run today. Bromure puts the four boundaries on that developer's Mac, with no infrastructure to stand up, and it is free and open source.
A good start
The Secure Software Factory is version 1 and open for comment: careful about what it claims, and honest about whose products shaped it. Its issue tracker is open to anyone, and the sections on observing and responding are where we think the most remains to be written.
More companies working on agent security in public, with stable control identifiers, is good for everyone who runs agents.