Security leaders are being asked to approve agentic code security before the operating model is fully familiar. Codename MDASH deserves attention because it changes the quality of evidence available for hard-to-find source-code flaws, not because it removes accountability from engineers, risk owners or executives. The right question is not whether it is a magic scanner. It is whether your organization can aim it at the right code, govern the findings well and turn stronger evidence into better release, patch and investment decisions.

What MDASH is in plain language

Codename MDASH is a Microsoft Security system for finding vulnerabilities in source code using multiple artificial intelligence (AI) models and many specialized agents. Rather than asking one model to read a repository and produce a list of issues, MDASH coordinates more than 100 agents across an ensemble of models. Different agents look for candidate weaknesses, test the reasoning, examine whether a path is reachable, assess whether exploitation is plausible, remove duplicate findings and, when the bug type permits it, build a concrete input that demonstrates the flaw.

That last point matters for executives. A finding with evidence is easier to triage than a finding that only says a risky pattern exists. MDASH is designed to produce evidence and remediation guidance, but it is read-only. It does not alter code, change infrastructure or repair systems by itself. The product is the orchestration layer that coordinates models and agents, not a single underlying model.

📌
The repeatable message. MDASH is a deep, read-only security reviewer that produces evidence for human decision-makers.
Specialized agents find candidates, test reasoning, check reachability, then prove the flaw. Agent Ensemble Find candidates Test reasoning Check reachable Prove flaw
Specialized agents find candidates, test reasoning, check reachability, then prove the flaw.

Why this is now an executive topic

The most damaging source-code vulnerabilities are often not the easiest ones to scan for. Memory-safety flaws such as use-after-free, double-free and buffer overflow bugs can depend on a chain of conditions spread across files, functions and branches. Traditional pattern matching can help, but it often struggles when the exploit path is long, indirect or context-dependent.

Microsoft has also published unusually specific evidence for a system at this stage. On CyberGym, a public benchmark with 1,507 real-world vulnerability-reproduction tasks across 188 open-source projects, MDASH achieved the highest published score at the time, several points above the next listed entry, while using generally available models. In a May 12, 2026 Microsoft Security Blog announcement, Microsoft said MDASH had helped identify critical remote-code-execution (RCE) flaws in Windows networking and authentication components, including the kernel networking stack and a key exchange service.

The system is not only a lab exercise. Microsoft says its own engineering teams use MDASH on some of its most complex codebases, including Windows, the hypervisor, Azure virtualization and infrastructure and directory services. Microsoft has also made it available to a limited set of eligible Microsoft Defender customers, with capacity intentionally constrained to preserve scan quality.

  • The risk class is material: deep source-code flaws can become high-impact product security issues.
  • The evidence is concrete: public benchmark results and Microsoft’s own disclosures give leaders more than a vague productivity claim.
  • The adoption pattern is cautious: access and scan capacity are limited, so early use should be selective rather than universal.

Where it fits: review system, not build gate

The most important governance choice is placement. MDASH scans are AI-based, can take time and are non-deterministic. Non-deterministic means that the same code may not produce exactly the same result on every run. That is normal for this class of system, but it changes how leaders should use it.

MDASH is well suited to asynchronous deep review: scheduled investigations of high-value repositories, focused reviews before major releases, backlog creation for security teams and expert triage of difficult code. It is poorly matched to deterministic, build-blocking pipeline gates where engineering teams expect a stable pass-or-fail answer within a fixed number of minutes.

A useful mental model is a senior reviewer with unusual patience and access to a committee of specialists. You would not ask that reviewer to approve every commit in seconds. You would ask them to examine the code where the cost of missing a flaw is highest.

⚠️
Set expectations early. Treating MDASH as a smarter reviewer is realistic; treating it as an always-on deterministic pipeline gate is not.
MDASH fits asynchronous deep review, not deterministic build-blocking gates. Review vs Gate Deep reviewasync Build gatedeterministic Before releases Every commit Patient triage Fast pass-fail
MDASH fits asynchronous deep review, not deterministic build-blocking gates.

The decisions MDASH changes

MDASH does not remove executive decisions. It makes several of them sharper. The first is focus. Deep analysis has cost and capacity limits, so leaders must decide which repositories, products, languages and vulnerability classes are worth the attention. The likely starting point is security-critical code with high blast radius, not every repository in the company.

The second decision is triage policy. MDASH prioritizes findings by exploitability, then impact, then confidence, and places results into categories such as findings validated by the AI scanner and findings that require human review. Leaders should define what each category means before the first scan finishes. Which findings require immediate review? Which receive a service-level objective (SLO)? Which can be accepted, deferred or placed into a backlog?

The third decision is ownership of remediation. MDASH itself does not open pull requests, push patches or change code. A separate optional workflow can be started by a developer using the Microsoft Defender command-line interface (CLI), GitHub Copilot and the scan’s machine-readable output to propose a function-level fix on a new branch. People still review, test, approve and merge. The accountability for shipped software remains human.

  • Which code is important enough for deep agentic review?
  • How quickly must each triage category be reviewed and acted on?
  • Who owns remediation, validation and final release risk?
  • What evidence is strong enough to delay a release or accelerate a patch?
MDASH sharpens three decisions: focus, triage policy, and remediation ownership. Executive Decisions Decisionssharper not gone Focuswhich repos Triage policycategories Ownershipwho fixes
MDASH sharpens three decisions: focus, triage policy, and remediation ownership.

Risk, compliance and data handling

Assurance teams will ask whether MDASH can change production systems, where code and results are stored, how audit works and what licenses are required. Microsoft’s public documentation gives clear boundaries. MDASH is read-only by design. It produces findings and guidance, but it does not modify environments or automatically remediate code.

For data residency, Microsoft says customer source code and scan results are encrypted at rest inside the customer’s Microsoft Defender tenant and stored in the same region as that tenant. Analysis runs in the region the customer specifies when connecting to its Microsoft Foundry endpoints.

For auditability, MDASH records privileged-user actions across the scan lifecycle, including onboarding, connecting and disconnecting inference, scan start, cancellation, upload, viewing and export. The audit record includes timestamp, user, client internet protocol (IP) address, scan identifier, code target, source surface and result. Source code itself is not logged. Audit events remain in the customer’s Microsoft Entra tenant log and can be queried through Microsoft Purview.

There is also a licensing prerequisite. Customers need an eligible Microsoft Defender plan, and MDASH must be enabled and configured through the Microsoft Defender portal.

Procurement and architecture choices

MDASH is model-agnostic in the sense that customers provision the models it uses through Microsoft Foundry rather than buying one fixed model as the entire product. Customers can see token consumption by model, which matters because token use is one of the cost signals for AI workloads.

This changes the buying conversation. The question is not simply which model performs best this quarter. Models will change. The better question is whether the orchestration system lets the organization compare models, swap them without rebuilding the security workflow and connect cost to the evidence produced.

Leaders should also treat capacity as a planning constraint. Microsoft has limited availability and rate-limited scans to protect quality. That makes portfolio selection part of the architecture. If the plan depends on scanning every repository continuously, the plan is misaligned with the current shape of the service.

📌
Buy the operating model. The durable value is orchestration, evidence, cost visibility and model flexibility, not allegiance to one model.

What not to expect

An honest business case is as important as an ambitious one. MDASH analyzes source code. It is not positioned as a scanner for compiled binaries, packaged Java archives or runtime memory images. It is also not a replacement for static analysis, manual security review or threat modeling. It adds a deeper reasoning-capable layer to an existing assurance program.

Organizations also should not expect to bring their own models or import custom agents at this stage. Remediation guidance is code-level rather than architectural redesign. If a product has a flawed trust boundary or an unsafe system design, a function-level patch may help one bug but will not replace architectural review.

The right success measures reflect those boundaries. Track duplicate rate, false-positive rate, proof-success rate, review time, fix time and the share of findings that change release or patch decisions. Also track token consumption and model cost, because deep analysis is only sustainable if its cost is visible and tied to outcomes.

  • Do not use it as the only security control.
  • Do not assume every finding is final without expert review.
  • Do not expect automatic pull requests or unattended fixes.
  • Do not plan for unlimited continuous scanning while capacity is constrained.
  • Do not confuse code-level remediation with architectural redesign.
✅
A practical start. Begin with the codebases where a validated high-impact finding would change a release, patch or funding decision.

Key takeaways

  • MDASH is a read-only, multi-model agentic source-code reviewer that produces evidence and guidance, not an autonomous repair system.
  • Its strongest use is asynchronous deep review of high-value code, not deterministic build blocking.
  • Leaders must decide target scope, triage policy, remediation ownership and release impact before findings arrive.
  • Assurance review should confirm data residency, audit logging, regional analysis, licensing and read-only behavior before onboarding.
  • The procurement question is about orchestration, model flexibility, token cost visibility and evidence quality rather than one preferred model.
  • MDASH complements static analysis and manual review; it does not replace them or redesign unsafe architectures.
Track the metrics that reflect MDASH's real boundaries and value. Success Measures Duplicate rateless noise False positivestrust signal Proof successevidence rate Fix timeresponse speed
Track the metrics that reflect MDASH's real boundaries and value.

Glossary

Agentic scanning
A scanning approach in which AI agents perform specialized tasks such as finding, checking and explaining possible vulnerabilities.
Artificial intelligence (AI)
Software techniques that perform tasks normally associated with human reasoning, pattern recognition or language understanding.
CyberGym
A public benchmark of real-world vulnerability-reproduction tasks used to compare systems that find and demonstrate software flaws.
Remote-code-execution (RCE)
A vulnerability that can allow an attacker to run code on a system from another location.
Service-level objective (SLO)
A measurable target for how quickly or reliably a service or process should perform.
Microsoft Foundry
Microsoft’s platform for provisioning and using AI models and related services.
Microsoft Defender
Microsoft’s security product family and portal environment through which eligible customers enable and configure MDASH.
Microsoft Entra
Microsoft’s identity and access platform, which includes tenant logs used for audit records.
Microsoft Purview
Microsoft’s data governance and compliance platform, which can be used to query relevant audit events.