VulnHunter: Capital One's Agentic Scanner That Argues Against Its Own Findings
Agentic AI security tool that applies proactive, attacker-first analysis directly to source code.
At a glance
- What is it?
- VulnHunter is an open-source Claude Code skill suite that walks forward from attacker entry points to exploitable sinks, then runs a falsification pass to kill weak findings. It needs Claude Opus, a Claude Code install, and a repository you are authorized to scan.
- Who is it for?
- Adopt VulnHunter if your team already works inside Claude Code with Opus access and you want findings that arrive with an exploit path and a proposed patch instead of a raw pattern list. Skip it if you need a scanner that runs without a frontier model, or if you cannot get your Anthropic account enrolled in the Cyber Verification Program, since the README warns that real-time cyber safeguards may block requests.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 35 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 19, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The false-positive problem VulnHunter was built to attack
Traditional static analysis works sink-first. It finds a dangerous call, then searches backward for a hypothetical attacker who could reach it. The README frames the cost of that direction plainly: teams get flooded with findings that are technically true and practically unreachable. A tainted variable that no request handler ever touches still shows up in the report.
VulnHunter inverts the walk. It starts at entry points an attacker can actually reach, which the README lists as APIs, network messages and file uploads, and reasons forward from there toward dangerous sinks. The audience is security engineers and development teams who already have a codebase and a review process, and who are tired of triaging. The project was developed internally at Capital One and released publicly, with the README noting that no single organization can solve supply chain risk alone. That framing matters for expectations: this is a tool built for people who read findings for a living, not a dashboard for executives.
How the falsification engine changes what reaches your queue
Finding a candidate vulnerability is the cheap part. The README describes a structured reasoning workflow that runs afterward and is explicitly designed to disprove the tool's own argument. It hunts for flawed assumptions, logic gaps, and security controls that would block the attack, and the README states that findings resting on unsupported assumptions are discarded immediately.
The pipeline is named in the README as Recon, then Parallel Hunt, then Adversarial Disprove, then a Capability Filter. Only what survives all four stages is emitted, and it arrives with an executable exploit, a mapped attack path, the capabilities an attacker would gain, and a proposed code change. That is a real design commitment, and it has a cost the README does not quantify: every stage is a model call, so a scan trades tokens for precision. If your repository is large and your budget is not, the falsification pass is the part that will decide whether the tool is affordable for you.
Hunt, fix and verify as three separate Claude Code skills
The suite is deliberately split so that the agent proposing a fix is not the agent grading it. The /vulnhunt skill does the hunting. The /vulnhunter-fix skill takes a confirmed finding and works test-first: it writes an exploit demo, creates a failing security test the README labels RED, implements the fix to reach GREEN, checks that the exploit is blocked without regressions, and cuts a pull request for review. The /vulnhunt-fix-verify skill is described as a completely separate, read-only agent that independently validates whether remediation actually worked, emitting a per-finding verdict.
One naming detail trips people up, and the README calls it out directly: the suite is VulnHunter, but the scanner command is the shorter /vulnhunt, while the remediation skill and the headless runtime keep the full spelling. The runtime lives in vulnhunter-agent/ and files GitHub issues, and harness/ drives batch scans across multiple repositories for benchmarking. Nothing in the README documents rollback for a bad fix, so treat the generated PR as a proposal that a human still reviews.
Installing VulnHunter and running a first scan
VulnHunter installs by copying skills into your Claude Code skills directory, not by adding a dependency to your project. The README gives this sequence for macOS and Linux, and the install script copies files rather than symlinking because symlinks can break find and glob behavior inside subagents.
git clone https://github.com/capitalone/vulnhunter.git
cd vulnhunter
# Copy skills into ~/.claude/skills/
./install.shOn Windows, the README points to the .cmd equivalents, run from cmd.exe or PowerShell, which copy into %USERPROFILE%\.claude\skills\. After pulling updates you re-run the install script, since the copy approach means your local skills go stale otherwise. Then you start Claude Code against Opus with the skill directories added, and invoke the scanner inside the session.
claude --model opus --add-dir ~/.claude/skills/vulnhunt --add-dir ~/.claude/skills/vulnhunt/phases
# Inside the Claude Code session, invoke:
/vulnhuntThe fixer has its own prerequisites: git, the GitHub CLI gh authenticated to your target repositories, and Python helpers installed from inside the vulnhunter-fix/ directory with pip install -e ".[dev]". Python 3.12 or newer is required only for the runtime agent and the benchmarking harness, not for the prompt-only scanner skills. Before you point any of this at a repository, the README's responsibility check applies: only scan code you are explicitly authorized to analyze.
Where VulnHunter is the wrong tool
The dependency on Claude Opus is the hard boundary. The README states the framework requires frontier Opus-class models and that you supply your own model access. If your organization runs scanners in an air-gapped CI runner, or standardizes on a different model provider, VulnHunter is not a drop-in replacement for the SAST tool already in your pipeline. There is no offline mode described.
The second boundary is the cyber-safeguard warning. The README states that running VulnHunter against an Anthropic account not enrolled in the Cyber Verification Program may cause real-time cyber safeguards to block requests and may flag your usage for cyber abuse. That is a policy constraint, not a bug, and it means the tool can silently fail to complete a scan on an unenrolled account. The README does not describe what a blocked request looks like in the output, so you have no documented signal to distinguish a clean scan from a suppressed one. Verify that distinction yourself before you rely on a zero-finding result.
VulnHunter against a conventional SAST scanner
Semgrep and similar pattern-based scanners run as deterministic binaries over source, produce the same output on the same input, and cost nothing per line scanned. Their rules are auditable and their execution is fast enough to gate a pull request. VulnHunter gives up all three of those properties. Its analysis is model-driven, so the same repository can yield different findings across runs, and the README offers no determinism guarantee.
What you buy with that trade is the reasoning layer Semgrep does not have. A Semgrep rule cannot tell you whether a control upstream actually blocks the path it flagged, because that requires reading intent across files. The falsification engine is VulnHunter's answer to exactly that gap, and the /vulnhunt-fix-verify agent exists because a fix proposed by a model needs an independent check. The honest comparison is not which tool finds more; it is that pattern scanners are cheap enough to run everywhere and VulnHunter is expensive enough that you run it where a false positive costs more than a token bill.
Licence, maintenance and what an upgrade costs you
VulnHunter ships under Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes. The repository includes LICENSE, SECURITY.md and CODEOWNERS at the top level, and an .oss-sync.json file that suggests the public tree is synchronized from an internal source. That is a distribution detail worth knowing: if the public repository is a mirror, upstream fixes may arrive in batches rather than continuously. Apache-2.0 also includes a patent grant, which matters if you embed the skills in a commercial product. None of this is legal advice; read the LICENSE file yourself.
The maintenance picture is straightforward from the repository facts. The last push was on 2026-08-15, and the only release listed is v0.1.0 from 2026-07-18. This is a young project with a single tagged release, so upgrade cost is currently low but so is the track record. Upgrades are manual by design: because install.sh copies files instead of symlinking, pulling a new commit does nothing until you re-run the install script, and the fixer's Python helpers need their editable install refreshed separately inside vulnhunter-fix/.
Editorial conclusion
Adopt VulnHunter if your team already works inside Claude Code with Opus access and you want findings that arrive with an exploit path and a proposed patch instead of a raw pattern list. Skip it if you need a scanner that runs without a frontier model, or if you cannot get your Anthropic account enrolled in the Cyber Verification Program, since the README warns that real-time cyber safeguards may block requests. Before trusting a scan, verify three things: that install.sh copied the skills into ~/.claude/skills/ rather than leaving stale files, that the fixer's Python helpers are installed with pip install -e ".[dev]" inside vulnhunter-fix/, and that gh is authenticated against the repository you intend to open PRs on.
Frequently asked questions
What does VulnHunter mean by a vulnerability?
VulnHunter treats a vulnerability as a defect an attacker can actually reach and exploit from an entry point such as an API, a network message or a file upload. Findings that depend on unsupported assumptions are discarded by the falsification engine before they reach you, so the tool's definition is narrower than a raw pattern match.
Is vulnerability scanning with VulnHunter illegal?
The README does not address legality directly, but it does include a responsibility check stating you should only scan code bases you are explicitly authorized to analyze. It also warns that running against an Anthropic account not enrolled in the Cyber Verification Program may trigger real-time cyber safeguards and flag your usage for cyber abuse.
What are the top vulnerabilities VulnHunter looks for?
The README does not publish a vulnerability taxonomy or a top-ten list. It describes the mechanism instead: the /vulnhunt skill maps attacker-accessible entry points forward to dangerous sinks and filters candidates through Recon, Parallel Hunt, Adversarial Disprove and a Capability Filter.
How do hackers find vulnerabilities, and does VulnHunter work the same way?
VulnHunter's README describes its approach as attacker-first forward analysis: it starts where a bad actor could enter, such as an API or an uploaded file, and reasons forward to see whether the attack truly succeeds. That mirrors an adversary's journey rather than searching backward from a dangerous code pattern.
Community notes