What happened
Factory’s November 10, 2026 announcement introduces Security Factory, available to a select group of customers in Private Preview. The product is aimed at large engineering organizations whose security findings and operational context are spread across scanners, asset inventories, threat intelligence, issue trackers and team conversations. Factory frames the problem as the manual work after a scanner raises a finding: validating it, assessing impact, assigning ownership and coordinating a safe change while remediation competes with other engineering work.
The first stage, called Signals, connects to existing tools through Connectors. Factory says it brings findings from static-analysis, dependency, secret and infrastructure-security tools together with context from threat intelligence, asset inventories, issue trackers and team conversations. Security Review applies STRIDE, OWASP and supply-chain security methodologies to pull requests and full-codebase audits. The stated purpose is to investigate findings in the context of a specific environment rather than treating a scanner alert as a complete account of risk.
The second stage, Triage, investigates reachability, exploitability and attack paths. Factory gives the example of an internet-facing vulnerable service combined with an overprivileged service account: investigating either issue alone could miss a route from the service to credentials and sensitive systems. Its Workstreams coordinate parallel investigations and specialized tasks, while durable state and shared context preserve progress, evidence and unresolved questions across longer investigations. For reproduction and exploit testing, Factory lists Droid Computers, an OS-level sandbox, or a customer’s cloud using OpenCompute. It says the output is a validated finding backed by evidence about affected systems, exploitability and potential access.
The third stage, Remediation, passes that evidence into Factory’s Automations, SDK, Droid CLI and desktop application. Agents can propose code patches, dependency upgrades, permission changes, credential rotations or infrastructure corrections; test against original exploit conditions; check for regressions; and prepare patches or pull requests for engineering review. Organizations can set autonomy levels, from plans requiring human approval to pull-request creation and deployment within approved policies. Factory also cites secure execution, configurable policies, audit trails and human approval as enterprise controls. The announcement gives no price or general-availability date; interested teams are asked to contact an account manager for preview access.
What the archive adds
New Runtime’s earlier coverage of Claude Security’s continuous scans and fix tracking (October 22, 2026) covered security findings tracked through fixes in connected repositories. Security Factory is a new product announcement on a related problem: it emphasizes carrying investigation context and evidence into remediation, rather than only tracking findings and fixes.
Trend signal
This supports AI-native organizations moving toward review and orchestration: the product’s workflow divides investigation, remediation and verification, while allowing humans to set approval and deployment boundaries. It is an announced design, not evidence that review capacity or delivery outcomes have improved in production.
Why now
Factory’s announcement argues that models are becoming more capable at finding vulnerabilities, while the next opportunity is fixing them. Its timing rationale is that identifying a possible issue does not resolve the manual validation and coordination work that follows. The announcement presents Security Factory as an application of Factory’s existing agent infrastructure to that downstream work.
Why it matters
For security and engineering teams, a finding is useful only if someone can establish whether it is exploitable, determine what it exposes, and make a safe correction. Passing reproduction evidence and affected-code context directly into remediation could reduce duplicated investigation and help teams prioritize demonstrated risk rather than scanner severity alone. The workflow also makes a consequential boundary explicit: agents may be limited to proposing a plan, creating a pull request or deploying only under approved policies.
That is a meaningful design direction for teams considering agent-led security work, but it is not yet a demonstrated reduction in backlog or vulnerability exposure. Private preview means most teams cannot evaluate it directly, and Factory publishes no performance, accuracy or cost figures. The practical question is whether the evidence survives the handoff into a fix that passes both exploit-specific tests and ordinary regression checks.
Limits and uncertainty
Factory does not report customer outcomes, vulnerability counts, remediation times, false-positive rates, regression rates or costs. It does not specify which connectors are available, how findings are prioritized in practice, or how the system handles disagreements between scanner output and agent investigation. Private Preview is limited to select customers; the announcement gives no general-release date, price or stated eligibility criteria beyond contacting an account manager. The claimed ability to validate exploitability and prepare safe fixes is not independently assessed here.
Reader takeaway
Security Factory’s central proposition is continuity: preserve investigation evidence and carry it into a tested fix instead of restarting the work at remediation. The announcement is a product design and private-preview offer, not proof of improved security outcomes. Teams should evaluate whether any agent-assisted fix is reproducible, regression-tested and bounded by explicit human approval and deployment policies.