What happened
Factory’s November 12, 2026 announcement introduces the Cyber Defense Network as an ecosystem of cybersecurity companies whose findings connect into Security Factory. Factory says the aim is to bring security intelligence directly into engineering workflows, helping organizations move from vulnerability discovery to tested, merge-ready fixes. It positions the network as a connection between tools that identify and prioritize security risks and Factory’s engineering-agent workflow for acting on those risks.
Factory lists Snyk, Palo Alto Networks, Semgrep, Cogent, Casco, DepthFirst, Detail, and others as founding partners. The announcement does not say that every listed partner has a generally available integration, describe the technical form of each connection, or list which products from those companies participate. Instead, it describes the network at the ecosystem level: partner findings can flow into Security Factory while organizations retain their existing security tools and engineering workflows.
The company describes a three-stage workflow. In the signals stage, security partners surface vulnerabilities and prioritized findings across an organization’s software ecosystem. In triage, Factory Droids investigate those findings, establish whether a vulnerability is reachable, and determine what must change. In continuous remediation, the Droids implement code changes and validate them through testing, producing fixes for engineering teams to review and merge.
That distinction matters. Factory is not presenting the network as a replacement for scanners, security platforms, repositories, or review processes. Its announcement says the intended outcome is to automate more of the work needed after a finding is created, while leaving the organization’s tools and workflows in place. Human engineering review and merge remain explicit parts of the stated flow. Factory does not say that Droids autonomously deploy fixes to production or close findings without review.
Factory says it plans to expand the network to additional cybersecurity innovators and model providers. It calls the launch an extension of Security Factory and part of a broader investment in autonomous cybersecurity. The company argues that AI is accelerating both software development and vulnerability discovery, increasing the need for agents that help remediate risks quickly and safely. The announcement also invites security leaders, innovators, and companies to join the network. It gives no price, general-availability date, integration onboarding process, or usage limits.
What the archive adds
New Runtime’s earlier coverage on November 10 described Security Factory as a private-preview product linking security signals, investigation, remediation, and verification in one workflow. This is a new fact on that known story: Factory is adding named external security companies as prospective sources of the signals that begin the workflow.
Trend signal
This supports agent-ready software exposes capabilities. Factory describes a capability boundary in which security products contribute prioritized findings and an agent system performs bounded engineering work on them. The useful question is not whether a model can identify a flaw, but whether systems can pass actionable, permissioned work between detection, triage, validation, and review without losing control or context.
Why now
Factory ties the timing to faster software development and vulnerability discovery. Its argument is that more findings make the work after detection harder to manage at scale, so the integration target is remediation rather than another detection surface. The announcement does not identify a triggering incident, regulatory deadline, or customer deployment behind the launch.
Connections to other events
An earlier New Runtime note on November 12 examined Shopify’s use of AI agents to attack its own production infrastructure in search of security weaknesses: Cyber Chaos Monkey. That work concerns finding weaknesses internally; Factory’s announcement concerns routing findings from specialist security products into an engineering remediation flow. Together, they point to agent use on both sides of the security loop, although neither establishes a common operating standard.
Why it matters
For engineering and security teams, the significant proposed change is the handoff. A scanner finding normally creates work that must be assessed, routed, reproduced, fixed, tested, and reviewed across several systems and owners. Factory’s model would make that finding the input to an investigation and a proposed code change, potentially reducing manual coordination around repetitive remediation.
The value will depend less on a fluent patch than on the controls around it. Teams need reliable reachability judgments, scoped repository permissions, reproducible test evidence, policy checks, and a clear owner for accepting or rejecting a change. A false reachability call can waste scarce review time; an overly broad agent permission can create a more serious problem than the original finding. Factory explicitly retains review and merge in its description, which is a useful boundary, but it has not described how that boundary is enforced.
For builders evaluating security agents, this announcement is best read as an integration direction. It suggests that security platforms may increasingly compete on whether their findings can become structured work for remediation systems, not only on detection quality or dashboards. Teams should evaluate the complete loop from signal quality to validated change rather than buying an autonomous-remediation claim in isolation.
Limits and uncertainty
Factory does not disclose partner integration status, eligibility, availability terms, pricing, or a general-availability date for the network. It provides no figures for findings processed, vulnerabilities judged reachable, proposed fixes accepted, false positives avoided, time saved, or risk reduced. The announcement also does not identify the models used by Factory Droids, the permissions they receive, the repositories or languages supported, or the tests and validation methods used before a fix is presented for review.
The company’s description establishes an intended workflow, not an independently measured operational outcome. It is also unclear whether every founding partner supplies the same type of finding or whether each integration has comparable triage and remediation coverage. Prospective users would need product documentation and deployment evidence to assess those details.
Skill to build now
Map one remediation path in your own organization this week: from a scanner finding to triage, code change, test evidence, reviewer, and merge decision. Record the systems crossed, the permissions required, and the evidence a reviewer needs to accept a fix. That map will expose whether an agent integration can remove a real handoff without bypassing a control that your security process depends on.
Reader takeaway
Factory is extending Security Factory into a partner-network model where external vulnerability findings can initiate agent-led investigation and tested remediation. The news is a proposed connection surface between security detection and engineering work, not proof that autonomous fixes are safe, broadly available, or effective at production scale.
Open question
Which partner integrations are live, and what technical and permission boundaries govern a Droid from receiving a finding to proposing a merge-ready fix?