How AI Vulnerability Discovery Harnesses Work

In August 2026, Google's Mandiant unit published the architecture behind its internal Agentic Vulnerability Discovery Harness (AVDH) — a multi-agent AI system that found over 100 true-positive critical vulnerabilities in stolen corporate source code within two days. This page breaks down how a harness like that actually works, stage by stage, and what the design gets right that matters for any team considering something similar. The core idea isn't "point a language model at some code and ask if it's vulnerable." A harness like AVDH is a genuine pipeline — a sequence of specialized agents, each doing one well-defined job, with a mandatory human checkpoint at the end. That structure is what separates a harness from a chatbot with file access, and it's the part most worth understanding if you're evaluating whether this approach fits your own team. Stage 1: Threat Modeling Before any code gets scanned, the harness establishes what's actually worth protecting in the codebase — which components handle sensitive data, which sit closest to externally reachable surfaces, and where a real compromise would matter most. This scoping step is what keeps the rest of the pipeline focused, rather than treating every line of code as equally important. Stage 2: Entry Point Discovery Parallel discovery agents scan the in-scope files for anything an external party could reach — HTTP routes, IPC listeners, API endpoints — and isolate the specific inputs an attacker could actually control at each of those entry points. Stage 3: Context Enrichment An enrichment agent traces each entry point across files and nested function calls, gathering context on sanitization, permissions, routing logic, and storage boundaries along the way. This is the step aimed at a well-known blind spot: exploitable conditions that only emerge across distributed code paths, which both manual review and conventional static scanners routinely miss because the vulnerable condition never sits in one place. Stage 4: Access Control & Data Flow Analysis Dedicated agents handle control-flow analysis (who can reach this code, and under what conditions) and data-flow tracking (where untrusted input actually ends up) as separate, specialized passes rather than one general-purpose sweep. Stage 5: Hypothesis Validation Multiple agents — deliberately run at a higher reasoning "temperature" to widen the range of thinking they produce — independently evaluate each candidate finding. A synthesis agent then sorts every hypothesis into confirmed, disproven, or rejected. Stage 6: Human Verification — Mandatory, Not Optional Every finding that survives synthesis still goes to a human security expert before it counts for anything. Mandiant's own consultants manually reproduce the exploit and run proof-of-concept code to confirm the flaw is genuine and isn't already blocked by a control the agents missed. Anything that fails this check is discarded outright — not downgraded to "low confidence" and left for someone else to triage later. Why the human step isn't negotiable Mandiant's own researchers were direct about this: "We encourage network defenders considering implementing similar vulnerability discovery harnesses to manually validate findings." A harness this capable is still built to accelerate a human review process, not replace the judgment at the end of it — the speed is only trustworthy because of the verification step, not despite it. If you're considering building something similar - Start by scoping deliberately, the way the Threat Modeling stage does — point the harness at the code that actually matters (sensitive data handling, externally reachable endpoints) rather than the whole repository at once. - Evaluate against your own synthetic test cases with manually injected flaws, not public vulnerability datasets a model may have already seen during training — otherwise you're measuring memorization, not genuine discovery. - Build the human verification step in from day one, not as a later addition. Treat every "confirmed" finding as a hypothesis until a person reproduces it. Is AVDH publicly available to use? No. Google Mandiant published the architecture and design principles publicly, not the tool itself, specifically so other security teams and open-source maintainers can build their own version suited to their own codebase. Does this replace traditional static analysis or code scanning? Mandiant positions it as complementary, not a replacement — pairing continuous, lighter-weight scanning with deep, point-in-time agentic review when the stakes justify the additional depth. How was the harness itself evaluated for accuracy? Against internal synthetic codebases with vulnerabilities manually injected by human experts, rather than public vulnerability datasets — since public datasets may already be part of what the underlying models were trained on, which would make the evaluation measure memorization rather than genuine detection ability.