Microsoft’s FORGE Lab update describes a security pipeline operating at a scale that would have sounded experimental a short time ago: 140 Windows vulnerabilities assigned CVEs from May through September, plus 155 internally validated reports submitted across 23 open-source projects.[1]
The headline is not that an AI system can produce more suspicious code paths. Static analysers and fuzzers have done that for years. The consequential question is whether a candidate can be converted into a reproducible trigger, a credible causal explanation, a severity judgement, the right maintainer conversation and a patch that can be shipped without breaking the software. Discovery has value only when the rest of that chain can keep pace.[1]
FORGE’s reported operating snapshot
| Measure | Value | Context |
|---|---|---|
| Windows CVEs across five servicing cohorts | 140 | The monthly cohorts run from May through September 2026; Microsoft warns they reflect announcement and servicing timing, not discovery throughput.Source 1 |
| September Windows cohort | 52 CVEs | The largest monthly servicing cohort in the period, including 2 Critical and 50 Important vulnerabilities in the published chart.Source 1 |
| Open-source reports submitted | 155 across 23 projects | Each report had been internally validated before submission.Source 1 |
| Maintainer acknowledgement or acceptance | 93 reports across 14 projects or project families | This was the documented status at the time of writing, not a final outcome for every remaining report.Source 1 |
| Hackathon output | 39 reports from 50 participants across 6 projects | Those reports are included in the 155-report total and should not be added again.Source 1 |
| Successful proof-of-concept validation | Average $3.61 and 21.5 minutes | Measured model cost and elapsed time for successful Linux-kernel crash cases in the described validation work.Source 1 |
A finding is not yet a vulnerability programme
A model can flag an out-of-bounds access, generate an input that crashes a build and draft a report. A maintainer still needs to know whether the crash is reachable in a supported configuration, whether the root cause is distinct from an existing issue, what versions are affected and whether the proposed patch introduces a regression. The more candidates an agent produces, the more important these distinctions become.
At the reported snapshot, 93 of 155 internally validated open-source reports had documented maintainer acknowledgement or acceptance. That is 60.0%, calculated as 93 divided by 155. The arithmetic does not measure a false-positive rate: some unacknowledged reports may still have been under review, some acknowledgements may not become security advisories, and the projects differ in review capacity. It is better read as a picture of pipeline progress at one date.[1]
The evidence chain from candidate to protection
| Stage | Minimum useful evidence | What can still fail |
|---|---|---|
| Discovery | A suspicious path, crash or policy violation | The signal may be duplicate, unreachable or caused by the test harnessSource 1Source 2 |
| Validation | A stable reproducer, affected versions and a causal explanation | The build, environment or trigger may not reproduce for the maintainerSource 1 |
| Triage and disclosure | Severity context, ownership and confidential coordination | Review queues, project capacity and downstream dependencies can delay actionSource 1Source 3 |
| Remediation | A patch with tests and a release path | A local fix can create regressions or leave related variants unresolvedSource 1 |
| Deployment | An update reaches exposed systems | Operators may delay, misconfigure or be unable to apply the fixSource 4 |
Reasoning economics is broader than token price
FORGE reports that MDASH, its multi-model agentic scanning harness, produced evidence for 627 findings during validation work. For successful Linux crash proofs of concept, model cost averaged $3.61 and elapsed time averaged 21.5 minutes. Six selected local privilege-escalation tests averaged $8.56 and 25.4 minutes. Those are useful production measurements because they attach cost and time to an accepted output, not merely to tokens consumed.[1][2]
Even those figures leave out important labour. A reviewer must provision a build, inspect the trace, judge exploitability, contact the project, negotiate a patch and sometimes support coordinated disclosure. If agent output triples but maintainer time does not, the queue can grow while the scan looks more productive. The economically relevant denominator is a safely remediated vulnerability, not a generated report.
Human coordination becomes an engineering component
The FORGE hackathon involved 50 participants and produced 39 reports across six projects. The value was not simply parallel model access. Participants had project setup guidance, review channels and a route into maintainers’ workflows. One Linux report became the first submission through the Linux Foundation’s Akrites process to result in a patch merged into the kernel. That example shows why an ecosystem can be more consequential than an isolated exploit demo.[1][3]
A better dashboard for AI security research
A serious programme should separate at least six counts: candidates generated, candidates reproduced, distinct root causes, reports submitted, fixes accepted and updates deployed. It should also record median reviewer time, time to first maintainer response, regression rate and the share of reports that need substantial human reconstruction. Those measures reveal whether automation is relieving work or merely moving it downstream.
FORGE’s results support a stronger claim than ‘AI finds bugs’ and a narrower claim than ‘AI automates security’. Agents can now contribute meaningfully to discovery and validation at scale. The frontier has moved to the organisational machinery that turns evidence into protection. The teams that win will not be those with the loudest scanner; they will be those whose validation and remediation loops are designed to absorb what the scanner finds.
Sources & further reading
- 3 lessons from frontier AI vulnerability research Microsoft Security Blog · 7 Oct 2026 · Accessed 8 Oct 2026
- Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark Microsoft Security Blog · 12 May 2026 · Accessed 8 Oct 2026
- Akrites Linux Foundation · Accessed 8 Oct 2026
- Microsoft Security Response Center Microsoft · Accessed 8 Oct 2026