Coding agents are moving from a single developer's terminal into pipelines that write, test and ship code with less and less human direction. That shift turns the software factory from a metaphor into an attack surface, and most teams are still working out where the boundaries should sit.

Recorded live at the AI Security Summit in San Francisco, The AI Native Dev brought together three co-authors of Agent Baseline, a new security reference architecture for software factories: Eli Aleyner, VP of Product Strategy at Docker, Marcelo Sousa of Snyk, and Ian Livingstone, founder and CEO of Keycard. Host Simon Maple asked them what it actually takes to give agents autonomy without handing them the keys.

Three levels of software factory maturity

The panel started with a definition, because "software factory" means different things to different people. Eli described it as whatever an organization uses to produce code, and laid out three levels of autonomy.

At level one, developers use coding agents and direct the whole process end to end. At level two, agents work inside a predefined workflow that produces, tests and assembles parts of an application. At level three, there is no predefined workflow at all: the agent decides the next step, which tools to use and which other agents to call.

It can be helpful to read these as a maturity curve rather than a ladder everyone must climb. Eli observed that few organizations have reached level three successfully, and that depending on the task, different parts of the same company may sensibly sit at different levels. Ian noted that distilling a nebulous concept into stepwise tiers was the hardest part of writing the paper, precisely so teams could ask a practical question: where are we today?

Manufacturing trust in an unpredictable actor

The core of the architecture rests on a first-principles view of what an agent is. On one hand it is just software. On the other, it is directed by something fundamentally probabilistic.

"In the wide majority of scenarios, an agent will do exactly what you ask it to do," Eli explained. "In some percentage of use cases, where the percentage is not zero, it will do things that are not your intended action."

That framing changes the job. Rather than assuming good behavior, the goal is to manufacture trust: a runtime that enforces boundaries on which networks the agent can reach, which secrets it can see and which local files it can touch. Autonomy, in this view, is something earned inside those boundaries rather than granted outside them.

Why the coding agent should never hold a credential

Ian pointed to the obvious failure mode. If a harness running in your user space is handed a Stripe or AWS key, nothing stops the agent performing any action that key allows, whether or not that was the intent. He cited the PocketOS incident, in which an agent working in staging found production keys and caused significant damage to a production database, and noted that incidents like it happen all the time.

The less obvious risk is accidental leakage. An agent might write a key to disk or send it off in a query parameter without realizing it. The approach Agent Baseline recommends is to keep secrets out of the sandbox entirely and enforce at the egress point, injecting credentials into outbound traffic only where required. Scoping those credentials with authorization boundaries adds a second layer, since many keys grant far more access than any single task needs.

The agent supply chain is now dynamic

Marcelo argued that supply chain risk looks different when the thing picking dependencies is an agent. A package manifest no longer tells the whole story. When an agent clones an open source repo, that repo may carry its own skills and MCP server configurations, and the agent may start consuming them, which he described as a supply chain that has become almost dynamic.

Skills sharpen the point. Marcelo described them as a Matrix-like moment: load a skill and the agent can suddenly do something new. That cuts both ways. A tampered skill can induce an agent to download and execute binaries as an apparent prerequisite, and some skills run scripts as they load. In practice, this suggests treating untrusted skills and MCP servers as a serious threat vector, and reviewing what a skill is actually telling the agent to do.

Eli added a caution that runs through the whole paper: "Assuming that just sandboxing is enough, in my mind, is completely insufficient."

Least privilege, agents monitoring agents, and the agent harness

Some inputs can be controlled, such as the base image inside the sandbox. Others, like prompt injection, may never be fully solved. Ian's answer was layered: harden boundaries wherever possible, apply least privilege where you cannot, and over time use agents that monitor other agents without sharing the same exposure to injected context. He also flagged emerging decision models as a cheaper way to judge whether an action aligns with intent.

"Nothing about this is trustable," Ian argued, so the job of the agent harness is to build a hardened boundary around the untrusted thing and give the agent a playground where it can iterate its way to success without causing damage.

Approval fatigue: YOLO mode vs CYA mode

Human approval for high-impact actions sounds like a safety net, but Eli described how it decays. Agents have largely run in two modes: YOLO mode, where you let it rip, and CYA mode, where you approve every single action. The second breeds fatigue, because people have long ignored warnings, and they ignore them faster when they appear every minute. As models handle longer tasks, the pressure to run with autonomy grows, which makes structural boundaries more important than prompts.

Where to start securing your software factory

Asked what to do on Monday morning, the panel converged on fundamentals. Marcelo, describing agents as sometimes being "kids with chainsaws," urged teams to cover the basics: container environments, no secrets in plain text, and egress control points. Ian suggested checking whether you are even at level one, meaning a common, shared setup for agents rather than a buffet of seven tools, since consolidation pays off for both security and usability. Eli's starting point was containment, because the rest of the architecture is hard to implement for agents that are not contained.

Agent Baseline v1 is open for comment, and the authors were clear it is an opinion meant to evolve with community feedback. The full conversation is worth a listen for anyone deciding how much autonomy their coding agents should have, and what boundaries need to exist first. Which level is your team at today?