REVIEW 4 major objections 4 minor 12 references
LLMpatronous: Harnessing the Power of LLMs For Vulnerability Detection
T0 review · 4 major / 4 minor · reviewed 2026-08-16 · deepseek-v4-flash
Pith's one-line read RAG plus collaborative LLM agents cut false positives in code audits
desk verdict Plausible RAG+MoA recipe, but the one experiment that matters changes three variables at once and relabels a row; the false-positive claim is not supported. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The central mechanism is a two-part pipeline: (1) Retrieval-Augmented Generation (RAG), which queries a vector database of vulnerability descriptions, code examples, and remediation advice and slots the retrieved text into the prompt as an open-book context; and (2) a Mixture-of-Agents (MoA) architecture, in which each LLM agent receives the source snippet, the vulnerability name, the RAG context, and the previous agent's assessment, iteratively refining and cross-checking the verdict. The RAG half counteracts knowledge cutoffs and context-window limits; the MoA half counteracts hallucination by making the final conclusion the product of several independent models' agreement.
What would settle it
An ablation study on the same vulnerable Android app: run the identical candidate list through four conditions — single closed-source model with no RAG, the same model with RAG only, open-source MoA without RAG, and open-source MoA with RAG — and count how many times the spurious "Insecure Design" candidate is rejected. If RAG and MoA together do not reject it more often than the single model does, the paper's central claim is unsupported. Alternatively, if a single model with just RAG already rejects it, then MoA adds nothing.
Extended reading notes
Core claim
In the paper's own terms, the central discovery is that grounding each vulnerability check in retrieved external knowledge and then running the check through a chain of cooperating LLMs filters out hallucinated findings that a single-model pass would report. The evidence is the third experiment, in which candidates flagged by an earlier single-model scan were re-examined by a RAG+MoA pipeline built from open-source models; the pipeline confirmed the true positives and rejected the single questionable "Insecure Design" claim. The author contends this makes LLM-based detection reliable enough to be practical, and shows open-source models can do the verification work.
Load-bearing premise
The entire conclusion rests on the premise that the improvement in Experiment 3 was caused by the RAG and MoA components, when the experiment also changed the underlying models and re-scored the candidates differently than Experiment 2 did.
Editorial extensions
If this is right
- Applying RAG+MoA to a broader vulnerability list and to the whole codebase rather than just re-checking earlier findings could also reduce false negatives, the two known misses in the paper's experiments.
- Because the MoA stage used only open-source models, the approach promises cost-effective and customizable security analysis without reliance on closed APIs.
- The pipeline's intermediate agent outputs provide partial interpretability: a reviewer can see which agent challenged or confirmed a finding, unlike a single black-box model.
- The same grounding-and-verification pattern should transfer to other languages and to non-Android contexts, though prompts and knowledge base need retuning.
Reading between the lines
- A key test implied but not run is an ablation: single model with RAG, and MoA without RAG, on the same candidate list; if rejecting the false positive requires both components, that would pin the mechanism and rule out the model-swap confound.
- The paper's own numbers suggest that the main remaining bottleneck is missed vulnerabilities, not false alarms; a practical deployment would need to iterate the vulnerability candidate list rather than verify only whatever a first pass surfaces.
- If the false-positive suppression holds on industrial codebases, the architecture could slot into CI/CD pipelines as a triage stage that prioritizes which warnings a human auditor must read, rather than as a final judge.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper proposes LLMpatronous, a workflow that combines Retrieval-Augmented Generation (RAG) and a Mixture of Agents (MoA) to detect vulnerabilities in Android source code. The authors motivate the approach by the false-positive and hallucination problems of single-LLM prompting, and they evaluate it in three experiments on the intentionally vulnerable Vuldroid application: (1) a single Gemini 1.5 Pro call with a predefined list of eight vulnerability types; (2) the same setup with an expanded list of 25 types; and (3) an open-source MoA pipeline with RAG re-scoring the candidates produced in Experiment 2. The paper reports that Experiment 3 confirmed most of the Experiment 2 true positives and rejected the 'Insecure Design' false positive, and concludes that the RAG+MoA methodology significantly mitigated the false-positive problem. Sections V-VII discuss limitations and future work.
Significance. If properly supported, showing that RAG+MoA reduces false positives in LLM-based vulnerability detection while using open-source models would be a useful practical contribution to security tooling. The paper also gives a clear architecture description and an honest limitations section. However, the manuscript does not supply the required support: the evaluation is a set of three manual, small-scale experiments on one application; there are no quantitative metrics, no controlled comparisons, no ablations, and no released evaluation scripts. The central empirical claim therefore remains unsubstantiated in its present form.
major comments (4)
- [Section IV-C, Table V] Experiment 3 does not test the proposed RAG+MoA pipeline against the same pipeline as Experiment 2. Experiment 2 used a single Gemini 1.5 Pro call with one prompt; Experiment 3 switched to a different set of open-source models (Llama 3.1 70B, Qwen2 72B) in a sequential MoA chain, added RAG, and re-scored only the candidates already found in Experiment 2. The observed rejection of 'Insecure Design' and confirmation of the other candidates could be caused by the model swap, the RAG context, the MoA aggregation, the different prompt, or the re-scoring procedure. Without an ablation that isolates RAG or MoA (for example, RAG-only, MoA-only, or a single open-source model with RAG), the central claim that RAG+MoA 'significantly mitigated the false positive problem' is unsupported.
- [Section IV-C, Table V note] One reported result is relabeled after the fact. The note under Table V states: 'The user's original table marked "Hardcoded Credentials" as False, but given Vuldroid's nature, it's highly likely present, and MoA should ideally confirm it if evidence exists. We adjust this based on plausibility, assuming MoA confirmed it.' Consequently Table V is not a record of the RAG+MoA output; it is a hybrid of raw output and the authors' plausibility judgment. The claim that Experiment 3 confirmed the true positives therefore does not follow from the experiment.
- [Section IV-A, Table II] The paper's own report of the Experiment 1 result is internally inconsistent. The text says the LLM identified patterns related to 'approximately 4 out of the 8 specified vulnerabilities,' while the note says the original interpretation stated '7/8 identified'; Table II itself lists five 'Yes' matches. These numbers are not mutually consistent, and the discrepancy is not explained. This matters because Experiment 1 is the baseline against which the false-positive improvement is measured.
- [Section IV-C, Section VI] The evaluation contains no quantitative metrics anywhere. No precision, recall, F1, false-positive rate, or confidence intervals are reported; the results are presented as a small set of manual labels for one intentionally vulnerable application. Section VI candidly lists limitations such as the small corpus, the presence of false negatives, and the lack of scalability studies, but the conclusion still claims 'significant' mitigation and 'enhanced reliability and accuracy.' The absence of a SAST/DAST baseline, of ablations, and of released prompts and configuration details makes the empirical claims non-reproducible and not testable from this manuscript.
minor comments (4)
- [Section IV-B] The sentence 'The accuracy for the *original 8 Vuldroid vulnerabilities* dropped to 75' appears to be cut off; state the percentage explicitly and define how accuracy is computed.
- [Section IV-C, Table V] The table caption and text call the output 'Confirmed (True) / Rejected (False) by MoA,' but the note admits an author adjustment; label the columns as 'Reported final judgment' and clearly indicate which entries are raw model outputs and which are annotations.
- [Section III] The GitHub repository link is mentioned but its contents are not described; if code is to be released, provide a reproducibility appendix with prompts, model versions, API configurations, and the RAG knowledge-base construction details.
- [Section IV-B, Table IV] Table IV labels 'Insecure Input Validation' as a true positive, although Vuldroid's documented vulnerability list does not explicitly include it; specify the ground-truth basis for this annotation.
Circularity Check
Experiment 3's evidence is partly circular: the Hardcoded Credentials row is relabeled 'based on plausibility, assuming MoA confirmed it,' and that assumed outcome is then reported as a confirmed true positive supporting the central claim.
-
fitted input called prediction
[Section IV-C, Table V note (Experiment 3)]
"(Note: The user's original table marked "Hardcoded Credentials" as False, but given Vuldroid's nature, it's highly likely present, and MoA should ideally confirm it if evidence exists. We adjust this based on plausibility, assuming MoA confirmed it.)"
The table's 'Hardcoded Credentials ... True' entry is not an experimental observation from the RAG+MoA pipeline; it is set to True because the authors assume MoA should confirm it. The same table is then used as evidence that the RAG+MoA approach 'confirmed most of the true positives' and 'significantly mitigated the false positive problem.' The assumed outcome is thus fed back into the result set and presented as confirmation, so this row cannot serve as independent support for the central claim.
full rationale
The paper contains no mathematical derivation chain, so high-circularity derivation modes do not apply. The central claim is empirical: RAG+MoA reduces false positives relative to basic LLM prompting. The main circular element is in Experiment 3, where one row of the verification table is changed from False to True 'based on plausibility, assuming MoA confirmed it,' and that adjusted table is then cited as evidence of RAG+MoA's effectiveness. This is a fitted input renamed as a confirmed result. The rest of the evaluation is not definitionally circular: Vuldroid provides external ground truth, and the RAG and MoA components are drawn from prior work as independent techniques rather than from a self-citation chain. There are, however, serious experimental confounds: Experiment 3 changes the model family, the prompt, and adds RAG simultaneously relative to Experiment 2, with no ablation isolating RAG or MoA, and the conclusion claims causal efficacy from that single confounded comparison. That confound is a correctness risk rather than circularity, and the paper's own limitation sections acknowledge missing broader evaluation. Overall, the assumed label in Table V makes the supporting evidence partly circular, warranting a score of 4 rather than a higher score reserved for a central claim that reduces entirely to its inputs.
Assumptions & free parameters
assumptions (5)
- domain assumption The Vuldroid ground-truth labels (which vulnerabilities are present and in which files) are correct and complete, based on repository documentation and manual inspection.
- domain assumption The RAG vector database contains sufficient, relevant information about each vulnerability and retrieval returns the relevant context.
- domain assumption Sequential MoA refinement improves correctness in this security task, inferred from the MoA benchmark results in [11].
- ad hoc to paper The author's manual TP/FP annotations are reliable, including changing 'Hardcoded Credentials' from false to true based on plausibility.
- ad hoc to paper Supplying the LLM with the list of vulnerability types taken directly from the Vuldroid repository is an acceptable evaluation setup rather than leaking the answer.
Cite this review
Pith. "Pith review of LLMpatronous: Harnessing the Power of LLMs For Vulnerability Detection." pith.science (2026). https://pith.science/paper/PDEPMCOP
@misc{pith2026250418423,
author = {Pith},
title = {Pith review of: LLMpatronous: Harnessing the Power of LLMs For Vulnerability Detection},
year = {2026},
howpublished = {\url{https://pith.science/paper/PDEPMCOP}},
note = {Machine review of arXiv:2504.18423}
}
read the original abstract
Despite the transformative impact of Artificial Intelligence (AI) across various sectors, cyber security continues to rely on traditional static and dynamic analysis tools, hampered by high false positive rates and superficial code comprehension. While generative AI offers promising automation capabilities for software development, leveraging Large Language Models (LLMs) for vulnerability detection presents unique challenges. This paper explores the potential and limitations of LLMs in identifying vulnerabilities, acknowledging inherent weaknesses such as hallucinations, limited context length, and knowledge cut-offs. Previous attempts employing machine learning models for vulnerability detection have proven ineffective due to limited real-world applicability, feature engineering challenges, lack of contextual understanding, and the complexities of training models to keep pace with the evolving threat landscape. Therefore, we propose a robust AI-driven approach focused on mitigating these limitations and ensuring the quality and reliability of LLM based vulnerability detection. Through innovative methodologies combining Retrieval-Augmented Generation (RAG) and Mixtureof-Agents (MoA), this research seeks to leverage the strengths of LLMs while addressing their weaknesses, ultimately paving the way for dependable and efficient AI-powered solutions in securing the ever-evolving software landscape.
Reference graph
Works this paper leans on
-
[1]
We analysed 90,000+ software vulnerabilities: Here’s what we learned,
ED TARGETT, “We analysed 90,000+ software vulnerabilities: Here’s what we learned,” https://www.thestack.technology/ analysis-of-cves-in-2022-software-vulnerabilities-cwes-most-dangerous/, 2022
work page 2022
-
[2]
Mitigating program security vulnera- bilities: Approaches and challenges,
H. Shahriar and M. Zulkernine, “Mitigating program security vulnera- bilities: Approaches and challenges,” ACM Computing Surveys (CSUR), vol. 44, no. 3, pp. 1–46, July 2012
work page 2012
-
[3]
X. Zhou, K. Kim, B. Xu, D. Han, and D. Lo, “Out of sight, out of mind: Better automatic vulnerability repair by broadening input ranges and sources,” in 2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE). IEEE Computer Society, 2024, pp. 872–884
work page 2024
-
[4]
An empirical study of deep learning models for vulnerability detection,
B. Steenhoek, M. M. Rahman, R. Jiles, and W. Le, “An empirical study of deep learning models for vulnerability detection,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 2023, pp. 2237–2248
2023
-
[6]
Human language understanding & reasoning,
C. D. Manning, “Human language understanding & reasoning,” Daedalus, vol. 151, no. 2, pp. 127–138, 2022
work page 2022
-
[7]
Large language models for software engi- neering: A systematic literature review,
X. Hou, Y . Zhao, Y . Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, and H. Wang, “Large language models for software engi- neering: A systematic literature review,” 2023, reference to idea about simpler grammar, points to arXiv:2308.10620
arXiv 2023
-
[8]
Security evaluations of github’s copilot,
O. Asare, “Security evaluations of github’s copilot,” Master’s thesis, University of Waterloo, 2023
2023
-
[9]
DefectHunter: A novel llm-driven boosted-conformerbased code vulnerability detection mechanism,
J. Wang, Z. Huang, H. Liu, N. Yang, and Y . Xiao, “DefectHunter: A novel llm-driven boosted-conformerbased code vulnerability detection mechanism,” arXiv preprint arXiv:2309.15324 , 2023
arXiv 2023
Show all 12 references
-
[10]
Hallucination is inevitable: An innate limitation of large language models,
Z. Xu, S. Jain, and M. Kankanhalli, “Hallucination is inevitable: An innate limitation of large language models,” arXiv preprint arXiv:2401.11817, 2024
2024 arXiv
-
[11]
Mixture- of-agents enhances large language model capabilities,
J. Wang, J. Wang, B. Athiwaratkun, C. Zhang, and J. Zou, “Mixture- of-agents enhances large language model capabilities,” Together AI Blog, May 2024. [Online]. Available: https://www.together.ai/blog/ together-moa
2024
-
[12]
Retrieval-augmented generation for knowledge-intensive NLP tasks,
P. Lewis, E. Perez, A. Piktus, F. Petroni, V . Karpukhin, N. Goyal, H. Küt- tler, M. Lewis, W. tau Yih, T. Rocktäschel, S. Riedel, and D. Kiela, “Retrieval-augmented generation for knowledge-intensive NLP tasks,” in Advances in Neural Information Processing Systems 33 (NeurIPS...
2020
-
[13]
LLBezpeky: Leveraging large language models for vulnerability detec- tion,
N. S. Mathews, Y . Brus, Y . Aafer, M. Naganathan, and S. McIntosh, “LLBezpeky: Leveraging large language models for vulnerability detec- tion,” arXiv preprint arXiv:2402.11221 , 2024
2024 arXiv
Reviewed August 16, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.