Visa Vulnerability Agentic Harness (VVAH): an LLM pipeline that runs from static seed to validated fix
Visa Vulnerability Agentic Harness
At a glance
- What is it?
- VVAH is Visa's open-source Python harness for autonomous vulnerability discovery, remediation and validation. It ships a four-phase S0-S11 pipeline, multi-provider model routing, and a beta exploit verifier that only runs against localhost.
- Who is it for?
- Adopt VVAH if you already run an LLM-assisted review workflow and the slow step is triage rather than discovery, and if you can route model traffic to an approved Anthropic or OpenAI-compatible endpoint. Do not adopt it if you need a scanner that works without model spend, or if your targets cannot be sent to a provider endpoint at all.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 7 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 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The bottleneck VVAH targets is triage speed, not finding bugs
VVAH starts from an explicit claim: in AI-assisted vulnerability management the constraint is triage speed, not discovery. The README states that the project's primary effectiveness metric is Mean Time to Adapt (MTTA), defined as elapsed time from an AI-discovered exploitability to a validated fix in production. That framing explains most of the design. The pipeline does not stop at a list of suspected weaknesses; it carries findings through deduplication, chaining, structured reporting, and optionally through candidate fixes and adversarial validation of those fixes.
The intended user is a security engineer or application team already using an LLM somewhere in review, who has more candidate findings than reviewers. It is not a drop-in replacement for a conventional scanner. VVAH is built on learnings from Project Glasswing, Anthropic's initiative for AI-assisted vulnerability research, and its shipped profiles assume model access. The README also carries an authorized-use notice and a data egress warning: any role routed to `via: cli`, `via: sdk`, `via: openai` or `via: deepagents` sends prompt data to that provider endpoint. That constraint, not the code, decides whether VVAH is usable in a given organisation.
How the S0-S11 pipeline moves from a static seed to a graded finding
The pipeline is described in four phases. Phase 1 (S1-S3) maps the attack surface and builds a threat-aware plan. Phase 2 (S4-S6) runs multi-lens analysis plus adversarial verification to assess likely exploitability. Phase 3 (S7-S9) deduplicates, chains and emits structured findings as Markdown and SARIF 2.1.0. Phase 4 (S10-S11) proposes candidate fixes and validates them adversarially before adoption.
The seed is S0, and where it comes from depends on the profile. The shipped `default.yaml` and `full.yaml` profiles derive the seed from the model. `taint.yaml` uses rules mode, which requires operator-supplied source/sink YAML. That is a real fork in the workflow: rules mode gives you deterministic, inspectable input at the cost of writing the rules yourself, while the model-derived seed is available immediately but is itself a model output.
Underneath the phases, two mechanisms narrow what the models actually read. Reachable-code analysis uses AST and call-graph seeding to focus model review on relevant code paths rather than the whole repository, and interprocedural taint analysis supplies data-flow evidence alongside model-based review for supported application languages. A coverage backstop can pull unrecognised files into catch-all review chunks instead of silently excluding them, but the README is explicit that this backstop is best-effort and not a guarantee.
Three stated design choices drive finding quality: threat modeling before analysis, multi-agent deterministic voting to reduce false positives, and structured triage artifacts. The voting step is the one worth scrutinising. Deterministic voting over multiple agents reduces false positives, and it also multiplies model calls per candidate, which is a cost decision as much as a quality one.
Installing vvaharness and running a first scan
The package is named `vvaharness` and requires Python 3.11 or later. The README points to `docs/SETUP_GUIDE.md` for install and configuration; the repository ships a `pyproject.toml` with a setuptools build backend, so the normal install path is from the source tree.
python -m venv .venv
source .venv/bin/activate
pip install .Configuration comes from environment variables. The `.env.example` file is not installed by pip or pipx; fetch it from the source repository and copy it to `.env`. It auto-loads from exactly the working directory or home, so no `source` is needed, and shell-exported variables win over the file. A `.env` inside the scan target is ignored by default.
For the shipped default profile, one credential covers everything. `default.yaml` runs local S0 and then every model role `via: deepagents` with Anthropic, and `ANTHROPIC_API_KEY` also satisfies `via: sdk` roles when a profile's backends are only sdk and deepagents. No OpenAI key is needed.
cp .env.example .env
# then set ANTHROPIC_API_KEY in .envThe default profile stops after Phase 3 (S9). Phase 4 remediation and validation are disabled there; the README directs you to the first-scan section for enabling S10 and S11. Missing post-scan credentials skip S10 and S11 with a warning, and `--stop-after s9` is the explicit way to end at reporting. If you want to validate a collection and target without spending on models, `--stop-after ev` does that. The `.env.example` also warns about a parsing trap: a trailing comment is stripped only from a line that has a value, so `KEY= # note` hands `# note` to the product as the value.
Exploit verification in 1.4 is deliberately fenced in
Version 1.4.0 adds S6 exploit verification, which attacks a finding with real HTTP traffic so a confirmed finding arrives with evidence attached rather than waiting on a human to reproduce it. The README calls this a direct move on MTTA, since confirming exploitability is usually the slowest manual step between an AI-discovered weakness and a validated fix.
The safety envelope is unusually explicit, and it is the part to read before enabling anything. S6 is beta, API-only, localhost-only, and off unless `EV_API_COLLECTION` is set. It is additive and positive-only: it never drops a finding, and the static verifier keeps the verdict. Credentials for exploit verification are read only from `EV_AUTH_*` environment variables, never from a profile or a CLI flag, and a collection may name the auth scheme but never a value.
That last point is narrower than it sounds. The README states that other secrets can still reach the target on the wire: a token saved inside the collection's own requests, the client-key passphrase `EV_TARGET_CLIENT_KEY_PASSPHRASE`, and any hardcoded credential the attacker agent finds in the repository and replays. So the environment-variable rule protects the auth slot, not the whole request. If your collection embeds a bearer token, that token is still sent.
The companion command is `vvaharness ev-replay`. After you patch and redeploy, replay re-runs the confirmed attack against the target and reports whether it still lands. That is a regression test derived from the attack itself. The README states the project is not aware of another open-source harness that closes that loop, which is a claim about the field rather than a guarantee about your deployment.
Where VVAH is the wrong tool
The licence field on the repository is NOASSERTION even though the README badge, the `pyproject.toml` metadata and the source headers all say Apache-2.0. Treat the metadata mismatch as something to resolve internally before you depend on the package, since the file headers carry the full Apache text and the project metadata declares `license = "Apache-2.0"`.
More practically, VVAH is the wrong tool when you cannot send prompt data to a model provider. The egress warning is not qualified: roles routed to cli, sdk, openai or deepagents send prompt data to that endpoint. There is no documented offline mode, and the shipped profiles derive the S0 seed from the model. `taint.yaml` in rules mode removes the model-derived seed, but the later phases are still model-driven roles, so rules mode changes the input, not the dependency.
It is also the wrong tool if you need a scan that runs without model spend. Everything downstream of S0 consumes model calls, and the multi-agent voting step multiplies them by design. `--stop-after ev` is the one documented path that validates a collection and target with no model spend, and it only exercises exploit verification.
Two smaller limits matter in practice. The coverage backstop that catches unrecognised files is best-effort, so file-type coverage is not something to assume. And the repository is not currently accepting external code contributions, per the README and `CONTRIBUTING.md`. If your team's adoption path involves patching upstream, that path is closed; you fork instead.
Against a conventional SAST scanner
The real alternative is a conventional static analysis tool, and the difference is where the judgement happens. A SAST scanner encodes detection rules written by humans and applies them deterministically. The same input produces the same findings, and the rule that fired can be read. VVAH inverts that: the shipped `default.yaml` and `full.yaml` profiles derive the S0 seed from a model, and analysis is model-driven, with AST and call-graph seeding and interprocedural taint analysis narrowing the code the model sees.
That inversion buys reach into code paths no rule was written for, and it costs reproducibility. A SAST tool also runs without network egress and without per-scan model cost, which is exactly the constraint VVAH cannot satisfy. VVAH's answer to the accuracy problem is multi-agent deterministic voting plus adversarial verification in S4-S6, and its answer to the triage problem is structured output in Markdown and SARIF 2.1.0. SARIF matters here: it means VVAH findings can land in the same consumer as a SAST tool's findings, so the two can coexist rather than replace each other.
The honest split is that a SAST scanner is the right default for a repository you must scan continuously under a fixed rule set, and VVAH is worth the model spend when you want a threat-modeled pass over an attack surface and a route from finding to candidate fix. The README's own framing supports that split: the bottleneck it names is triage, which only exists after something has produced candidates.
Maintenance, upgrade cost and the pinned Anthropic client
The last push to the default branch was on 2026-09-11, the same day as the v1.4.0 release, and the project has shipped v1.2.0, v1.3.0 and v1.4.0 across roughly five weeks. The repository is not archived. That is a fast release cadence, and it has a cost: the `pyproject.toml` comments document a live compatibility hazard rather than a settled one.
"anthropic>=0.125.0,<1.0",
"openai>=3.7.0,<4",
"httpx2>=2.12.0,<3",The comment above the Anthropic pin explains that anthropic 1.0 removed temperature, top_p and top_k from the Messages methods, so passing one becomes a client-side TypeError that the 400-handler in `backends/llm/sdk.py` cannot catch. `langchain-anthropic` used to cap the version transitively, but 1.7.0 relaxed its bound to `<2.0.0`, so a fresh dependency resolution can select the breaking major. The note says to lift the cap only together with a backend change that stops sending temperature as a top-level keyword argument. In other words, an unpinned install can break in a way the harness cannot intercept.
Licence-wise, the source headers and package metadata declare Apache-2.0, and the repository carries a NOTICE file and a THIRD_PARTY_LICENSES.md. The GitHub licence field reads NOASSERTION. Apache-2.0 includes a patent grant and requires attribution and notice retention, but whether that fits your distribution model is a question for your own counsel, not something this review can settle.
Editorial conclusion
Adopt VVAH if you already run an LLM-assisted review workflow and the slow step is triage rather than discovery, and if you can route model traffic to an approved Anthropic or OpenAI-compatible endpoint. Do not adopt it if you need a scanner that works without model spend, or if your targets cannot be sent to a provider endpoint at all. Before committing, check docs/SETUP_GUIDE.md against your environment, run `vvaharness --stop-after ev` to confirm the collection and target wiring with zero model spend, and read docs/security.md on the coverage backstop rather than assuming unrecognised files are reviewed.
Frequently asked questions
What are the top 5 vulnerability scanning tools?
The README does not rank tools. It positions VVAH against a conventional static analysis scanner, which encodes human-written detection rules and applies them deterministically, while VVAH derives its S0 seed from a model in the shipped default and full profiles and emits findings as Markdown and SARIF 2.1.0.
What are the two main types of vulnerability scans?
The README does not divide scans into two types. It distinguishes seed modes instead: the shipped default.yaml and full.yaml profiles derive the S0 seed from the model, while taint.yaml uses rules mode, which needs operator-supplied source/sink YAML.
What are the four stages of vulnerability assessment?
VVAH's pipeline has four phases: Phase 1 (S1-S3) maps the attack surface and builds a threat-aware plan; Phase 2 (S4-S6) runs multi-lens analysis and adversarial verification; Phase 3 (S7-S9) deduplicates, chains and reports; Phase 4 (S10-S11) proposes and validates candidate fixes. Phase 4 is disabled in the shipped default profile, which stops after Phase 3.
What are the three main types of security assessments?
The README does not classify security assessments into three types. It describes VVAH's own outputs and constraints: findings as Markdown plus SARIF 2.1.0, an optional remediation and validation phase, and a beta exploit verifier that is API-only, localhost-only and off unless EV_API_COLLECTION is set.
Community notes