AI-powered vulnerability discovery is advancing so quickly that finding security flaws may soon be the easy part. The harder challenge is proving those vulnerabilities are real, determining which ones matter and getting fixes into production before the backlog becomes unmanageable.
Microsoft's Frontier Offensive Research & Generative Exploitation (FORGE) Lab is confronting that problem at scale.
Between May and September 2026, the lab helped discover Windows vulnerabilities and assigned 140 CVEs, including 52 addressed in September's security release. Its researchers also submitted 155 internally validated vulnerability reports across 23 open-source projects, including the Linux kernel.
Those results form the backdrop for Taesoo Kim's presentation at [un]prompted II in San Francisco, From DARPA AIxCC to Microsoft FORGE Lab: Lessons Building Hyperscale AI Code Scanning Tools.
Kim, Microsoft's vice president of security research and leader of FORGE Lab, is examining what happens when autonomous vulnerability discovery moves beyond research competitions and into the daily operations of one of the world's largest software companies.
The answer is increasingly clear: Finding more vulnerabilities does not automatically make software more secure.
Full coverage of [un]prompted II:
Bill Brenner
From DARPA victory to Microsoft's security pipeline
Kim's journey to Microsoft began with Team Atlanta's victory in DARPA's AI Cyber Challenge (AIxCC), a two-year competition designed to advance autonomous vulnerability discovery and remediation.
The team, which included researchers from Georgia Tech, built AI systems capable of analyzing complex software, identifying vulnerabilities and generating repairs.
The scale of that effort was extraordinary. According to Kim, Team Atlanta consumed more than 100 billion tokens using a single OpenAI model during the competition, with additional models pushing the overall total higher.
But winning AIxCC was only the beginning.
After the competition, Kim and several teammates joined Microsoft to establish FORGE Lab, bringing lessons from the competition into a production environment with access to enormous proprietary and open-source codebases.
Their central technology is MDASH, Microsoft's multi-model, multi-agent vulnerability discovery and remediation system.
Unlike a conventional code scanner or a single large language model instructed to find bugs, MDASH coordinates more than 100 specialized agents, each focused on particular vulnerability classes or research tasks.
Some agents investigate specific bug patterns. Others evaluate potential findings, challenge conclusions or generate evidence that a vulnerability can actually be triggered.
The system also incorporates traditional program-analysis techniques, including code graphs and data-flow analysis, rather than relying entirely on expensive model reasoning.
That combination is central to Kim's argument: AI vulnerability discovery becomes practical at scale when specialized reasoning is combined with deterministic tools and an engineering pipeline capable of processing the results.
140 Windows CVEs, and the limits of finding more bugs
Microsoft's October 7 research report documents FORGE Lab's rapid expansion into operational vulnerability research.
The Windows CVEs associated with its work increased across successive monthly security-release cohorts, reaching 52 in September alone.
Beyond Windows, FORGE researchers submitted 155 internally validated reports spanning 23 open-source projects. At the time of the report, 93 reports across 14 projects or project families had received documented maintainer acknowledgment or acceptance.
Affected projects included Linux, curl, Node.js, SQLite, FFmpeg, Rust, vLLM and llama.cpp, among others.
Those figures demonstrate that AI-assisted research can produce findings across very different software environments.
But they also expose the limits of measuring success by vulnerability counts.
A scanner can generate thousands of suspicious findings. If those reports cannot be reproduced, reviewed or converted into patches, the result may be more work for already overburdened security teams.
Microsoft's research describes a particularly revealing example: One internal project used abstract syntax tree analysis to eliminate approximately 45% of duplicate findings across multiple scans of the same code.
That reduced unnecessary work for proof-of-concept generators and human reviewers.
The lesson is that scaling AI vulnerability discovery requires more than adding agents or increasing compute budgets. It requires controlling the volume and quality of findings entering the remediation pipeline.
Why Microsoft's AI agents argue with each other
One of MDASH's more interesting architectural decisions involves having agents challenge one another.
In a July interview with Microsoft's Command Line publication, Kim explained that the system uses specialized personas representing different perspectives, including an offensive security researcher and a software developer.
The offensive agent argues that a finding represents a legitimate security vulnerability. The developer-oriented agent challenges that conclusion, examining whether the behavior is intentional, reachable or genuinely exploitable.
The objective is not to generate a more convincing written report. It is to reduce false positives and identify findings that deserve further investigation.
MDASH also includes proving agents designed to generate inputs that reproduce suspected vulnerabilities.
For example, a scanner might identify a potential flaw in a PDF parser. A proving agent can attempt to create a specially crafted PDF that triggers the vulnerable behavior.
That moves the finding beyond a plausible explanation toward reproducible evidence.
Even then, a crash does not necessarily establish exploitability or security impact. Further analysis is required to determine what an attacker could actually accomplish.
Kim's approach combines AI reasoning with traditional analysis and executable tests to reduce uncertainty at each stage.
That is a substantial departure from the familiar model of AI generating long lists of potential vulnerabilities and leaving humans to determine which findings are real.
Linux kernel bugs for $3.61 apiece
Perhaps the most striking figures in Microsoft's research concern the cost of automated vulnerability validation.
MDASH identified thousands of suspicious locations in the Linux kernel, with validation agents producing supporting evidence for 627 findings.
For a subset of 182 confirmed crash findings, generating a proof of concept cost an average of $3.61 in model usage and took 21.5 minutes per successful case.
For six selected cases involving tests of potential local privilege escalation, automated exploit-generation work averaged $8.56 and 25.4 minutes.
The evaluations used GPT-5.5 without extensive task-specific tuning.
Those numbers require context. They reflect successful cases and exclude initial screening, failed or filtered candidates, human investigation and patch preparation. They are not the total cost of finding and fixing a vulnerability.
Nevertheless, they suggest that a meaningful part of vulnerability validation can be automated at relatively low marginal model cost.
That could have significant consequences for software security.
If researchers can cheaply reproduce large numbers of potential vulnerabilities, organizations will need to reconsider how they prioritize review, coordinate disclosure and allocate remediation resources.
The bottleneck moves from whether a machine can find a problem to whether the organization can do something useful with the finding.
Three lessons from operating AI vulnerability research at scale
Microsoft's research identifies three major changes required to turn autonomous vulnerability discovery into a sustainable security capability.
1. Measure validated fixes, not scanning volume
The first shift is from demonstrating that AI can find difficult vulnerabilities to repeating those results across large, complex software environments.
More scanning agents can generate more candidates without increasing the number of vulnerabilities that reach remediation.
Microsoft argues that useful measures include duplicate rates, rejected findings, validated defects, unresolved queues and the time required to move a finding through each stage.
The goal is not the largest possible collection of AI-generated vulnerability reports. It is a steady flow of reproducible findings that development teams can investigate and fix.
2. Spend AI reasoning where it removes uncertainty
The second shift concerns what Microsoft calls reasoning economics.
Running powerful AI models repeatedly over large codebases is expensive. But simply minimizing token usage can also be counterproductive if it produces incomplete findings that require extensive human investigation.
MDASH attempts to allocate work according to the problem being solved.
Traditional analysis tools can identify callers, data flows and other structural relationships more efficiently than asking an LLM to reconstruct that information.
More powerful models can then focus on problems requiring deeper reasoning, such as whether a suspected vulnerability is reachable under specific conditions.
Microsoft is also exploring how validated findings, rejected reports, reviewer feedback and remediation outcomes can improve future specialized models.
The objective is to spend reasoning capacity on resolving meaningful uncertainty rather than repeatedly generating analysis that does not change a decision.
3. Make remediation part of the AI learning loop
The third shift may be the most consequential.
Microsoft argues that validation and remediation cannot remain disconnected processes occurring after AI discovers a vulnerability.
Instead, findings should move through automated verification, human review, patch development and regression testing, with each stage returning useful evidence to the system.
A failed reproduction should explain why the finding failed. A rejected report should help the system recognize similar false positives. A successful patch should provide evidence that improves future vulnerability discovery and repair.
That requires integrating AI research systems with actual software builds, release processes and development teams.
It also requires retaining human accountability for assessing security impact, reviewing changes and deciding whether a proposed fix is safe to deploy.
The objective is not to eliminate security engineers or software maintainers. It is to reduce the repetitive work that prevents them from concentrating on the decisions requiring expertise.
Open source presents an even harder challenge
The difficulty of turning AI discoveries into fixes becomes particularly apparent in open-source software.
Unlike Microsoft's internal Windows development environment, open-source projects have different build systems, maintainer expectations, disclosure policies and review capacities.
Microsoft's research describes work through Akrites, a Linux Foundation initiative supporting coordinated vulnerability disclosure and remediation for critical open-source projects.
FORGE submitted nine Linux findings with internally assessed CVSS scores above 7.0 through the initiative.
One of those submissions became the first Akrites report to result in a patch merged into the Linux kernel.
That milestone illustrates the difference between discovering a vulnerability and getting it fixed.
A credible report must reach the appropriate maintainers, provide reproducible evidence, explain the security implications and fit the project's remediation process.
Microsoft also organized an internal open-source bug-hunting initiative involving 50 participants, who produced 39 reports across six projects. Those findings were included in the broader total of 155 reports.
The initiative reinforced an operational lesson: AI security research will not scale if researchers simply overwhelm maintainers with more reports.
Research teams must absorb more of the validation, coordination and remediation burden themselves.
AI could change the balance between attackers and defenders
Kim's work points toward a potentially significant change in software security.
For decades, defenders have struggled to identify and eliminate vulnerabilities across enormous codebases while attackers needed to find only a small number of exploitable weaknesses.
Autonomous vulnerability discovery could help shift that balance by allowing software developers to identify more weaknesses before release.
But that outcome is far from guaranteed.
Attackers can also use increasingly capable AI systems to discover vulnerabilities. And defensive scanning provides limited benefit if organizations cannot validate findings and deliver fixes quickly enough.
The critical advantage will come from integrating discovery, proof, remediation and release into a continuous process.
That is what distinguishes Microsoft's current FORGE Lab work from the research competition that helped launch it.
DARPA AIxCC demonstrated that autonomous systems could discover and repair vulnerabilities.
Microsoft is now confronting the much harder problem of making that capability work repeatedly across real software, real development teams and real release schedules.
![[un]prompted II: Full Coverage](https://storage.ghost.io/c/ab/67/ab676516-71e3-473d-8f73-9e0692f5aaee/content/images/size/w1304/format/webp/2026/10/20db4c11-e6e0-4989-9cf5-9b6e767a8f5f.png)
![AI Agent Security Gaps Take Center Stage at [un]prompted II](https://storage.ghost.io/c/ab/67/ab676516-71e3-473d-8f73-9e0692f5aaee/content/images/size/w1304/format/webp/2026/10/Screenshot-2026-10-26-at-9.31.22---AM.png)
