Tanium Tests Microsoft MDASH Agentic Vulnerability Scanner on Production Code

As reported by IT Brief Asia and detailed in Tanium's official announcement, the company is part of a small group of customers testing Microsoft’s autonomous vulnerability discovery engine against live production codebases and feeding operational insights back into the platform's development. Rather than treating AI code scanning as a magic wand that replaces human engineers, Tanium paired the MDASH preview with its own static and dynamic validation pipelines and specialist human review before routing confirmed findings into its secure development lifecycle.

For Windows administrators, DevSecOps architects, and CISO teams, this collaboration offers a fascinating look under the hood of how enterprise software vendors are responding to an uncomfortable reality: as artificial intelligence accelerates how code is written, it also accelerates how bugs are introduced and exploited.

What Exactly Is Microsoft Codename MDASH?​

If you have ever deployed a traditional Static Application Security Testing (SAST) tool, you already know its dirty little secret: it is essentially an over-caffeinated spellchecker. Rule-based and pattern-matching scanners are fantastic at spotting textbook syntax mistakes or well-known insecure functions within a single file, but they routinely choke on complex business logic, subtle authorization bypasses, and memory ownership bugs scattered across half a dozen source files. Worse, when you turn up their sensitivity, they bury your engineering team under an avalanche of false positives.

Microsoft built Codename MDASH—short for its multi-model agentic scanning harness within Microsoft Defender and Microsoft Security Exposure Management—to solve that exact reasoning gap. First detailed publicly by Microsoft Vice President of Agentic Security Taesoo Kim in May 2026, MDASH was developed by Microsoft’s Autonomous Code Security (ACS) team alongside its Offensive Research & Security Engineering (MORSE) and Windows Attack Research and Protection (WARP) groups. Notably, several ACS team members joined Microsoft from Team Atlanta, the group that won the DARPA AI Cyber Challenge by engineering autonomous cyber-reasoning systems.

According to Microsoft Learn documentation and Microsoft Security’s technical disclosures, MDASH does not rely on a single large language model trying to spot a vulnerability in one prompt pass. Instead, it operates as a structured, multi-stage pipeline orchestrated across an ensemble of frontier and distilled models:

• Prepare: The harness ingests the target repository, builds language-aware indices, maps the attack surface and threat models by analyzing commit histories, and ranks files by risk using call-graph analysis and code complexity metrics.
• Scan: More than 100 specialized auditor agents—such as injection auditors, memory-safety auditors, and authentication-bypass auditors—examine the prioritized code paths using multiple models. Each agent is tailored to a specific vulnerability class based on historical Common Vulnerabilities and Exposures (CVEs) and patch patterns.
• Validate: To keep engineers out of false-positive purgatory, MDASH uses taint analysis and type resolution via Language Server Protocol (LSP) servers alongside a second cohort of "debater" agents. These debaters actively argue for and against the reachability and exploitability of every candidate finding. When an auditor flags a suspect path and the debater cannot refute it, the finding's confidence score rises.
• Deduplicate: The pipeline consolidates semantically equivalent findings so teams aren't handed five separate tickets for the same underlying flaw.
• Prove: Where the bug class allows it, proving agents and domain-specific plugins construct and dynamically execute triggering inputs—such as generating a malformed log file or triggering an AddressSanitizer (ASan) crash in C/C++—to prove the vulnerability is real before a human ever opens a ticket.

Section Summary: Codename MDASH is a private-preview agentic code scanner inside Microsoft Defender that replaces single-pass AI prompting with a five-stage pipeline—Prepare, Scan, Validate, Deduplicate, and Prove—using over 100 specialized agents to catch multi-file logic and memory flaws that traditional static analysis misses.

Inside Tanium’s Production Codebase Test​

Why does it matter that Tanium is kicking the tires on this system? Think about the software privileges involved. Endpoint management platforms run deep inside enterprise infrastructure, executing commands, deploying patches, and monitoring telemetry across vast fleets of Windows devices. If an attacker discovers an authentication bypass or a remote code execution flaw in a management vendor's code, the blast radius for downstream customers is enormous.

Christian Hunt, Chief of Engineering at Tanium, emphasized that exact responsibility in the company's announcement, noting that because customers build their IT and security programs on Tanium, the security of the code the company ships is critical. Hunt added that Tanium had already been applying frontier AI models across its software development lifecycle, and joining the MDASH preview extends that strategy.

What stands out for security practitioners is how Tanium integrated the tool. In its announcement, Tanium stated that it ran MDASH directly against its own production codebase. However, it did not blindly pipe AI output into bug reports. Instead, Tanium used a layered workflow:

1. Automated Agentic Discovery: MDASH scanned the production codebase to surface candidate logic, authorization, and cross-file issues at scale.
2. Secondary Automated Validation: Tanium paired MDASH’s output with additional AI-assisted static and dynamic validation checks.
3. Human Specialist Review: Seasoned security engineers examined, proved, and prioritized the surviving findings.
4. SDL Remediation: Confirmed findings were routed directly into Tanium’s formal secure development lifecycle (SDL) for patching.

Loic Simon, Vice President of Security at Tanium, summed up the operational philosophy bluntly: "The value isn't just running a scan, it's what you do with what it finds that matters."

From an objective journalistic standpoint, it is important to note what Tanium has not disclosed. Neither Tanium nor Microsoft has released specific metrics from Tanium's production scan—there is no public tally of how many candidate findings MDASH flagged in Tanium's repositories, how many survived human validation, or whether any specific production vulnerabilities were remediated as a result. Nor has Tanium specified which deployment interfaces or programming languages were involved in its test run. Still, the architectural takeaway is clear: even with multi-agent debate and automated proof stages, mature security teams treat agentic AI as a high-speed force multiplier for human engineers, not a replacement for them.

Section Summary: Tanium tested MDASH against its live production codebase using a layered "detect, decide, and remediate" workflow that combined Microsoft's agentic scanning with secondary validation and human engineering review, though specific vulnerability counts from the test remain undisclosed.

How MDASH Fits into the Microsoft Defender Ecosystem​

For enterprise defenders and DevSecOps leads wondering what Codename MDASH actually looks like in practice, Microsoft Learn’s current preview documentation provides concrete technical boundaries. While MDASH remains in a limited private preview, Microsoft has already wired it into the broader Defender and developer tooling ecosystem.

According to Microsoft Learn, findings generated by MDASH are centralized inside the Microsoft Defender portal under a dedicated initiative page within Microsoft Security Exposure Management. Because agentic scanning operates differently than conventional rule matching, this portal view is isolated to AI scanner results and categorizes items into three triage buckets: Validated by AI scanner, Flagged for review, and Low priority. Microsoft explicitly advises that high-severity findings the AI cannot fully validate on its own should be investigated by a human analyst—a workflow recommendation that aligns closely with how Tanium structured its internal testing.

Microsoft’s Own Benchmarks: Impressive Numbers with Real-World Caveats​

To understand why third-party software vendors are eager to join the MDASH private preview, you only have to look at how Microsoft used the harness on its own core Windows components earlier this year.

In its May 2026 technical report, Microsoft revealed that MDASH-assisted research uncovered 16 vulnerabilities across the Windows networking and authentication stack that were patched in the April and May 2026 Patch Tuesday cycles, including four Critical remote code execution (RCE) flaws. Two of those cases illustrate why multi-agent reasoning is catching the eyes of C/C++ and enterprise systems engineers:

• CVE-2026-33827 (tcpip.sys): A remote, unauthenticated race-condition use-after-free (UAF) in the Windows IPv4 receive path (Ipv4pReceiveRoutingHeader) triggered via Strict Source and Record Route (SSRR) packet options. Single-model scanners missed it because dropping the reference to the Path object and reusing the stale pointer were separated by complex control flow, and recognizing the bug required noticing that another file in the codebase handled the exact same pattern in the correct order.
• CVE-2026-33824 (IKEEXT service): A pre-authentication LocalSystem RCE in the Windows IKE and AuthIP IPsec keying module over UDP port 500. When reassembling an IKEv2 fragment, the service performed a shallow memcpy of a packet context, leaving two structures believing they owned the same 16-byte heap pointer and triggering a deterministic double-free on teardown. Catching the flaw required tracking an alias chain across six separate .c files.

Microsoft also published several internal and public benchmark figures for MDASH:

• 21 of 21 planted bugs found with zero false positives on StorageDrive, a private sample Windows kernel driver used to interview offensive security researchers (ensuring the code was never in any LLM's training data).
• 96% retrospective recall on five years of confirmed Microsoft Security Response Center (MSRC) vulnerabilities in the Windows Common Log File System driver (clfs.sys), aided by a custom domain plugin that knew how to build triggering log files, and 100% recall across seven historical cases in tcpip.sys.
• 88.45% success rate on the public CyberGym benchmark of 1,507 real-world vulnerability reproduction tasks across 188 OSS-Fuzz projects, topping the leaderboard by roughly five percentage points at the time of publication.

Now, let's put on our veteran IT journalist spectacles for a moment. Those are Microsoft’s self-reported figures, and to the company's credit, Microsoft’s researchers included important caveats. Retrospective recall proves a tool would have caught yesterday’s bugs, not that it will automatically catch 96% of tomorrow’s unknown flaws. Furthermore, in the ~12% of CyberGym tasks where MDASH failed, Microsoft noted that 82% of wrong-target failures stemmed from vague task descriptions lacking file or function identifiers, while others failed due to fuzzer harness format mismatches (such as generating libFuzzer inputs when honggfuzz was expected).

In other words, the AI harness is only as sharp as the context, plugins, and validation pipelines wrapped around it.

Section Summary: Microsoft’s own testing shows MDASH excels at multi-file C/C++ memory and logic bugs—having helped uncover 16 Windows networking and authentication CVEs—and integration into GitHub, Azure DevOps, and Defender CLI makes it practical for enterprise CI/CD pipelines, though human triage and domain context remain vital.

Practical Takeaways for Enterprise DevSecOps and Windows Admins​

While Codename MDASH is currently gated behind a limited private preview, the partnership between Microsoft and Tanium signals a major shift in how enterprise software is audited before it ever lands on your endpoints. If you manage application security or enterprise IT infrastructure, here is how to read the tea leaves:

1. Audit Your Vendors’ SDL Practices: When evaluating endpoint management, RMM, or security agents that run with LocalSystem or kernel privileges on Windows, ask vendors how they are evolving beyond basic pattern-matching SAST. Are they testing multi-agent discovery tools to hunt for cross-file logic and authorization bugs?
2. Design for Validation, Not Just Discovery: As Loic Simon pointed out, running a scan is the easy part. If your organization adopts AI code scanning—whether through Microsoft Defender's preview or competing platforms—build a triage funnel that uses LSP type resolution, dynamic proving, and human security review so developers aren't drowned in unverified AI theories.
3. Avoid Model Lock-In: One of the smartest architectural choices in MDASH is that its pipeline stages are model-agnostic. Because foundation models leapfrog each other every few months, enterprise security harnesses should allow you to swap underlying models via a configuration change without throwing away your custom repository context, call graphs, or proving plugins.

Software development isn't slowing down, and neither are the adversaries combing through binary diffs every Patch Tuesday. Seeing major endpoint vendors like Tanium put their production code through multi-agent gauntlets like Codename MDASH—backed up by skeptical human engineers—is exactly the kind of defense-in-depth the Windows ecosystem needs.