The Agentic Pipeline: Prepare, Scan, Validate, Dedupe, Prove

The useful way to understand an agentic vulnerability-finding system is not as a chatbot that reads code. It is a pipeline. Each stage narrows uncertainty: first by making the codebase searchable and risk-ranked, then by asking specialized agents to form hypotheses, then by testing those hypotheses against program facts, collapsing duplicates, and, where possible, producing a working proof. Microsoft’s public description of Codename MDASH is a good concrete example of this pattern: many agents, several models, language-aware tools, and domain plugins cooperate so that a final finding is more than an interesting guess.

The pipeline turns suspicion into evidence

A single pass over source code can produce many plausible warnings. Some are real. Some are unreachable. Some are different descriptions of the same underlying flaw. The agentic pipeline exists to separate those categories before a human engineer spends time on them.

The five stages are Prepare, Scan, Validate, Dedupe, and Prove. Prepare builds the map. Scan generates candidate findings. Validate challenges each candidate for reachability and exploitability. Dedupe merges equivalent reports. Prove tries to create a triggering input or other dynamic evidence when the bug class allows it.

This matters because security teams do not need more vague alerts. They need a small set of distinct, actionable vulnerabilities with a clear explanation of why the issue can be reached and why it matters.

Prepare: give the agents a map, not a haystack

Preparation is where the system turns a repository into something agents can reason about. According to Microsoft’s public materials, Codename MDASH ingests the source target, builds language-aware indexes, and studies the attack surface and threat model. It also analyzes past Git commits and builds a call graph, which is a map of which functions can call which other functions.

That map is not just for navigation. It helps rank work. A function on a sensitive call path, with high code complexity, near a boundary where untrusted data enters the system, deserves more attention than a simple helper buried in test code. Risk ranking gives later stages a better starting order.

This stage is easy to understate. Without preparation, agents see fragments. With preparation, they can ask better questions: where does input enter, where does it flow, what permissions are assumed, what code changed recently, and which functions sit on paths that matter?

Scan: use specialists instead of one generalist

The scan stage is deliberately plural. Microsoft describes more than 100 specialized auditor agents in Codename MDASH. Examples include agents focused on injection, memory safety, and authentication bypass. Each agent looks for a narrower class of vulnerability and emits candidate findings with a hypothesis and supporting evidence.

This design accepts a practical truth: an agent that is good at spotting memory lifetime mistakes is not necessarily the same agent that is good at reasoning about authorization logic. Different bug classes have different shapes, vocabulary, traces, and failure modes.

The agents are informed by research into past Common Vulnerabilities and Exposures, or CVEs, and their patches. Microsoft says individual expert agents have been tuned with deep experience in languages such as C, C++, Java, and C#. The system is described as operating across codebases generically, supporting major programming languages, and adding expertise over time, including for domain-specific languages used in industrial controllers and programmable logic controllers in operational technology environments.

Validate: make the finding survive an argument

Validation is the hard middle of the pipeline. A candidate finding is not enough. The system must ask whether the code path is reachable, whether attacker-controlled data can arrive there, whether type and framework behavior make the scenario possible, and whether existing checks block exploitation.

In Microsoft’s description, a second group of agents acts as debaters. Some argue for a finding. Others argue against it. The system also uses taint analysis, which tracks how untrusted data may flow through code, and type resolution through Language Server Protocol servers. The Language Server Protocol is the common editor-and-tooling protocol that lets tools ask language-aware questions such as where a symbol is defined or what type an expression has.

The point of debate is not theater. It is a way to turn disagreement into signal. If an auditor flags a suspicious pattern and a separate model, using different reasoning and tools, cannot refute reachability or exploitability, the finding becomes more credible. If the counterargument shows that a guard always runs first, confidence drops.

Dedupe and prove: reduce noise, then seek a trigger

After validation, the system still may have several reports that describe the same root cause. One agent might describe the flaw from the input boundary. Another might describe the same flaw at the crashing function. A third might point to the patch that would fix both. Dedupe collapses semantically equivalent findings into one actionable item.

Microsoft’s notes mention patch-based grouping as one way to think about this. If two reports would be fixed by the same code change, they may not be two separate vulnerabilities. Dedupe is not cosmetic; it changes the workload for the team that must investigate, assign ownership, patch, test, and ship.

The Prove stage then attempts dynamic confirmation where the bug class permits it. For C and C++ memory bugs, that might mean constructing an input that triggers the condition under AddressSanitizer, often called ASan, which is a compiler-based runtime tool that detects memory errors. A candidate without proof can still be important, but in practice it remains a triage item. A successful proof raises it to a confirmed vulnerability with evidence.

Models and plugins: do not ask the foundation model to know everything

The pipeline also separates model choice from stage design. Microsoft describes a configurable panel of models rather than one model doing all work. A state-of-the-art model can serve as a heavy reasoner. Distilled models can handle high-volume debate more cheaply. A second independent state-of-the-art model can provide a counterpoint. The system can treat disagreement as useful information, not merely as an error.

Plugins add another important boundary. Some facts are too local, too proprietary, or too specialized to expect a foundation model to know. A plugin can encode kernel calling conventions, I/O request packet rules, lock invariants, interprocess communication trust boundaries, or codec state machines. The agent can then reason with those facts instead of guessing them.

Microsoft gives a concrete example: a proving plugin for the Common Log File System, or CLFS, that knows how to construct a triggering log file. Such a plugin can understand the on-disk container layout, block validation sequence, and in-memory state machine. Teams can also connect a custom code-analysis database, such as a CodeQL database, so that agents can query facts already extracted from the code.

What leaders and practitioners should decide

The main decision is not whether agents sound impressive. It is where the pipeline will change real engineering outcomes. A team should ask what repositories are in scope, which languages and frameworks matter, which bug classes are worth the cost of deep validation, and what level of proof is required before work enters the remediation queue.

Practitioners also need to decide how agentic findings will meet existing security operations. A proven vulnerability should carry enough evidence for assignment and repair: affected path, vulnerability class, reachability argument, dedupe rationale, proof artifacts if available, and a suggested fix area. Without that handoff discipline, even a strong pipeline can create a new kind of backlog.

The best operating model treats the agentic system as a source of tested claims, not as an oracle. Humans still own risk acceptance, patch design, regression testing, and release decisions. The pipeline earns trust by making its reasoning inspectable and by being clear about which findings are proven, which are likely, and which are merely candidates.

• Choose the repositories, languages, and products where validated findings would change release or patch decisions.
• Define the evidence bar for each bug class, especially where dynamic proof is possible.
• Invest in plugins for domain rules the model cannot infer reliably from source code alone.
• Measure duplicate rate, false-positive rate, proof success rate, and time from finding to fix.
• Keep humans accountable for final risk, remediation, and shipment decisions.

Glossary

Agentic pipeline

A structured workflow in which multiple software agents use models, tools, and rules to move from raw input to tested output.

Call graph

A representation of which functions or methods can call one another in a program.

Common Vulnerabilities and Exposures

The public naming system, commonly abbreviated CVE, for cataloging known cybersecurity vulnerabilities.

Language Server Protocol

A standard protocol, often abbreviated LSP, that lets tools ask language-aware questions about code.

Taint analysis

A code-analysis technique that tracks whether untrusted data can flow to sensitive operations.

AddressSanitizer

A runtime checking tool, often called ASan, that helps detect memory errors in compiled programs.

Dedupe

The process of merging duplicate or semantically equivalent findings into one unique issue.

Operational technology

Hardware and software used to monitor or control physical processes, often in industrial settings.

Plugin

An extension that adds specialized tools, facts, or domain rules to a broader system.