What MDASH Actually Is

Codename MDASH can sound like another artificial intelligence security product with a dramatic name. It is more specific, and more interesting, than that. MDASH, short for Multi-model Agentic Scanning Harness, is a Microsoft Security capability in Microsoft Defender that uses many specialized artificial intelligence agents and many large language models to reason over source code and find vulnerabilities that ordinary pattern matching often misses.

The product is the harness, not the model

MDASH was built by Microsoft’s Autonomous Code Security team and is offered to eligible Microsoft Defender customers. It extends the Defender command-line interface, or CLI, with agentic code scanning and sends findings into Microsoft Security Exposure Management, which is part of Microsoft Defender XDR, or extended detection and response.

The important architectural idea is that MDASH is not one large language model, or LLM, pointed at a repository. Microsoft describes it as a harness that coordinates more than 100 specialized artificial intelligence agents across an ensemble of frontier and distilled models. The harness decides how work is divided, how evidence is checked, how confidence is built, and how results are reported.

That distinction matters because model names change quickly. A security scanning system that depends on a single model inherits that model’s blind spots. A harness can use models as replaceable inputs while preserving the surrounding workflow: decomposition, cross-checking, exploitability reasoning, triage, and reporting.

What MDASH scans, and what it does not

MDASH analyzes source code. That is a narrow but essential point. It is not described as a scanner for compiled binaries, packaged Java archive files, or runtime memory images. Its job is to inspect the code that developers and platform teams maintain, then reason about whether a defect can become an exploitable vulnerability.

Traditional static application security testing, often called static analysis, is good at enforcing known rules and spotting recognizable patterns. MDASH is aimed at cases where the vulnerable path is not obvious from one line or one function. It may require following calls across files, understanding branches, tracking data flow, and asking whether an attacker could reach the dangerous state.

This does not make older techniques obsolete. Static analysis, fuzzing, manual review, threat modeling, and runtime detection still matter. MDASH adds a deeper reasoning layer for classes of bugs that are hard to reduce to simple signatures.

How a scan becomes a security finding

A typical MDASH workflow starts with a repository submitted through the Defender CLI. The harness then breaks the work into smaller tasks for specialized agents. Some agents may explore code paths, others may compare a suspected defect with known vulnerability patterns, and others may challenge whether the finding is actually exploitable.

The multi-model design is not just about producing more guesses. Independent model checks are used to increase confidence, reduce fragile single-model conclusions, and support exploitability assessment. In practical terms, MDASH is trying to answer not only whether code looks suspicious, but whether the suspicious code can plausibly be reached and abused.

When MDASH produces a finding, it includes supporting evidence and human-readable remediation guidance. It can also correlate code findings with deployment context in Microsoft Security Exposure Management so teams can prioritize what is exposed in the real world. It does not modify the environment or automatically remediate the issue; it is a read-only analysis capability.

The kinds of bugs it is built to catch

Microsoft positions MDASH for deep and complex vulnerabilities, especially those that resist direct pattern matching. Public descriptions emphasize memory-safety bugs such as use-after-free, double-free, and buffer overflow flaws. These are not new categories, but they remain dangerous because the exploit path can depend on subtle object lifetime, parsing, concurrency, and control-flow details.

The system has been applied to some of Microsoft’s most complex codebases, including Windows, Hyper-V, Azure virtualization and infrastructure, and Active Directory Domain Services. Those environments are large, old, performance-sensitive, and security-critical, which is exactly where simple checks often fail to see enough of the program to make a reliable judgment.

MDASH also draws on a knowledge base of past Common Vulnerabilities and Exposures, or CVEs, and patches. That does not make it a signature scanner. The point is to combine historical security knowledge with reasoning over the current code, rather than merely matching a known bad string or byte pattern.

• Use-after-free bugs, where code continues to use memory after it has been released.
• Double-free bugs, where the same memory is released more than once.
• Buffer overflows, where code writes or reads beyond the intended memory boundary.
• Logic flaws whose exploitability depends on calls, branches, and state spread across files.
• Network-reachable vulnerabilities where deployment context can change priority.

What Microsoft has publicly shown

Microsoft has published several signals about MDASH’s capability, each with a different kind of meaning. In one private StorageDrive test driver, a codebase Microsoft says had never been published and therefore should not have been in a model’s training data, MDASH identified all 21 deliberately injected vulnerabilities with zero false positives in that run.

Microsoft also reported retrospective recall results against historical Microsoft Security Response Center, or MSRC, cases in heavily reviewed Windows components. For clfs.sys, MDASH found 96 percent of 28 MSRC cases spanning five years. For tcpip.sys, it found 100 percent of 7 MSRC cases spanning five years.

On CyberGym, a public benchmark with 1,507 real-world vulnerability-reproduction tasks across 188 OSS-Fuzz projects, Microsoft reported an 88.45 percent success rate. At the time, that was the top published leaderboard score and about five percentage points ahead of the next entry at 83.1 percent, using generally available models.

These numbers are useful, but they should be read carefully. A retrospective recall study says the system would probably have helped on a known set of past issues. It does not guarantee the same performance on future code, new bug classes, or a different engineering environment.

The May 2026 Patch Tuesday signal

The strongest public sign that MDASH is more than a lab experiment came with Microsoft’s May 12, 2026 security release. Microsoft said MDASH helped researchers find 16 new vulnerabilities across the Windows networking and authentication stack.

Those vulnerabilities included four Critical remote-code-execution flaws in components such as the Windows kernel TCP/IP stack, tcpip.sys, and the Internet Key Exchange version 2 service, ikeext.dll. The broader cohort included 10 kernel-mode and 6 user-mode CVEs, and Microsoft said most were reachable from a network position without credentials.

This work involved the Autonomous Code Security team, Microsoft Offensive Research and Security Engineering, or MORSE, and Microsoft Windows Attack Research and Protection, or WARP. Several Autonomous Code Security team members came from Team Atlanta, which won the Defense Advanced Research Projects Agency, or DARPA, AI Cyber Challenge, also known as AIxCC.

For defenders, that Patch Tuesday cohort is important because it is forward-looking evidence. It shows MDASH contributing to newly disclosed vulnerabilities that were found, fixed, and shipped through a real security release process.

The decisions it changes for security teams

For a practitioner, the first decision is where MDASH fits in the existing secure development lifecycle. It should not be treated as a replacement for compiler hardening, static analysis, fuzzing, manual review, or incident response. A healthier pattern is to use it as another review layer for high-risk repositories, exposed services, complex parsers, kernel-adjacent code, authentication paths, and infrastructure components.

For a security leader, the more important decision is operational. A tool that produces deeper findings also needs owners, service context, triage rules, fix accountability, and a way to avoid dumping unactioned results on developers. The value is not only whether MDASH can find a bug; it is whether the organization can turn that finding into a prioritized fix before an attacker can exploit the same class of weakness.

The link to Microsoft Security Exposure Management is therefore not cosmetic. Code severity and runtime exposure are different signals. A severe bug in unreachable code and an important bug in an internet-facing path may demand different action. The useful question is how the scanning output changes patch order, engineering focus, and risk acceptance.

• Choose initial repositories where deep reasoning is likely to matter.
• Decide who validates exploitability and who owns remediation.
• Use exposure context to separate urgent risk from merely interesting findings.
• Keep existing static analysis and fuzzing programs in place.
• Track whether findings lead to fixes, not just whether they appear in a dashboard.

How to judge MDASH over time

The right way to evaluate MDASH is not to ask which single model it uses. Models will improve, regress, specialize, and be replaced. The better question is what the harness does with model output: how it decomposes work, checks itself, handles uncertainty, reasons about exploitability, and survives the arrival of the next model.

That is also the broader lesson for artificial intelligence in vulnerability discovery. The durable advantage is increasingly in systems that organize reasoning, evidence, and workflow around models. MDASH is Microsoft’s example of that idea applied to source-code security inside the Defender ecosystem.

Its promise is significant but bounded. It can help find difficult vulnerabilities, including zero-day and logic-flaw issues, and it can help teams prioritize them with runtime context. It is still a tool in a security program, not a substitute for engineering judgment, defense in depth, or disciplined patching.

Glossary

MDASH

Multi-model Agentic Scanning Harness, a Microsoft Security capability that uses coordinated artificial intelligence agents and models to analyze source code for vulnerabilities.

Large language model

An artificial intelligence model trained on large amounts of text and code that can generate, summarize, and reason about language-like inputs.

Agentic scanning

A scanning approach in which software agents break a task into steps, call models or tools, check intermediate results, and produce a final finding.

Static analysis

The examination of source code without running it, often using rules, patterns, data-flow analysis, or other code-inspection techniques.

CVE

Common Vulnerabilities and Exposures, the standard naming system for publicly disclosed cybersecurity vulnerabilities.

MSRC

Microsoft Security Response Center, the Microsoft organization that coordinates vulnerability response and security updates.

OSS-Fuzz

A service that continuously fuzz-tests open-source software projects to find reliability and security bugs.

Remote-code execution

A vulnerability class that can let an attacker run code on a target system from another machine.

Defender XDR

Microsoft Defender extended detection and response, a Microsoft security platform that correlates signals across security domains.