Visa's VVAH 1.4 Adds Live Exploit Verification to an Agentic Security Pipeline

Visa's open-source Vulnerability Agentic Harness (VVAH) now includes an optional exploit-verification stage that can generate constrained HTTP evidence for an AI-discovered vulnerability and replay that exploit after a fix. The feature is currently documented as beta, API-only, localhost-only and off by default unless an exploit-verification collection is configured.

That distinction matters because an LLM-generated finding is not the same thing as a confirmed vulnerability. VVAH's newer design inserts an evidence-producing step between model analysis and remediation decisions instead of asking the model's narrative to serve as proof.

What VVAH is

VVAH is an open-source security-analysis harness from Visa. Its pipeline combines threat modeling, code analysis, adversarial verification, finding deduplication, remediation and validation.

The documented architecture uses an S0 static seed followed by eleven stages:

S0
static seed
  |
  v
S1–S3  discovery + threat modeling
  |
  v
S4–S6  deep dive + verification
  |
  v
S7–S9  synthesis + reporting
  |
  +--> S10 remediation
  |
  +--> S11 validation

The important addition is within S6: exploit verification can be used when a finding maps to an HTTP endpoint and the operator supplies a supported API collection.

Discovery is not proof

Traditional AI-assisted security analysis has a straightforward epistemic problem: a model can identify a plausible vulnerable code path without proving that the path is reachable and exploitable in the target environment.

VVAH separates those states.

A finding can begin as a model-generated triage candidate. Adversarial verification can then assess it. If the finding is suitable for the exploit-verification stage, the system can attempt to generate positive HTTP evidence against the authorized local target.

That creates a useful chain:

model hypothesis
      |
      v
security analysis
      |
      v
adversarial verification
      |
      v
optional live exploit evidence
      |
      v
human review

The live step does not make the entire pipeline deterministic. It provides an additional class of evidence for findings that satisfy its constraints.

S6 is deliberately constrained

The project documentation is unusually explicit about the boundaries of exploit verification.

It is:

• beta;
• API-only;
• positive-only and additive;
• off unless an API collection is configured;
• restricted to findings that map to supported HTTP endpoints;
• addressed in code to a loopback host;
• and intended for a target the operator is already running and authorized to test.

These constraints are not incidental implementation details. They define the security model.

A system that can turn an LLM finding into live exploit traffic needs a clear boundary between analysis and execution. VVAH's approach is to make that boundary narrow and explicit rather than treating arbitrary external targets as test environments.

What exploit verification changes

Without an execution step, a security workflow can end with:

The model believes this endpoint is exploitable.

With positive exploit verification, an eligible finding can instead produce:

The verification stage generated HTTP traffic against the configured local target and obtained evidence consistent with exploitation.

That is a stronger statement, but it is also narrower.

A failure to verify is not proof that the vulnerability is absent. VVAH explicitly describes the feature as positive-only: confirmation is actionable evidence, while non-confirmation remains unproven.

That is the right direction for an evidence system because network reachability, authentication state, runtime configuration and application behavior can all prevent a static hypothesis from reproducing.

ev-replay closes a second loop

The more interesting feature is not only first-time exploitation.

VVAH also documents vvaharness ev-replay, which re-runs a confirmed exploit after a fix has been deployed. The intent is to turn the original exploit evidence into a regression test for the security fix.

The lifecycle becomes:

find weakness
     |
     v
verify exploit
     |
     v
patch
     |
     v
replay original exploit
     |
     v
check whether it still lands

That is a different concept from asking a model whether a patch "looks correct." The regression signal is derived from the behavior that originally demonstrated exploitability.

The feature remains constrained and beta, so it should not be interpreted as a general replacement for full integration testing.

Why this is different from autonomous remediation

VVAH also contains remediation and validation stages, but the project separates those concerns.

The packaged documentation says remediation can propose or apply fixes, while validation evaluates the result. It also warns that generated fixes are not automatically production-ready and that operators should review and test them.

Exploit verification therefore occupies a useful middle position:

AI discovery
   |
   +--> remediation candidate
   |
   +--> exploit evidence
          |
          v
     human decision

The system does not need to assume that the model is correct simply because the model generated the patch.

The multi-model design is also important

VVAH is not tied to a single model provider for every role. Its documentation describes routes for Anthropic, OpenAI-compatible models and other configured backends.

That is relevant because security evidence should ideally be separated from provider identity.

If the same model that discovers a vulnerability also decides whether its own hypothesis is correct, the workflow has an obvious confirmation-bias problem. VVAH's architecture instead uses distinct stages and adversarial verification, although the exact independence of models depends on the configured roles.

The project does not publish a validated precision or recall figure yet. That limitation should remain visible when interpreting the system.

Live traffic changes the risk model

Exploit verification is also not a free safety upgrade.

The documentation says the stage sends real HTTP requests to a running target when armed. That means operators must treat the feature as a live security-testing capability rather than a read-only static analyzer.

The loopback restriction narrows the destination, but it does not determine what service is listening there. The operator remains responsible for making sure the target is authorized and disposable enough for the intended test.

That is a meaningful distinction from ordinary SAST tooling.

What the project still cannot prove

VVAH's own limitations are important here.

The project says its findings are LLM-generated and non-deterministic, published accuracy numbers are not yet available, code coverage is bounded, and remediation fixes still require human review and independent build/test validation.

Exploit verification is also limited to API findings and only produces positive evidence. A vulnerability that cannot be reproduced through the supplied collection remains unresolved rather than cleared.

These limitations prevent a stronger claim such as "VVAH automatically proves security." It does not.

A more accurate statement is that VVAH is building an evidence-producing security workflow in which some model-generated hypotheses can be tested against a constrained live interface.

Why this matters for agentic security

The Observatory's OpenAI Astra cybersecurity evaluation and FLOWSEAL information-flow research illustrate two other directions in AI security: evaluating increasingly capable models and constraining what agents can leak or access.

VVAH addresses a different operational problem: how to move from an AI-generated security hypothesis toward evidence that a human can act on.

That is especially important as AI security tooling itself becomes more autonomous. If an agent can find vulnerabilities faster than humans can triage them, the bottleneck shifts toward verification and remediation confidence.

VVAH's stated MTTA focus is consistent with that problem: shorten the path from suspected exploitability to evidence and then to a validated fix.

What remains uncertain

The current public documentation does not establish how often exploit verification confirms real vulnerabilities, how its confirmation rate compares with manual reproduction, or how much it reduces remediation time across a representative portfolio.

The project also has no published precision/recall benchmark in the current documentation. The claim that exploit verification improves triage speed is therefore an architectural objective, not a quantified independent result.

Finally, live exploit evidence is only one kind of security evidence. Authentication differences, non-HTTP attack paths, race conditions, environment-specific behavior and destructive effects can all require manual testing.

Why this matters

The important change in VVAH is not that an AI system can write a security report. Many systems can do that.

It is that the workflow is being designed around a stronger boundary between prediction and proof:

• models generate and analyze hypotheses;
• verification challenges those hypotheses;
• optional exploit verification can produce positive HTTP evidence;
• remediation can propose a fix;
• exploit replay can test whether the original attack still works;
• and humans remain responsible for final acceptance.

That is a more defensible architecture for agentic security than treating an LLM's confidence as evidence.

Sources and further reading

• Visa Vulnerability Agentic Harness — GitHub
• VVAH — Features & Capabilities
• Visa — open-source vulnerability harness announcement
• VVAH — Changelog

Related Digital Observatory coverage: OpenAI Astra's critical cybersecurity evaluation, FLOWSEAL's information-flow approach to agent privacy, and GitHub AI Scan's security-control layer.