Generated by Codex with GPT-5

What happened

Microsoft’s official Security Blog published Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark, a post about MDASH, Microsoft’s multi-model agentic scanning harness for vulnerability discovery and validation.

The post is interesting because it treats AI-assisted security review as a production engineering system rather than a smarter static analyzer. MDASH is not framed as one frontier model pointed at a repository. It is a pipeline that prepares a target codebase, builds indices, maps attack surfaces, runs specialized auditor agents over candidate paths, sends findings through adversarial validation, deduplicates semantically similar reports, and then tries to prove that a vulnerability can actually be triggered.

That staging is the core design choice. Microsoft says the harness uses more than 100 specialized agents across frontier and distilled models. Some agents look for suspicious paths, others debate reachability and exploitability, and still others construct proof inputs when the bug class allows it. The model ensemble matters, but the important product is the orchestration around the models: role-specific prompts, tools, stop criteria, domain plugins, and evidence gates that turn a speculative model finding into something a security engineering team can patch.

The security setting makes that difference unusually concrete. A low-quality scanner creates work for already overloaded triage teams. Microsoft emphasizes that Windows, Hyper-V, Azure, and related components contain private implementation details that are not likely to be present in model training data, and that findings have to flow into real ownership, review, and Patch Tuesday processes. In that environment, a useful AI system has to reason across kernel conventions, reference ownership, IPC trust boundaries, codec state machines, and component-specific invariants. It also has to keep false positives low enough that teams can trust it.

Microsoft reports several evaluation signals. On a private StorageDrive test driver with 21 deliberately seeded vulnerabilities, MDASH found all 21 with no false positives in that run. On retrospective scans of pre-patch Windows components, it recovered 96% of 28 confirmed clfs.sys MSRC cases and all 7 confirmed tcpip.sys cases in the evaluated set. On CyberGym, a public benchmark of real-world vulnerability reproduction tasks across OSS-Fuzz projects, Microsoft reports an 88.45% success rate using generally available models, ahead of the next listed score at the time of writing.

The strongest evidence is not only benchmark performance. Microsoft says its May 12, 2026 Patch Tuesday cohort included 16 CVEs found with MDASH across the Windows networking and authentication stack, including critical remote-code-execution flaws in tcpip.sys, ikeext.dll, netlogon.dll, and dnsapi.dll. That turns the system from a demo into an operational vulnerability-discovery pipeline: the harness produced findings that survived enough investigation to land in a public security release.

The post’s two technical deep dives show why the architecture needs more than a single model pass. One tcpip.sys bug involved a remote use-after-free reachable through IPv4 Strict Source and Record Route handling. The issue depended on reference lifetime across non-obvious control flow and concurrent cleanup paths, so it was not visible as a simple release-then-use pattern inside one local snippet. The other bug involved an IKEv2 double-free caused by shallow-copying receive context across several files. In both cases, the decisive signal came from cross-file comparison, ownership reasoning, reachability analysis, and proof-oriented validation.

That is where MDASH’s plugin model matters. Microsoft describes domain-specific extensions, such as a CLFS proving plugin that knows enough about log-file layout and in-memory state to turn a candidate issue into a triggering artifact. This is a pragmatic boundary: foundation models should not be expected to internalize every private kernel invariant, but a harness can expose the right invariants as tools and structured context. The model reasons with the plugin; the plugin grounds that reasoning in executable checks.

Why it matters

The broader lesson is that AI vulnerability discovery is becoming a systems problem. Raw model capability helps, but Microsoft is arguing that durable value comes from the harness: target preparation, scoped agents, debate, deduplication, proof construction, benchmarks, and domain extensions. That architecture is portable across model generations because a new model can be A/B tested inside an existing workflow rather than requiring the whole security process to be rebuilt.

The post also clarifies why “find a bug” is the wrong unit of success for production security. A useful scanner has to find the right code region, explain the vulnerability, survive adversarial validation, produce enough evidence for triage, avoid duplicates, and often build a proof-of-concept input. Each stage removes a different class of failure. Debate filters out plausible but unreachable reports. Deduplication keeps teams from seeing the same root cause many times. Proving turns a candidate into an engineering priority rather than a vague backlog item.

There is an important evaluation takeaway as well. Microsoft explicitly separates private synthetic tests, retrospective recall on real patched vulnerabilities, public benchmark performance, and forward-looking Patch Tuesday output. None of those signals is complete by itself. A private planted-bug test controls for training-data contamination, but it can be artificial. Retrospective recall shows whether the system would have caught past mistakes, but not necessarily future ones. Public benchmarks make comparisons possible, but may contain harness-format artifacts. Real release output is the hardest to fake, but less controlled. Together, they make a more credible case than any single headline number.

The engineering pattern generalizes beyond security. Agentic systems become more reliable when the system decomposes work into specialized roles, uses disagreement as signal, gives models domain tools instead of only text, and evaluates end-to-end outcomes instead of isolated substeps. MDASH applies that pattern to vulnerability research, but the same structure is relevant to code review, incident response, migration planning, and other tasks where a model’s first plausible answer is far from enough.

Takeaway

MDASH is a reminder that the most useful AI engineering work often lives around the model. Microsoft’s system does not assume that a single agent can audit, reason, exploit, and patch reliably in one pass. It builds a workflow where many agents can inspect different facets of the problem, challenge each other, use domain plugins, and produce evidence that humans and release processes can consume.

For teams building AI-assisted engineering tools, the practical bar is rising. It is not enough for an agent to emit confident findings. The system needs provenance, validation, deduplication, reproducible proofs, domain-specific context, and metrics that connect model behavior to operational outcomes. In security especially, the value is not a clever bug report. The value is a finding that survives the path from scan to fix.