On 13 October, Docker, Keycard, Barclays, Socket and Secure Theory published version 1 of the Secure Software Factory, an open reference architecture for development pipelines that AI agents now run a large part of. We had partnered with Docker, one of our customers, on this project.
The Software Factory applies Agent Baseline, the control set Docker, Snyk and Keycard released in July, to the particular problem of agents that write and ship code. It starts from an assumption that an agent will eventually do something nobody asked for, no matter what its instructions said.
"Assume rogue agents" is the natural extension for security teams that already assume breach. The controls belong in the environment the agent runs in.
The part that matters for this post is the detection side: how you find out when one of the boundaries has failed.
The paper opens with failures that have already happened. Each turns on an agent reaching something it was never meant to reach:
- PocketOS lost its production database (and recent backups) when an AI agent attempting an autonomous fix found and used a credential with too much access. (April 2026)
- Hugging Face was breached by an AI agent that escaped its sandbox during one of OpenAI's own internal evaluations, reached the internet, and exploited its way into another company's infrastructure. No human attacker was involved. (July 2026)
- Shai-Hulud worm targets developer environments looking for credentials (September 2025), and returned in August 2026 across 444 npm packages, scanning every machine it reached for roughly 200 patterns of credential and infrastructure files.
Two of these were benign agents that went rogue. The third was malware.
The Secure Software Factory reference architecture
The Secure Software Factory, a reference architecture published by Agent Baseline, is written for that problem.
Constraining how an agent reasons does not work. You cannot instruct your way to safety, because the same prompt that steers an agent can be rewritten by a poisoned dependency or a malicious tool description. What you can control is the environment it runs in. Let the agent reason freely, and put the limits around its execution.
In practice, the paper asks you to do four things:
- Treat agents and everything they read as untrusted.
- Enforce four boundaries: sandbox, network, supply chain, and identity and access.
- Let the agent propose its scope, policy authorize it, and infrastructure enforce it.
- Gate every stage on verification and validation, so nothing advances on the agent's say-so.
The paper states: "Boundaries only protect the factory if no agent can run outside them and someone can tell when they fail."
A boundary that fails silently is not a boundary. This is why "assume rogue agents" is written into the architecture. It's now taken as given that agents will end up outside their lane, then make sure you can tell when it happens. That is where deception earns its place.
Deception technology's role in the Secure Software Factory
The paper asks for observability thorough enough to produce a real audit trail: who authorized the work, and what the agent actually did. Done thoroughly, that means instrumenting everything an agent can reach, and that is a lot.
We recommend placing canaries throughout the factory and the environment around it, so that an agent moving beyond the scope of its task produces a clear alert.
Two of Agent Baseline's own controls describe this problem directly:
- OBS-04 Unintended action detection: calls for spotting actions that are technically permitted but clearly inconsistent with the intended task.
- OBS-03 Behavior and drift monitoring: calls for noticing unexpected changes in data access, tool use and destinations, measured against the agent's approved purpose.
Both are difficult to satisfy with logging alone, because the behavior in question is authorized. Nothing in the audit trail marks it as wrong.
A canary provides that. The credential has no legitimate purpose, so no agent doing its job will ever reach for it. There is no baseline to learn and no threshold to tune.
Each of the four boundaries has a place to put one.
- Sandbox: Canary credentials placed inside the sandbox have no part in any task the agent has been given. PocketOS is the case in point. The agent scanned the codebase, found an account-scoped Railway token that had nothing to do with the job it was doing, and used it. Had that token been a canary, the alert would have fired when it was read, rather than nine seconds later when the database was gone. Halting the agent on an alert to put a human in the loop is something that can be automated and prevents things from going very wrong.
- Network: A perimeter sensor is a believable service on your own domain, bound to canary credentials seeded inside the factory. An agent that has been denied egress and goes looking for another route has to authenticate somewhere. If it tries the sensor, you know it went off task, and you know which credential it picked up along the way.
- Supply chain: Placing canaries in repositories you own, including ones the factory has no reason to touch, gives you an alarm when an agent starts pulling from sources outside its approved set. You cannot plant a canary in someone else's repository, so this boundary is about watching your own estate rather than the wider ecosystem.
- Identity and access: A canary identity in your IdP has no owner and no job. Nothing legitimate ever authenticates as it, so an agent looking for a way to widen its permissions announces itself the moment it tries.
None of this replaces a boundary. What deception gives you is a way to tell when one has failed.
It can also buy time. Our Context Bombs research tested nine techniques against seven frontier models across 773 AWS assessments, and found that decoys can do more than alert. They can send an attacking agent down a path that goes nowhere, buying your team more time to respond.
The boundaries define what an agent may do. Deception tells you what it did. Assume rogue agents, the way you already assume breach, and build the factory so that when one steps outside its lane, you are the first to know.
You can read the reference architecture for free at agentbaseline.org. The project is taking implementation feedback on GitHub.
If you are building a software factory of your own and want to talk through where deception would fit in to keep your agents in check, book a demo with us.