Capital One’s VulnHunter
from source code to live attack

VulnHunter’s Hunt workflow began with the pinned crAPI source. It mapped exposed entry points, traced attacker-controlled data toward sensitive operations, formed hypotheses, and used focused subagents to challenge weak ideas before packaging what survived.

The interesting part came next. Generated tests registered fresh crAPI users, logged in through the application’s own API, obtained JSON Web Tokens, and exercised the live local target. There were no preloaded crAPI accounts driving the selected examples. Source understanding became authenticated application behavior that a reviewer could inspect.

That is a meaningful capability signal. It also needs a boundary.

This was one controlled, non-blind run. Public crAPI solution material remained readable. VulnHunter’s separate Fix and Verify workflows did not run. The study does not establish operation against a live target without source, accuracy, repeatability, production readiness, or net labor saved.

The right conclusion is narrower and more useful: for this source-led application and API use case, VulnHunter carried a material part of the path from code analysis into live authenticated testing.

The run used three different layers that are easy to collapse if they all get called “the harness.”

VulnHunter’s upstream repository also contains a native batch and benchmark harness. That tooling was present in the project, but it was not the custom experiment harness used here. The naming matters because the responsibilities are different: VulnHunter analyzed, the experiment harness controlled and recorded, and a human had to decide what the evidence meant.

The architecture was less about adding another layer of AI than keeping those responsibilities from bleeding into one another.

The complete review set contained 46 candidate packages. A candidate package is a lead with a hypothesis, code path, proof material, and machine test state—not a confirmed finding.

Those numbers describe workflow state. They are not 39 vulnerabilities, and they cannot be used as an accuracy or false-positive score because the run lacked a locked, independently scored ground-truth set.

One reproduced example involved Broken Object Level Authorization (BOLA). BOLA occurs when an application confirms that a user is logged in but fails to confirm that the user owns the specific record named in the request. In the retained test, a fresh attacker identity supplied another user’s vehicle identifier and received the corresponding location data.

That is useful reproduction evidence. It is still not the entire finding.

The package included the endpoint, request shape, source location, classification, proof-of-concept material, and runnable test. The curated record did not yet resolve the named reviewer, business impact, Common Vulnerability Scoring System (CVSS) score, affected asset ownership, ticket routing, approved remediation, or validation plan. It also split the operator path across a proof document, test, and shared helper rather than presenting one complete intake record.

That package boundary cannot prove VulnHunter is unable to produce those fields. It shows what was and was not present in this experiment’s retained package.

The experiment did not make manual penetration testing irrelevant. It made the handoff easier to see.

VulnHunter was well suited to fast, repeatable work close to the source: building an application map, tracing many candidate paths, generating concrete tests, and preserving technical material for review. A human tester still owned the parts that depend on judgment across systems and organizations: whether the scenario matters, which conditions are realistic, how attacks chain, what the business impact is, whether the evidence clears the finding bar, and what deserves priority.

That division is not a consolation prize for the human. It is the operating model.

The agent can compress a large amount of structured exploration. The program gains value when the next stages can absorb that work without burying reviewers in unresolved packages. If human validation remains the narrowest point, candidate production alone does not show that the program has scaled. It may simply show that the queue moved.

The next evaluation therefore has to measure both sides of the handoff: what the tool produces and what a practitioner still has to do before the organization can act.

The current run demonstrated a tool capability and an experiment system. It did not demonstrate an enterprise integration. The useful next move is to test that larger operating path deliberately.

A bounded proof of concept should ask whether the system can:

1. accept an approved source revision, running target, rules of engagement, test identities, and explicit time and cost limits;
2. execute inside a controlled boundary with observable startup, health, progress, refusal, and teardown behavior;
3. normalize tool output into a review record with enough evidence, context, and lineage for efficient human triage;
4. keep machine state separate from named-human disposition;
5. route accepted work into the organization’s existing vulnerability-management system rather than creating a competing queue;
6. support remediation and independent retest without allowing the testing authority to change production or close its own findings; and
7. measure reviewer effort, repeatability, integration burden, and total operating cost—not merely how many candidates the agent can generate.

That path is a proposal, not a description of what this run already achieved.

It is also where the investment decision becomes real. An agentic tool may be fast and technically capable while still creating an expensive evidence-conversion problem. Another may appear less expansive but fit the intake, review, remediation, and audit path better. A mixed approach may win.

This field study tested one slice of VulnHunter. That boundary should not hide what the repository gives the security community beyond this run.

Several design choices are useful techniques in their own right: start from an attacker’s path through the code rather than a generic checklist; ask a separate phase to disprove a weak hypothesis; preserve phase outputs as files another process can inspect; keep verification non-mutating and separate from the work that proposed the fix; expose a stable scan manifest for downstream systems; and refuse to turn failed agent execution into a clean bill of health. Unknown coverage should remain unknown.

Those choices cannot settle the product decision, and appreciation cannot soften the evaluation boundary. The respectful response to an open contribution is neither applause without testing nor criticism without context. It is to run the system, show the boundary, report what survived, identify what still has to be engineered, and return the lessons to the field.

Capital One gave the industry something concrete to examine, challenge, adapt, and improve. That deserves credit—and careful use.