Inside VulnHunter: How Capital One Built an Agentic Code Security Scanner

The Plain-Speak: What Capital One Actually Released

Capital One didn’t just publish a white paper. They open-sourced VulnHunter, an agentic AI framework designed to autonomously find security vulnerabilities in source code. The core idea is simple to state but hard to execute: instead of a single monolithic LLM call that scans a file and guesses, VulnHunter orchestrates a team of specialized agents that plan, investigate, and validate before reporting a finding.

Under the hood, it’s a Python framework built on LangGraph. It targets GitHub repositories, ingests the codebase, and dispatches a Planner Agent to decide what to look for. That planner spawns Sub-Agent workflows that dive deep into specific code paths, tracing data flows and control flows to confirm whether a suspected vulnerability is actually exploitable. The output isn’t a wall of false positives; it’s a structured report with evidence chains.

This matters because static analysis has been stuck in a local maximum. Traditional SAST tools are fast but noisy. LLMs are context-aware but hallucinate. VulnHunter attempts to split the difference by giving the LLM agency—the ability to iterate, search, and verify—within a bounded, deterministic graph execution environment.

The Architecture of an Agentic Security Scanner

To understand why VulnHunter is different, you need to see the control flow. It’s not a single prompt. It’s a state machine where nodes are LLM calls with specific tool access.

The Planner Agent receives a high-level map of the repository—file trees, function signatures, import graphs. It doesn’t read every line. It uses this structural overview to hypothesize where vulnerabilities might live. “This repo uses Flask and has user input flowing into SQL queries. I should investigate SQL injection in these three files.”

The Sub-Agent Dispatcher then fans out. Each sub-agent is a LangGraph sub-graph with access to tools like grep, AST traversal, and a code-aware LLM. One sub-agent might trace how a specific HTTP parameter reaches a database cursor. Another might look for missing authentication checks on API endpoints. They operate concurrently, sharing a common state but not stepping on each other’s toes.

The Vulnerability Validator is the critical gate. It takes the evidence gathered by the sub-agents and applies a stricter prompt: “Given this code path and this suspected vulnerability, confirm whether it is exploitable. If not, explain why.” This is where most false positives die. The validator acts as a mini red-team, trying to construct a proof-of-concept mentally before signing off.

Finally, the Report Generator compiles only validated findings into a SARIF-compatible report that can plug directly into GitHub’s code scanning UI or any CI pipeline.

Why This Matters for Engineers and FDEs

For working engineers, VulnHunter represents a shift in how we think about LLM-powered tools. It’s not a copilot. It’s an autonomous agent that runs in CI, much like a linter, but with reasoning capabilities. The implication is that security review can shift left even further—not just catching syntax-level bugs, but reasoning about business logic flaws.

For FDEs (Forward Deployed Engineers), this is pure gold. If you’re in a customer-facing technical role, you’ve had the conversation: “How do we know your platform is secure?” VulnHunter gives you a concrete, open-source artifact to point to. More importantly, it’s a pattern you can adapt. The agentic architecture—planner, sub-agents, validator—is a blueprint for building domain-specific review tools. Imagine an FDE building a custom agent that checks a customer’s Terraform configurations against your platform’s best practices before a deployment. The same LangGraph skeleton works.

This also changes the demo dynamic. Instead of showing a static dashboard, you can show an agent actively hunting through code in real-time. It demonstrates technical depth and a proactive security posture. As we’ve discussed in our guide on how FDEs build trust with non-technical stakeholders, showing the work—not just the result—is often the difference between a stalled POC and a signed deal.

Getting Your Hands Dirty: How to Run VulnHunter

Capital One released VulnHunter under the Apache 2.0 license. You can clone it and run it against your own repos today. Here’s the quickstart path.

Prerequisites:

• Python 3.11+
• An OpenAI API key (GPT-4o is the default model; you can swap in others via LiteLLM)
• A GitHub personal access token with repo read permissions

Installation:

git clone https://github.com/capitalone/vulnhunter.git
cd vulnhunter
python -m venv .venv && source .venv/bin/activate
pip install -e .

Configuration: Create a .env file with your keys:

OPENAI_API_KEY=sk-...
GITHUB_TOKEN=ghp_...

Running a Scan: The CLI is straightforward. Point it at a GitHub repo URL and give it a high-level instruction.

vulnhunter scan \
  --repo https://github.com/your-org/your-repo \
  --instruction "Find SQL injection and XSS vulnerabilities in the web application"

The framework will clone the repo, build the structural index, and begin the agent workflow. For a medium-sized repo (10k-50k lines of Python), expect a full scan to take 5-15 minutes and cost a few dollars in API calls.

Customizing for Your Stack: The real power is in the tools/ directory. You can add custom tools for your language or framework. If you’re a Java shop, you can add a tool that understands Spring Boot annotations and route mappings. The planner agent will automatically incorporate any tool you register. This is where FDEs can shine—building custom toolkits for specific customer environments.

If you’re interested in the broader pattern of indexing a codebase for Q&A, check out how to build a codebase Q&A tool with LlamaIndex and Cloudflare Workers. The indexing strategies are complementary to VulnHunter’s approach.

A Balanced Engineer's Take: Strengths and Real-World Friction

Let’s be honest about where VulnHunter excels and where it’ll frustrate you.

Strengths:

1. False Positive Reduction is Real. The validator agent catches hallucinations that a naive “scan this file for bugs” prompt would miss. In Capital One’s internal testing, they saw a significant drop in noise compared to baseline LLM scans.
2. Extensible by Design. LangGraph’s state graph makes it easy to inject new tools or swap models. You’re not locked into OpenAI. The framework is model-agnostic at the architectural level.
3. CI-Native Output. SARIF support means it slots into existing GitHub Advanced Security workflows. No custom dashboard required.
4. Evidence Chains. Every finding includes the code path that led to the conclusion. This is critical for auditability and for convincing a skeptical engineering team that the finding is real.

Friction Points:

1. Cost and Latency. Multiple LLM calls per sub-agent add up. A single scan can burn through 100k+ tokens. For large monorepos, you’ll need to be strategic about scoping the scan.
2. Language Support is Uneven. The initial release is Python-first. The AST traversal tools are Python-specific. For other languages, you’ll need to build or adapt parsers. The agentic orchestration is language-agnostic, but the tools are not.
3. Non-Determinism. LLMs are probabilistic. Run the same scan twice, and you might get slightly different findings. This is a hard sell in regulated environments that demand reproducible security audits.
4. No Runtime Context. VulnHunter analyzes static code. It can’t observe actual data flows in a running application. Complex vulnerabilities that span multiple services or depend on deployment configuration will be missed.

This non-determinism challenge ties into a broader tension we’re seeing across the industry. As we covered in why AI advice made engineers 3x less accurate but 2x more confident, the veneer of thoroughness can mask gaps. A validator agent that “confirms” a finding with high confidence isn’t the same as a proven exploit. Treat VulnHunter as a highly intelligent grep, not a replacement for penetration testing.

FAQ: VulnHunter in the Trenches

Q: Can I use VulnHunter with local models to keep code on-prem? Yes. The framework uses LiteLLM under the hood. Point it at an Ollama endpoint or a self-hosted vLLM instance. Expect lower accuracy with smaller models—the planner and validator agents rely heavily on reasoning depth.

Q: How does this compare to Semgrep or CodeQL? Semgrep and CodeQL are pattern-matching and dataflow engines. They’re fast, deterministic, and have low false positive rates for the patterns they cover. VulnHunter is complementary. It catches vulnerabilities that don’t match known patterns—business logic flaws, complex authorization bypasses. Use both. Run Semgrep for the known-knowns, VulnHunter for the unknown-unknowns.

Q: What’s the minimum repo size for meaningful results? Below 1,000 lines of code, the planner agent doesn’t have enough structural context to make intelligent hypotheses. You’re better off with a direct LLM review. VulnHunter shines on repos with 5,000+ lines where the code graph is too large for a single context window.

Q: Can I use this to scan customer code during a sales engagement? Absolutely, with permission. This is a powerful FDE motion. Run VulnHunter against a prospect’s sample repo, redact any sensitive findings from the report, and present the results as a value demonstration. It shows technical sophistication and a genuine commitment to security. Just ensure you have explicit written consent and handle the code according to your company’s data handling policy.

Q: How do I stay updated on the project? Star the official GitHub repository. Capital One’s open-source office actively maintains it and has indicated they’ll be expanding language support based on community contributions.

Q: Does this relate to the agentic patterns in other tools I might build? Yes. The planner-dispatcher-validator pattern is generalizable. If you’re building an internal tool that needs to autonomously investigate a complex system—whether it’s code, infrastructure, or data pipelines—the same LangGraph skeleton applies. For a hands-on project that uses similar multi-agent orchestration, see how to build a multi-agent research assistant with Groq and Serper. The agent communication patterns are directly transferable.