MDASH: multi-model agentic vulnerability discovery reaches production defense

What is this?

MDASH — Microsoft Security’s “multi-model agentic scanning harness” — is an AI system that audits source code for exploitable vulnerabilities. Microsoft’s Autonomous Code Security team unveiled it on May 12, 2026, alongside a concrete result: 16 vulnerabilities across the Windows networking and authentication stack, four of them Critical, all shipped in that day’s Patch Tuesday. At Microsoft Build on June 2, 2026, the company expanded the private preview and wired MDASH findings into the Defender portal.

What makes MDASH worth reading about is not a single bug. It is the claim, backed by numbers, that AI-driven vulnerability discovery has crossed from research demo into production-grade defensive engineering — and the design lesson Microsoft draws from it: the durable advantage lives in the system around the model, not in any one model.

How it works

MDASH is a staged pipeline, not a single prompt. Microsoft describes it running more than 100 specialized agents across an ensemble of frontier and distilled models, each stage with its own role, tools and stop criteria.

A Prepare stage ingests the target, builds language-aware indices, and reconstructs the attack surface by analyzing past commits. A Scan stage runs auditor agents over candidate code paths, emitting findings with hypotheses and evidence. A Validate stage introduces debater agents that argue for and against each finding’s reachability and exploitability — model disagreement is treated as signal rather than noise. A Dedupe stage collapses semantically equivalent findings, and a Prove stage constructs and runs triggering inputs where the bug class allows it, so a candidate finding becomes a demonstrated one rather than a triage-backlog entry.

Two properties do most of the work. First, an ensemble of diverse models: a strong reasoner for auditing, cheaper distilled models for high-volume debate passes, and a second independent frontier model as a counterpoint. Second, extensibility through domain plugins — for example a component-specific proving plugin that encodes filesystem invariants the base models cannot infer on their own. Because targeting, validation, dedupe and proving are model-agnostic by construction, swapping in a newer model is a configuration change rather than a rebuild.

Why it matters

The evidence Microsoft published is unusually testable for this genre. On a private device driver seeded with 21 deliberately injected bugs — code that never appeared in any model’s training data — MDASH reported all 21 with zero false positives in that run. On retrospective benchmarks it recovered 96% of five years of confirmed Security Response Center cases in the CLFS logging component and 100% of seven cases in the TCP/IP stack. On the public CyberGym benchmark of 1,507 real-world reproduction tasks it reached 88.45%, the top published score at launch and roughly five points ahead of the next entry; by Build, Microsoft reported that figure had climbed above 96%.

The defensive upside is obvious: five years of the bugs that actually mattered, re-found by a system that can also prove them. The dual-use tension is just as real. The two flaws Microsoft detailed — a remote unauthenticated use-after-free in the Windows IPv4 receive path, and a pre-authentication double-free in the IKEv2 keying service reachable over UDP as LocalSystem — are exactly the class of deep, cross-file, concurrency-sensitive bugs that single-model scanners miss and that skilled offensive researchers prize. A harness that finds them at scale is a defensive asset when defenders run it first and a threat model when the same capability diffuses. Microsoft deliberately withheld exploitation details for both, consistent with responsible disclosure; both were patched before publication.

Defenses

For defenders the practical takeaways are concrete. Evaluate AI vulnerability tools by what they do with a model — validation, deduplication, proof construction — not by which model they use; a scanner that stops at candidate findings just relocates the triage burden. Ground any capability claim on data the model has not seen: seeded private targets and retrospective recall against your own historical case database are far more informative than public leaderboards alone. Treat proof-of-reachability as the acceptance bar, since unproven findings inflate backlog without reducing risk.

Assume offensive parity is coming, and shorten the window it exploits: prioritize the bug classes these systems find best — memory-safety and concurrency defects on network-reachable, unauthenticated paths — with memory-safe languages, fuzzing and hardened reassembly logic. Finally, note the systemic risk flagged by outside reviewers: an orchestration layer coordinating 100+ agents across identity, cloud and code has a large blast radius, so the governance and permission boundaries around such a harness must be designed before deployment, not retrofitted after an incident.

Status

The vulnerabilities below are among the Critical findings Microsoft attributed to MDASH in its May 12, 2026 disclosure. They are listed here only as references; all were patched before publication.

Component	Nature	Reference	Status
Windows TCP/IP (IPv4 receive)	Remote unauth. use-after-free → RCE	CVE-2026-33827	Patched
Windows IKEv2 keying service	Pre-auth double-free → LocalSystem RCE	CVE-2026-33824	Patched
Windows Netlogon (CLDAP)	Unauth. stack overflow → RCE	CVE-2026-41089	Patched
Windows DNS client	Crafted UDP response → heap OOB → RCE	CVE-2026-41096	Patched

MDASH remains in limited private preview (expanded at Build 2026). Primary source: Microsoft Security Blog, published May 12, 2026, updated June 3, 2026.