Secure software factory is not a new term. Security architects have used it for years to describe the pipeline that turns source code into a trusted, verifiable artifact: signed builds, provenance tracking, dependency attestation, the machinery that proves a piece of software is what it claims to be. That definition was built for a world where humans wrote most of the code and machines mainly moved it through the pipeline.
That world is gone. AI agents now write a growing share of enterprise code directly, and they do it faster than any human review process was built to handle. The pipeline security problem the term was originally coined for still exists.
But it has been joined by a second, harder problem: how do you govern the code itself when the thing generating it has no institutional memory, no accountability, and no way to know whether what it just wrote violates a policy nobody told it about?
This article covers four things:
- What a secure software factory has to account for now that AI agents generate code directly instead of only moving it through a pipeline
- Why existing AppSec and DevSecOps tooling was not built to catch what agentic development introduces
- How Forge approaches security and governance as a structural property of the build process rather than a checkpoint bolted on afterward
- How that approach compares to other AI-native platforms competing in adjacent parts of this problem
Why AI-Generated Code Is a Different Kind of Security Problem
Traditional application security assumes a slow, traceable origin story for every line of code. A developer writes it. A reviewer reads it. A scanner checks it against known vulnerability patterns before it merges. Each step leaves a record, and that record is what auditors, security teams, and compliance officers rely on when something goes wrong.
AI coding agents break that origin story in three specific ways:
- They are stateless – an agent has no memory of the last codebase it touched or the last policy violation it caused, so it cannot learn from its own mistakes the way a human engineer eventually does.
- They have no architectural judgment – an agent will happily generate code that is syntactically correct and functionally plausible while violating a security boundary it was never shown, because nothing in its context told it that boundary existed.
- They operate at a volume review processes were not built for – a security team that could reasonably review a human engineer’s dozen pull requests a week now faces agents producing that volume in an afternoon, across every team running them in parallel.
Opsera calls the resulting dynamic the Agentic Paradox: AI speed is building a future that is structurally unmaintainable, one ungoverned change at a time. Applied to security specifically, the paradox gets sharper. Every agent-generated change that ships without a governance gate is a change that expands the attack surface without expanding the organization’s ability to see it.
As Rajeev Madhavan, Founder and Managing Director of Radiant, frames it, AI has given every developer superpowers, but code generation without enterprise-grade governance limits how safely that power can be used. The superpower and the exposure arrive together.
What the Research Shows About This Gap
Gartner’s research puts numbers behind what security and engineering leaders are already sensing.
- The Resilience Deficit – 62% of enterprise risk leaders admit their current business continuity plans do not adequately prepare them for the disruptions introduced by rapid AI scaling.
- The Validation Barrier – 35% of successful AI adopters identify validating the accuracy of AI-generated output as one of their top three operational challenges, which is a security and compliance problem as much as a quality one.
- The Maintenance Cliff – by 2027, organizations that do not adopt spec-driven development for AI work will see 25% slower delivery, driven by rising costs in defect remediation and rework, much of which traces back to issues that should have been caught before code shipped.
- The Accuracy Benchmark – prioritizing semantics and persistent context in AI-ready data is projected to increase agentic AI accuracy by up to 80%, alongside up to 60% lower operational costs, which is the clearest evidence available that most of the AI accuracy problem is really a missing-context problem wearing security clothing.
Independent research on AI governance points at the same gap from a different angle. Industry surveys on enterprise AI coding adoption have found that a majority of technical leaders want security and access controls centralized in a platform layer beneath the applications AI generates, rather than configured piecemeal inside each generated app, and that only a small fraction of organizations currently govern AI-generated code at that environment level.
The tools are ahead of the governance. That gap is the actual product category a secure software factory needs to fill.
Why Traditional AppSec Tooling Doesn’t Close This Gap
It would be reasonable to assume the enterprise security stack already covers this. Static analysis, dependency scanning, secrets detection, and policy-as-code tools are mature, widely deployed, and genuinely effective at what they were designed to do. None of them were designed to answer the question that matters most with agentic development: does this specific change match what the system was supposed to do, and did a human actually authorize it.
Two gaps show up consistently in organizations trying to bolt security onto agentic development after the fact.
- Scanners Catch Known Patterns, Not Intent Violations
A vulnerability scanner is built to recognize patterns it has seen before: a known-bad dependency, an unescaped input, a hardcoded credential.
It has no way to evaluate whether a change fits the system’s actual architecture, because “the system’s actual architecture” is not something most scanners have access to in a structured, machine-readable form.
An agent can write code that passes every scan cleanly and still violate a security boundary that only existed in a design document nobody connected to the pipeline.
- Review Checkpoints Assume Human-Scale Volume
Human-in-the-loop review works when the volume of change matches human review capacity. Agentic development breaks that assumption directly.
Security and compliance teams end up with two bad options:
- Slow the agents down to a pace humans can review, which erases the speed advantage that justified using agents in the first place,
- Let volume outpace review, which is how governance gaps turn into actual incidents.
Katie Norton, Research Manager for DevSecOps and Software Supply Chain Security at IDC, describes the shape of what is actually needed.
As AI increases the speed and scale of code generation, organizations need stronger ways to validate what is being built, what risks it introduces, and whether it meets policy requirements before code progresses, rather than reviewing for compliance after the fact.
Forge’s Approach to a Secure Software Factory: 3 Core Capabilities
Forge treats security and governance as something the build process enforces structurally, not something a separate team checks for after code already exists.
As Kumar Chivukula, Co-Founder and CEO of Opsera, puts it, AI gave enterprises speed, and Forge is built to be the first Secure Software Factory that pairs that speed with governance, delivering new applications from concept to cloud in hours while modernizing the legacy debt that consumes nearly 40% of IT budgets. That structural approach shows up in three connected capabilities.
- Active Governance and Compliance Mapping
Rather than treating security review as a gate at the end of the pipeline, Forge structurally maps every agentic action to an organization’s corporate policies and regulatory mandates as the action happens, so generated code is auditable and compliant before it ever reaches production.
This is the mechanism behind Forge’s Spec-Driven Development capability: AI-generated code has to satisfy explicit architectural and behavioral constraints before it can merge, which means the specification itself functions as a security and compliance gate rather than a reference document a reviewer checks against after the fact.
- ForgeScore: An 8-Dimension Fidelity Assessment That Includes Security
Instead of a standalone security scan disconnected from everything else affecting a system’s health, ForgeScore evaluates a codebase across eight dimensions in a single run: security, architecture, performance, maintainability, test coverage, infrastructure fit, cost efficiency, and AI adaptability.
Folding security into a broader fidelity assessment, rather than treating it as a separate workstream, means a security finding shows up next to the architectural and maintainability context that explains why it matters and how urgently it needs to be addressed. What used to take weeks of manual, multi-discipline review happens in minutes.
- Work Orders: A Machine-Auditable License for Every Agentic Action
A Work Order is a human-auditable license that authorizes a specific agentic action and ties it back to a specific human intention. That structure is what makes governance a property of the workflow itself instead of a step someone has to remember to perform.
It also means multiple agents can execute in parallel without losing individual traceability, because every action, no matter how many agents are running at once, carries its own audit trail back to the human who authorized it.
Roman Vorel, VP and GM of Digital Supply Chain and ERP at Intel, connects this directly to how enterprises already run security operations.
Forge lays the foundation for enterprise autonomy by creating and preserving context through governed workflows and systems of record, enabling solutions like ITSM to resolve issues intelligently and deploy changes through the DevSecOps processes companies already trust.
The point is not to replace the DevSecOps stack an enterprise has already invested in. It is to make sure AI-generated change flows through that stack with the same governance a human-authored change would carry.
Underneath all three capabilities sits Forge’s Contextual Shared Memory: a persistent layer that folds architecture, security, policy, and operational rules into one shared source of truth, so every agent working on a system inherits the same security context instead of reconstructing it, imperfectly, from whatever happens to be in its current session.
Forge Capabilities at a Glance
| Capability | What It Does | Technical Mechanism |
| Active Governance and Compliance Mapping | Enforces policy and regulatory alignment before code reaches production | Structurally maps every agentic action to corporate policy and regulatory mandates in line, not as a post-hoc review |
| ForgeScore (8-Dimension Assessment) | Evaluates security alongside architecture, performance, and six other dimensions in one run | Produces a structured fidelity score covering security, architecture, performance, maintainability, test coverage, infrastructure fit, cost efficiency, and AI adaptability in minutes |
| Work Orders (HITL Verification) | Authorizes and audits every agentic action | Creates a machine-auditable license tied to a specific human intention, enabling parallel agent execution without losing individual traceability |
| Contextual Shared Memory | Gives every agent the same security and policy context | Folds architecture, security, policy, and operational rules into one persistent, shared context layer |
Forge Key Benefits
- Security review shifts upstream – violations get caught against the specification before merge, instead of getting discovered in a scan or an incident after code has already shipped.
- One assessment covers eight dimensions – security sits alongside architecture, performance, maintainability, test coverage, infrastructure fit, cost efficiency, and AI adaptability in a single ForgeScore run, instead of a standalone scan disconnected from system context.
- Every agentic action is individually auditable – Work Orders create a traceable license tied to a specific human intention, so parallel agent execution does not mean losing track of who authorized what.
- No model training on proprietary code – proprietary code, intent, and architectural data stay private and are never used to train foundational AI models.
- Works inside the DevSecOps stack already in place – Forge integrates with Cursor, Claude, GitHub Copilot, VS Code, existing CI/CD pipelines, and both cloud and on-premises environments, rather than requiring a rip-and-replace of existing security tooling.
- Governance holds up under parallel execution – because Work Orders are enforced structurally rather than manually, multiple agents can run at once without security review becoming the bottleneck that erases the speed advantage.
Trade-offs to Consider
- Governance is only as complete as adoption – Work Orders enforce policy for agentic actions that actually get routed through them, so a team running agents outside the governed workflow creates a blind spot the audit trail cannot see into.
- Specification quality determines security coverage – if a specification is incomplete or vague about a given constraint, code that violates that unstated constraint can still clear the gate, since the gate can only enforce what the spec actually states.
- This is a workflow change, not a drop-in scanner – getting the governance benefit depends on formalizing specs and policy mappings first, which is real upfront work before the security payoff shows up.
- Best suited to environments already running multiple agents or handling regulated data – a small team running a single agent on a low-stakes internal tool may find the governance overhead heavier than the risk it is managing.
Is Forge Right for Your Organization?
Forge tends to fit best for organizations with the following characteristics.
- Security and compliance teams that need every AI-generated change traceable to a specific human decision and a specific approved specification at the moment it happens, rather than documented after the fact.
- Organizations in regulated industries where auditability of AI-generated code is a requirement rather than a nice to have.
- Engineering teams running multiple AI agents across a shared codebase, where a governance gap in one agent’s output can compromise work the other agents are building on.
- Enterprises that already have DevSecOps tooling in place and need AI-generated code to flow through those existing controls, rather than needing to replace them.
Forge may be less of a fit for organizations in the following situations.
- A small team running a single agent on a simple, low-stakes project, where formal governance overhead may outweigh the risk being managed.
- Organizations not yet using AI coding agents at all, since a meaningful part of Forge’s value comes from governing AI-driven work specifically.
- Teams looking only for a standalone vulnerability scanner rather than a governance layer that spans specs, assessment, and execution.
How Forge Compares to Other Security-Focused Development Platforms
Most competing platforms address one layer of this problem, usually generation speed or prototyping, without treating governance of the generated output as a structural, enforced property of the workflow.
| Competitor | Their Weakness | Forge Knockout |
| 8090 | Prioritizes rapid app generation speed but has historically lacked the enterprise-grade guardrails needed to prevent unmanaged architectural drift and security exposure | Work Orders provide a specific, machine-auditable license for AI agents to act, moving execution from unmanaged speed to governed production |
| Dazl | Focuses on visual prototyping and high-speed prompting that often results in context rot, where agents lose track of long-term architectural and security intent | Persists architectural and security context across the entire factory through Contextual Shared Memory, targeting the accuracy gains that come from eliminating context loss |
| vFunction | Treats modernization as a purely technical refactoring task, which can leave compliance and security posture unverified against business-approved specifications | Verified Modernization checks refactored code against reverse-engineered, approved specifications rather than technical parity alone |
| Retool (AI) | Optimized for internal admin tools and prototypes, which creates shadow IT risk and lacks end-to-end governance for core applications | Manages the entire idea-to-production lifecycle as a governed factory, rather than a siloed prototyping tool with security handled app by app |
| Gallop Intelligence | Competes only in the modernization use case and anchors success to technical parity rather than a documented, auditable fidelity baseline | ForgeScore ties modernization to an 8-dimension technical fidelity assessment that includes security, not technical guesswork |
For a secure software factory conversation specifically, the two most relevant comparisons are 8090 and Retool AI, since both intersect directly with governance of AI-generated code in production environments.
8090 has moved fast this year, and its most recent funding and platform messaging lean heavily into governance, audit trails, and compliance for regulated industries, which is a meaningfully different posture than the rapid-generation positioning reflected in Forge’s current competitive messaging.
Retool AI’s own research on the state of AI governance found that a majority of technical leaders want security and access controls centralized in a platform layer beneath generated applications, and that only a minority of organizations currently govern at that level.
That data point supports the broader argument this article makes, but it also comes from Retool itself acknowledging a gap in the category it competes in, which is worth citing carefully rather than treating as a knockout against them specifically.
The Bottom Line: A Secure Software Factory Has to Govern the Code Itself
The original definition of a secure software factory was built for a world where the biggest risk was a compromised build pipeline or an unverified dependency. That risk has not gone away. But it has been joined by a bigger one: code that was never reviewed against an authoritative specification, generated by an agent that has no memory of the last policy it violated, shipped at a volume no human review process was sized to catch.
Venkat Gopalan, Chief Digital, Technology, and Data Officer at Belcorp, described what his organization actually needed as more than faster code.
It needed an AI-driven SDLC that accelerates time to market, delivers measurable business outcomes, and lets talent focus on strategic, high-value work, carrying business intent from concept to cloud without losing governance along the way.
That is the real bar for a secure software factory in 2026. Not whether the build pipeline is signed and verified, though it should be. Whether every line of AI-generated code flowing through that pipeline can be traced back to an approved specification and a specific human decision, at whatever speed the agents are actually running.
Frequently Asked Questions
What makes Forge different from a traditional AppSec or DevSecOps tool?
Traditional AppSec tools scan code after it exists, checking for known vulnerability patterns. Forge governs code before it merges, requiring AI-generated changes to satisfy explicit architectural and behavioral constraints and mapping every agentic action to corporate policy and regulatory mandates in line, rather than catching issues in a later review pass.
What makes Forge different from 8090?
8090 has historically prioritized rapid app generation speed, and its guardrails against unmanaged architectural drift and security exposure have been a documented gap. Forge’s Work Orders provide a specific, machine-auditable license for every AI agent action, moving execution from unmanaged speed to governed production.
What makes Forge different from Retool AI?
Retool AI is optimized for internal admin tools and prototypes, which creates shadow IT risk and lacks end-to-end governance once those tools become business-critical. Forge manages the entire idea-to-production lifecycle as a governed factory, so security and compliance controls apply consistently rather than being configured app by app.
Does using Forge mean replacing our existing security tools?
No. Forge integrates with the tools your team already uses, including Cursor, Claude, GitHub Copilot, and VS Code, along with your existing CI/CD pipelines and cloud or on-premises environments. Forge governs the AI-SDLC around those tools and existing DevSecOps processes rather than replacing them.
Does Forge train on our proprietary code or architectural data?
No. Proprietary code, intent, and architectural data stay private and are never used to train any foundational AI models.
How does Forge handle compliance and regulatory requirements?
Forge structurally maps every agentic action to an organization’s corporate policies and regulatory mandates, making AI-generated code auditable and compliant before it reaches production, rather than reviewing for compliance after the fact.
We already run scanners and manual review. Why do we need a governance layer on top of that?
Scanners catch known vulnerability patterns, and manual review works at human scale. Neither is built to evaluate whether a specific AI-generated change matches an approved specification, or to keep pace with agents producing changes faster than a review team can process them. Forge is built to close that specific gap, structurally, rather than adding another scan to the pipeline.
