The agent is the worker that can generate or modify code, while the software factory is the production system that constrains how work enters, moves through, and exits the pipeline. The factory includes approvals, quality gates, evidence, credential handling, and cost controls. Practitioners should govern the factory boundary, not just the model or the agent itself.
What separates the agent from the factory that surrounds it?
The distinction is architectural. The agent is the decision-making worker that can draft code, transform artifacts, or trigger actions; the software factory is the controlled environment that decides which work is allowed in, how it is reviewed, what evidence must be captured, and what can leave the pipeline. Treating them as the same thing usually blurs accountability and weakens control.
Why the agent is only one part of the production system
An agent can be useful without being trusted. Its value is that it can move quickly across code, tests, tickets, and tools, but that speed is only safe when the surrounding system constrains scope. In practice, the factory boundary is where you decide whether the agent may write to a repo, call a deploy tool, open a change request, or only propose a patch for review.
The worker should therefore be designed as a bounded contributor, not an implicit owner of the pipeline. That means its permissions, context, and output format are all subordinate to the production process around it. The better question is not “what can the agent do?” but “what is the factory willing to accept, verify, and record?”
A useful mental model is to treat the agent like a specialist operator inside a controlled plant, not like the plant itself. The plant still needs intake rules, inspection points, release criteria, and exception handling. Without those controls, the agent becomes a direct path from prompt to production risk.
What the software factory controls that the agent does not
The factory is the system of governance around work. It defines entry conditions, quality gates, evidence requirements, review paths, and release authority. It also handles credential use, artifact provenance, cost guardrails, and rollback expectations. This is where an agent’s output is normalized into something the organisation can trust, test, and audit.
That boundary matters because many failures are not model failures at all, they are pipeline failures. An agent may generate a correct patch, but if the factory accepts it without tests, allows broad credentials, or skips approval for high-impact changes, the real weakness is in the production system. The same logic applies when an agent has access to deployment, signing, or secret-handling steps that should remain tightly constrained.
For teams building AI-assisted delivery, the practical design choice is to separate creation from acceptance. The agent can create candidate work, but the factory decides whether the work is complete, safe, and attributable. That separation is what keeps automation from becoming uncontrolled automation.
Why this distinction matters for governance and scale
The difference becomes most important when the agent operates with any meaningful authority. If it can touch source control, CI/CD, credentials, or infrastructure, then its actions must be treated as part of a governed delivery chain rather than an isolated productivity feature. AI Agent Authorisation Guide is useful here because it frames task-scoped access, per-action decisions, and human approval as factory controls, not model features.
At scale, the main risk is not one bad action but repeated unsafe defaults. A small convenience choice, such as standing credentials or unrestricted tool access, can turn into a system-wide exposure when many agents share the same pipeline. The right governance boundary keeps approvals, logging, and exception handling in the factory layer so that the organisation can trace who allowed what, when, and under what policy.
This is also where secure coding and release governance meet AI operations. AI Coding Agents Security Guide reinforces that secrets in context, over-scoped tokens, and sandboxing are pipeline problems as much as agent problems. If the factory does not constrain those conditions, the agent inherits more authority than the delivery process can safely absorb.
Risk and Threat Considerations
The main danger is boundary collapse: teams start trusting the agent as if it were the control system, when it is only one actor inside it. That creates exposure through excessive privileges, weak review, hidden credential use, and unverified changes that move too far too fast.
Failure mechanism: The agent gains access to tools or secrets that should be mediated by the factory, then uses that access to create, modify, or promote work without sufficient review, isolation, or provenance checks.
Impact: Unsafe code, compromised credentials, uncontrolled deployments, and poor auditability can all follow, especially when the same pattern is repeated across multiple workflows or environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The question is about agent authority versus surrounding controls. |
| ASI02 — Tool Misuse | The factory boundary controls which tools an agent may invoke. | |
| Recommendation — Constrain agent permissions and require policy decisions for each action. Restrict tool access to approved workflows and high-signal actions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Factory controls should limit what the agent can do in production systems. |
| AU-2 — Event Logging | The factory must record evidence of agent actions and approvals. | |
| Recommendation — Apply least privilege to every agent-facing credential and integration. Log agent requests, approvals, and promoted changes with traceable attribution. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The answer centres on verifying each agent action rather than trusting the worker itself. |
| Recommendation — Verify each request and treat every agent action as untrusted until authorized. | ||
Practitioner Guidance
What to verify: Confirm that the agent can only act within a bounded workflow, and that every path from proposal to merge, build, deploy, or secret use is separately governed. If the agent can cross the boundary without an explicit factory decision, the design is too loose.
What good looks like: The agent produces work, but the factory enforces human or policy approval, evidence capture, and least-privilege execution. The best implementations make it obvious which outputs are suggestions and which are authorised changes.
Common mistake: Treating model quality as the primary control and assuming a better agent removes the need for a stronger pipeline. In practice, higher-capability agents make factory discipline more important, not less.
Practitioner takeaway: Govern the production boundary first. If you cannot explain how work is admitted, checked, attributed, and released, you do not yet have a software factory, only a powerful worker with too much freedom.
Related resources from NHI Mgmt Group
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between zero trust for users and zero trust for NHIs?