Agentic source-code review brings more context to vulnerability discovery

Google Threat Intelligence has described how it uses a multi-agent system to analyze source code and discover exploit paths. The approach, called the Agentic Vulnerability Discovery Harness (AVDH), is not presented as a replacement for security specialists. Instead, it is infrastructure intended to extend their ability to analyze large and complex repositories.

The central idea is to structure model-based work through a deterministic sequence of stages. The process begins with repository reconnaissance and threat-model construction. One agent identifies the application’s purpose, technologies, available documentation, and relevant components. Specialist explorers then review areas such as authentication, authorization, routing, and other entry points.

This first stage matters because analyzing an isolated function often loses critical information. A vulnerability may depend on permissions defined in another module, a routing condition, or a transformation applied several calls away. AVDH therefore enriches each discovered entry point with related context and determines whether it requires access-control analysis, data-flow analysis, or both.

Specialized agents then generate hypotheses about possible flaws. The access-control analysis looks for issues including missing authorization, checks performed against the wrong identity, and privilege escalation. The data-flow analysis follows user-controlled input until it reaches dangerous sinks, where SQL injection, cross-site scripting, command injection, or path traversal could occur.

The architecture separates hypothesis generation from validation. Multiple agents review each possibility, while a synthesis agent classifies the result as confirmed, disproven, or rejected. Human specialists then take over to reproduce the exploit and execute proof-of-concept tests in controlled environments. Findings that fail this verification stage are discarded.

According to the article, the system discovered more than one hundred confirmed critical vulnerabilities during an incident-response investigation in two days. It also analyzed tens of millions of lines of code and contributed to twelve assigned CVEs. These figures come from the provider’s own account, so they should be understood as internal experience rather than an independent benchmark.

The most useful technical lesson is not simply that models can review code. Their effectiveness depends on orchestration: asset inventories, SBOMs, architecture documentation, threat intelligence, language- and framework-specific rules, confidence filters, and dynamic validation. Without that context, a system can produce excessive false positives or miss relevant attack paths.

For engineering teams, the pattern suggests a layered defense. Automated analysis can broaden coverage and prioritize repetitive work, while people retain responsibility for validating exploitability, impact, and disclosure. Teams also need to measure the system with private benchmarks, genuinely reachable vulnerabilities, and human review, because public datasets may already appear in model training data.

The value, in other words, does not come from adding a chatbot to a security process. It comes from designing a reproducible pipeline that connects architectural context, specialized analysis, adversarial verification, and expert judgment.