The most useful lesson from Microsoft’s Codename MDASH is not that one model suddenly learned to find hard security bugs. It is almost the opposite. The model is only one ingredient. The larger invention is the system around it: the way work is divided, evidence is checked, disagreements are used, tools are attached, and findings are turned into something an engineer can trust enough to fix.

The harness is the product

Codename MDASH is an agentic system for finding and helping remediate software vulnerabilities. Agentic means the system does not merely answer a prompt; it plans subtasks, calls tools, inspects evidence, and continues through a workflow until a stop condition is met.

That distinction matters. A single model can be impressive in a demonstration and still be brittle in an engineering process. It may notice a pattern, miss the context that proves it, or state a plausible exploit path without enough evidence. A harness exists to keep those abilities useful and those weaknesses contained.

In MDASH, the core work is not framed as one prompt to one model. The system runs many specialized agents, compares their outputs, validates the claims, removes duplicates, and assembles a report. The model contributes judgment and language understanding, but the surrounding machinery decides how that judgment is used.

The harness plans subtasks, calls tools, checks evidence, and assembles one report. The Harness The harnessnot one prompt Plans taskssubtasks Calls toolsinspects Checks evidencevalidates Assemblesone report
The harness plans subtasks, calls tools, checks evidence, and assembles one report.

Why diversity helps

No one model is best at every part of vulnerability analysis. A large frontier model may be strong at long, careful reasoning. A smaller or distilled model may be cheap enough for broad first-pass review. A separate high-capability model may be useful precisely because it fails in different ways.

The point is not to vote blindly. The point is to treat disagreement as evidence. If three agents converge on the same lifetime bug from different paths, confidence rises. If one agent claims a remotely reachable exploit and another cannot find the network path, the system has learned where to spend validation effort.

This is especially important in security, where the cost of being wrong is asymmetric. A false positive wastes scarce engineering time. A false negative leaves an exploitable flaw in place. A multi-model harness gives the system more than one lens before it asks humans to act.

📌
Disagreement is useful. In a well-designed harness, model disagreement is not noise to hide; it is a signal that guides deeper checking.
The cost of being wrong is asymmetric: a missed flaw is far worse than wasted review time. Error Costs True positivecaught it False positivewasted time False negativeflaw remains True negativeall clear
The cost of being wrong is asymmetric: a missed flaw is far worse than wasted review time.

Specialized agents beat general attention

MDASH uses specialized agents rather than asking one model to be auditor, skeptic, and proof writer at the same time. An auditor hunts for suspicious patterns. A debater challenges the claim, looks for missing preconditions, and asks whether the evidence really supports exploitation. A prover tries to connect the suspected defect to a concrete path and a defensible report.

Those roles can have different prompts, tools, budgets, and stopping rules. A broad auditor may tolerate weak signals because its job is to find possible leads. A prover should be much stricter because its output may guide a fix. Separating the roles makes the system less dependent on one model maintaining the right level of skepticism throughout a long interaction.

Public Microsoft material describes MDASH as using more than one hundred agents working independently and then combining their results into a single report. That scale is not just about parallelism. It is a way to make security analysis more like a disciplined review process than a single act of generation.

Separate agents audit for leads, debate the claim, then prove it before humans act. Agent Roles Auditorfinds leads Debaterchallenges Proverconfirms
Separate agents audit for leads, debate the claim, then prove it before humans act.

The pipeline must survive model turnover

The most durable design choice in MDASH is that major parts of the workflow are model-agnostic. Target selection, validation, deduplication, and proof construction are built as stages around the models, not as behavior trapped inside one model’s quirks.

That matters because model quality changes quickly. If a system’s value depends on a particular model behaving in a particular way, the system must be rediscovered or rebuilt whenever the model landscape shifts. If the harness is stable, a new model can be tested against the current panel, promoted when it helps, or rejected when it does not.

Microsoft describes customers provisioning access to MDASH models through Microsoft Foundry and being able to see token consumption by model. The system is designed to use multiple models and to switch them over time.

A single model is brittle; a stable harness lets you swap models as the landscape shifts. Model vs Harness Single modelbrittle Stable harnessmodel-agnostic Rebuild on change Swap models in Trapped quirks Stable stages
A single model is brittle; a stable harness lets you swap models as the landscape shifts.

Example one: a use-after-free hidden by time

CVE-2026-33827 is a remote, unauthenticated use-after-free in tcpip.sys, the Windows kernel networking driver. The defect is in the Internet Protocol version 4 receive path, in logic associated with Strict Source and Record Route processing. Strict Source and Record Route is an IPv4 option that can direct and record the path a packet takes.

The bug involves a reference-counted Path object. The code releases its only owned reference to that object and later uses the same pointer again. If the reference count reaches zero at the earlier release, the memory can return to a per-processor lookaside allocator and be reused. The later access can then become a kernel use-after-free triggered by crafted IPv4 packets from a remote attacker who has not authenticated.

This is the kind of flaw a single pass can miss. The dangerous release and the later reuse are separated by control flow: an alternate branch, validation checks, and early-drop conditions. Seen locally, the two operations may not look connected. The stronger clue is comparative: the same logical operation appears elsewhere in the codebase in the correct order. The bug is not just one bad line; it is an inconsistency across related implementations.

A useful system has to connect ownership, reachability, and timing. It must notice the lifetime violation, understand that the Strict Source and Record Route path can be reached under the relevant configuration, and account for other subsystems that can reclaim the object during the exposed window. That is a chain of reasoning, not a single pattern match.

⚠️
Local evidence is not enough. Some real vulnerabilities only become obvious when a system compares distant code paths and tracks state across time.

Example two: a double-free spread across files

CVE-2026-33824 is an unauthenticated Internet Key Exchange version 2 vulnerability in the IKEEXT service. Internet Key Exchange version 2, or IKEv2, is used to negotiate security associations for Internet Protocol security. The service runs as LocalSystem inside svchost.exe, so successful exploitation can lead to remote code execution in a highly privileged Windows context.

The underlying bug is an aliasing lifecycle error spread across six source files. When IKEEXT reinjects a reassembled IKEv2 fragment, it duplicates a packet receive context using a flat memory copy. That copies the bytes of the structure but not the ownership of heap allocations referenced by pointers inside it.

After the copy, two owners refer to the same attacker-supplied security-realm identifier. During teardown, both free the same 16-byte heap allocation. The result is a deterministic double-free that can be triggered with two User Datagram Protocol packets, without a race and without special timing.

Again, the best evidence is contrast. Elsewhere in the same codebase, a similar copy is followed by the additional step needed to handle the pointed-to data correctly. Finding the bug requires one agent to notice the missing step, another to test whether the omission really matters, and a proving stage to connect that omission to a pre-authentication exploit path.

What leaders and practitioners should decide

The practical question is not whether to use the newest model. The better question is whether your vulnerability discovery process can absorb better models without throwing away everything else you have built.

For a security leader, that changes procurement and architecture discussions. Ask how findings are validated, how duplicate reports are merged, how domain knowledge enters the system, how model costs are measured, and whether new models can be tested against old ones. A benchmark score is useful, but it is not the same as an operating model.

For an engineering practitioner, the lesson is equally concrete. Invest in scope definitions, reproducible scan configurations, plugins that expose project-specific context, and feedback loops that mark findings as true, false, fixed, or not exploitable. Those artifacts should remain valuable when the model panel changes.

The larger pattern is simple: discovery requires composition, validation turns suspicion into action, and portability protects the work you do today from the model changes that arrive tomorrow.

  • Can the system compare multiple models rather than rely on one?
  • Are agent roles separated for discovery, challenge, proof, and reporting?
  • Can teams add domain context through plugins or configuration?
  • Does the workflow expose cost and token use by model?
  • Can new models be A/B tested without rebuilding the pipeline?
✅
Durability is the goal. A model-agnostic harness lets an organization benefit from new models while preserving its prior engineering investment.

Key takeaways

  • Many-model systems work best when a harness assigns roles, checks evidence, and controls the workflow.
  • Model disagreement can be a useful signal, especially when deciding which claims need deeper validation.
  • Specialized agents are better suited to security work than one all-purpose prompt because discovery, debate, and proof need different standards.
  • Hard vulnerabilities often require cross-file reasoning, lifecycle tracking, reachability analysis, and comparison with correct patterns elsewhere.
  • A model-agnostic pipeline is more durable than a system whose value depends on one model generation.
  • Leaders should evaluate the full operating system for vulnerability discovery, not just the headline model.

Glossary

Agentic system
A software system that uses models to plan and carry out multi-step tasks with tools, checks, and stopping rules.
A/B test
A comparison in which two options are run under similar conditions to see which performs better.
Common Vulnerabilities and Exposures
A public naming system that gives known security vulnerabilities identifiers such as CVE-2026-33827.
Deduplication
The process of merging multiple reports that describe the same underlying issue.
Internet Key Exchange version 2
A protocol used to negotiate cryptographic security associations, commonly for Internet Protocol security connections.
LocalSystem
A highly privileged Windows service account with broad authority on the local machine.
Remote code execution
A vulnerability class in which an attacker can cause a target system to run attacker-controlled code.
Strict Source and Record Route
An Internet Protocol version 4 option that specifies packet routing and records the route taken.
Use-after-free
A memory safety bug in which software continues to use memory after it has been released.