VulAgent: Agent-Based Vulnerability Analysis

• VulAgent is an agent-based vulnerability analysis framework that organizes specialized LLM agents to localize risky code and validate exploit hypotheses.
• It employs a multi-phase pipeline combining code localization, hypothesis construction, and structured verification against program context.
• Empirical results show enhanced pairwise accuracy and reduced false positives compared to traditional vulnerability detectors.

Searching arXiv for the named VulAgent framework and closely related agentic vulnerability-detection systems. VulAgent denotes an agent-based approach to software vulnerability analysis in which LLMs are organized into specialized roles that localize security-sensitive code, formulate explicit exploitability hypotheses, and validate those hypotheses against program context rather than emitting a single one-shot classification. In the literature, the name refers specifically to the hypothesis-validation framework “VulAgent” (Wang et al., 15 Sep 2025), while closely related systems such as VulnAgent-X are presented as concrete instantiations of a “vulnerability agent” architecture for repository-level detection (Meng et al., 11 Mar 2026). Across these systems, vulnerability detection is recast from isolated function labeling into a staged auditing process that combines localization, contextual retrieval, structured reasoning, and selective verification.

1. Conceptual scope and representative systems

VulAgent is best understood as both a specific framework and a broader design pattern. The specific framework “VulAgent” targets project-level vulnerability detection through a semantics-sensitive, multi-view pipeline built around hypothesis construction and validation (Wang et al., 15 Sep 2025). The broader pattern includes adjacent multi-agent systems that decompose vulnerability analysis into specialized roles, contextual retrieval, and adjudication or verification stages rather than treating the task as flat binary classification (Meng et al., 11 Mar 2026).

This broader usage is visible across the recent literature. Some systems emphasize hypothesis validation, others layered auditing, courtroom-style deliberation, contextual reasoning, or repository-scale retrieval. What unifies them is the claim that realistic vulnerability detection requires both precise localization of risky operations and explicit reasoning over the surrounding code, data flow, and defensive checks.

System	Core mechanism	Scope
VulAgent (Wang et al., 15 Sep 2025)	hypothesis conditions + trigger path validation	project-level detection
VulnAgent-X (Meng et al., 11 Mar 2026)	layered risk screening, bounded context expansion, selective dynamic verification	repository-level detection
MAVUL (Li et al., 30 Sep 2025)	contextual reasoning and interactive refinement	pairwise OSS vulnerability detection
VulTrial (Widyasari et al., 16 May 2025)	mock-court multi-agent deliberation	vulnerable–benign function pairs

This suggests that “VulAgent” is not merely a product name but a recognizable systems pattern: multi-agent vulnerability auditing with explicit intermediate structure.

2. Core architecture

In its named formulation, VulAgent organizes analysis into four phases: multi-view vulnerability detection, report aggregation and hypothesis construction, hypothesis-conditions validation, and hypothesis-path verification (Wang et al., 15 Sep 2025). The first phase assigns code to a baseline set of agents and, when semantic cues warrant it, to additional specialists. The baseline set is given as $\mathcal{B}$, and agent activation is expressed as

$$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$

where $\phi(c_i)$ denotes the parsed code unit and each routing rule $r$ maps semantic cues to specialist agents (Wang et al., 15 Sep 2025).

The specialized agents are aligned to vulnerability families and analysis perspectives. The baseline set comprises StaticAnalyzerAgent, BehaviorAnalyzerAgent, and MemoryLayoutAgent. Additional specialists include FormatStringAgent, FilePermissionAgent, AuthFlowAgent, CryptoConfigAgent, ConcurrencyAnalyzerAgent, ErrorHandlingAgent, and CodeInjectionAgent (Wang et al., 15 Sep 2025). Each agent emits a structured report over numbered source lines, allowing downstream aggregation and cross-agent alignment.

Aggregation is followed by explicit hypothesis construction. For each merged candidate report $\tilde t_{i}^{(k)}$, TriggerPlannerAgent constructs

$$h_{i,k} = \Psi\!\bigl(\tilde t_{i}^{(k)}, C_i\bigr) = \bigl(\,\mathrm{cwe}_{i,k},\; \mathcal{A}_{i,k},\; \mathcal{P}_{i,k}\,\bigr),$$

where $\mathcal{A}_{i,k}$ is the set of assumption conditions and $\mathcal{P}_{i,k}$ is the trigger path (Wang et al., 15 Sep 2025). This is the central structural move in VulAgent: a vulnerability report is not the endpoint of reasoning but the starting point for a formalized exploitability hypothesis.

3. Hypothesis validation and contextual reasoning

The hypothesis-validation paradigm distinguishes VulAgent from prior multi-agent systems that rely primarily on discussion or textual reflection. A trigger path is modeled as

$$\mathcal{P}_{i,k} = \bigl\langle v_1 \xrightarrow{e_1} v_2 \xrightarrow{e_2} \cdots \xrightarrow{e_{m-1}} v_m \bigr\rangle, \quad v_1 \in \mathcal{S}^{\text{att}}_{i,k},\;\; v_m = s_{i,k},$$

with $v_1$ drawn from attacker-controllable sources and $$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$0 fixed as the sensitive sink (Wang et al., 15 Sep 2025). Guard conditions encountered along the path are not used to prune the path during construction; instead, they are recorded as assumptions in $$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$1 and tested later. This separates path discovery from path invalidation.

Assumption validation is then performed against program context $$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$2, including control-flow graphs, data-flow dependencies, call graphs, types, and invariants. For each assumption $$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$3, the system computes

$$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$4

where $$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$5 classifies the assumption as valid, contradicted, or plausible and $$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$6 stores supporting evidence (Wang et al., 15 Sep 2025). The retained assumptions form

$$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$7

A representative example in the paper uses a hypothesis that the input is too long before a strcpy sink. Context analysis finds an upstream check if (strlen(input) > 256) return;, which contradicts that assumption and causes the hypothesis to be rejected (Wang et al., 15 Sep 2025). This is the essential false-positive reduction mechanism: the model is steered to ask not only whether a sink looks dangerous, but whether the exact preconditions required for exploitation survive contact with the real code base.

Related work frames the same problem differently but reaches similar conclusions. Vul-RAG argues that strong vulnerability detection requires explicit cause–fix reasoning rather than pattern matching, especially when vulnerable and patched functions have high lexical similarity (Du et al., 2024). MAVUL likewise argues that contextual reasoning and interactive refinement are required because binary labels alone cannot capture root cause, vulnerability type, or exploit conditions (Li et al., 30 Sep 2025).

4. Repository context, tool use, and verification

VulAgent’s context reasoning is not purely prompt-based. On PrimeVul, context is built with Joern-derived control-flow graphs, data-flow graphs, and call graphs; on SVEN, a custom static tool reconstructs minimal project context from original files, calls, imports, and libraries (Wang et al., 15 Sep 2025). The system therefore treats context as structured analysis state rather than raw code concatenation.

This design aligns with other agentic detectors that expose explicit context tools. MAVUL equips its analyst agent with get_function_body, get_callers, and get_callees, and uses multi-round critique between a Vulnerability Analyst and a Security Architect to refine conclusions (Li et al., 30 Sep 2025). VulnAgent-X adopts a related but more heavily layered scheme: Stage I computes an initial risk score $$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$8, keeps only the top-$$A_i = \mathcal{B} \cup \Bigl( \bigcup_{r \in R} r\!\bigl(\phi(c_i)\bigr) \Bigr), \qquad 0 < i \le N,$$9 regions with default $\phi(c_i)$0, and then performs bounded context expansion by ranking context items with $\phi(c_i)$1 under a token budget $\phi(c_i)$2 (Meng et al., 11 Mar 2026). It then routes each suspicious region through Router, Semantic Analysis, Security Analysis, Logic Bug, and Sceptic agents, optionally invoking a Verification Agent for high-risk or uncertain cases.

VulnAgent-X makes the escalation policy explicit through thresholds $\phi(c_i)$3 and $\phi(c_i)$4, and it fuses evidence through

$\phi(c_i)$5

where the negative counter-evidence term explicitly suppresses false positives (Meng et al., 11 Mar 2026). Although this equation belongs to VulnAgent-X rather than the named VulAgent framework, it illustrates the same family trait: vulnerability detection is treated as evidence accumulation under bounded context and explicit validation, not as unrestricted textual speculation.

5. Evaluation regimes and empirical profile

VulAgent is evaluated on PrimeVul and SVEN using conventional binary metrics together with pair-wise measures over vulnerable–fixed code pairs (Wang et al., 15 Sep 2025). Accuracy is defined as

$\phi(c_i)$6

F1 as

$\phi(c_i)$7

and the paper additionally uses pair-wise correct prediction, pair-wise reversed prediction, and the vulnerability pair-wise score $\phi(c_i)$8 (Wang et al., 15 Sep 2025).

The reported gains are concentrated in pair discrimination and false-positive control. On average across the two datasets, VulAgent improves overall accuracy by 6.6%, increases the correct identification rate of vulnerable–fixed code pairs by up to 450% and by 246% on average, and reduces the false positive rate by about 36% compared with state-of-the-art LLM-based baselines (Wang et al., 15 Sep 2025). On PrimeVul, it reaches $\phi(c_i)$9, $r$0, $r$1, $r$2, and $r$3; on SVEN, it reaches $r$4, $r$5, $r$6, $r$7, and $r$8 (Wang et al., 15 Sep 2025).

A recurring theme in the surrounding literature is that evaluation itself is a source of distortion. MAVUL introduces a judge agent and multi-dimensional ground truth because binary comparisons can overestimate system capability; in its study, removing the evaluation agent yields error rates as high as 91.7% for some baselines (Li et al., 30 Sep 2025). Vul-RAG’s PairVul benchmark pushes the point further: several representative detectors collapse to near-random performance when asked to distinguish vulnerable code from its corresponding patched version, with pairwise accuracy between 0.01 and 0.10 for classical baselines and only 0.05 for basic GPT-4, whereas Vul-RAG reaches 0.21 pairwise accuracy (Du et al., 2024). The empirical implication is that VulAgent-style systems are best judged by their ability to separate vulnerable from fixed code under realistic context, not by coarse vulnerable/non-vulnerable labels alone.

6. Relation to adjacent agentic systems and limitations

The literature around VulAgent now spans the broader vulnerability lifecycle. Detection-oriented systems include VulAgent itself, MAVUL, VulTrial, MulVul, and VulnAgent-X; management-oriented systems include AgenticVM, which reduces raw scanner outputs into prioritized queues and predicts missing CVSS attributes; repair-oriented systems include VulnResolver and VulDebugger; exploitation and PoC-generation systems include PAGENT and SLYP (Arifin et al., 3 May 2026, Wu et al., 26 Jan 2026, Liu et al., 10 Apr 2025, Desai et al., 8 Apr 2026, Lee et al., 6 May 2026, Zhang et al., 20 Jan 2026). This suggests a wider interpretation of “VulAgent” as an agentic vulnerability-analysis stack rather than a detector alone.

That expansion does not remove the core limitations identified by the detection papers. VulAgent itself is evaluated only on PrimeVul and SVEN, and the paper notes broader scaling concerns for larger projects and more languages (Wang et al., 15 Sep 2025). VulnAgent-X reports concrete failure modes that remain difficult even with bounded context expansion: missing build or runtime assumptions account for 27.0% of analyzed failures, implicit helper-function semantics for 23.5%, incorrect reachability estimation for 18.0%, over-generalized pattern matches for 16.5%, and noisy labels for 15.0% (Meng et al., 11 Mar 2026). Related systems also show that more interaction is not automatically better: VulTrial reports that increasing discussion rounds can increase pair-wise vulnerable predictions and reduce pair-wise correct prediction, whereas MAVUL reports that contextual refinement substantially improves pair-wise correctness (Widyasari et al., 16 May 2025, Li et al., 30 Sep 2025). The common lesson is that agent multiplicity must be paired with disciplined role design, structured outputs, and explicit validation criteria.

Taken together, the literature positions VulAgent as a security-specific form of agentic program analysis: one in which specialized language-model agents localize security-sensitive operations, construct explicit vulnerability hypotheses, query structured program context, and only then decide whether a report should survive as a real vulnerability finding. This is both the defining contribution of the named VulAgent framework and the organizing principle of the broader family of systems that now surround it (Wang et al., 15 Sep 2025).