Visa's Auto-Patching Agent: A Blueprint for Trust

By Lazar Milicevic · Published September 23, 2026 · 9 min read

Your CI just flagged a SQL injection in a dependency you touched last week. It's Thursday afternoon. You have a customer call in 40 minutes, a client demo tomorrow, and the actual fix — reading the CVE, tracing the call site, writing the patch, adding a regression test — is a two-hour job you'll compress into twenty stressed minutes. This is the exact loop Visa's new open-source security harness tries to close, and it's worth studying whether or not you ever run it. It ships a pattern most teams should copy: find, fix, adversarially review, then hand a human something that's already 80% done.

Below is what the Visa Vulnerability Agentic Harness actually does, where it will bite you, and how the same pattern maps onto the boring-but-expensive automations most small teams need — invoice processing, lead triage, contract review — without turning your agents loose on production data.

What Visa actually shipped

Visa released an open-source agentic security harness that chains an 11-stage pipeline: scan a target repository, identify vulnerabilities, generate a patch, run an adversarial "red team" panel of agents against that patch, and produce a report. The default configuration edits source files in the target repo. If you want detection-only behavior, you have to explicitly cap it at that stage.

Two things make this notable and neither of them is "AI writes code":

1. The adversarial panel is on by default. The agent that wrote the patch is not the agent that judges the patch. A separate ensemble tries to break the proposed fix — testing for regressions, incomplete sanitization, edge cases the original patch missed. Only patches that survive get promoted.
2. The harness assumes write access to the codebase unless you tell it otherwise. That's an aggressive default for a security tool, and it's a signal about where the industry is heading: high-trust automation with in-loop verification instead of low-trust automation with a human bottleneck.

You can read the announcement and repo directly on Visa's technology page — I'd recommend cloning it locally in an isolated sandbox before pointing it at anything you care about.

Why "find + fix + adversarial review" is the right pattern

Most AI coding tools stop at "here's a suggestion, human decides." That framing sounds safe but it's actually the failure mode. The human is the least reliable link — tired, context-switching, trusting the diff because it looks plausible. The Visa pattern flips the responsibility: the machine has to convince a hostile machine before it earns human attention.

Concretely, the loop looks like this:

Scan → Classify → Locate → Propose patch
                                 ↓
                    ┌────────────┴────────────┐
                    ↓                         ↓
             Adversarial agent 1      Adversarial agent 2
             (regression tests)       (bypass attempts)
                    ↓                         ↓
                    └────────────┬────────────┘
                                 ↓
                         Consensus report
                                 ↓
                          Human review

The single most important design choice is that the reviewer agents don't see the patch author's reasoning. They see the patched code, the original vulnerability, and their own mandate: prove this fix is insufficient. This is roughly the same pattern researchers have been publishing on under names like "constitutional AI," "debate," and "critic models" — Visa's contribution is packaging it as a runnable pipeline for a specific domain.

The 11 stages, roughly mapped

The harness isn't a black box. From the pipeline definition, the stages roughly break down as:

The stages you can safely turn off are 11 (writes) and, if you're just triaging, 6–10. The stages you should never turn off are 4 and 5 — context assembly is where most autonomous coding agents fail, and it's the difference between a patch that fixes the vulnerability and one that fixes a vulnerability while introducing two more.

Running it without wrecking your repo

If you're going to try this on a real codebase, don't. Try it on a fork first. Here's the minimum safe sandbox:

# 1. Fork or clone into a throwaway path
git clone https://github.com/your-org/target-repo /tmp/harness-test
cd /tmp/harness-test
git checkout -b harness-sandbox

# 2. Run harness in detect-only mode first
harness run \
  --repo /tmp/harness-test \
  --mode detect \
  --output ./harness-report.json \
  --no-write

# 3. Review findings manually
jq '.findings[] | {severity, file, cwe}' harness-report.json

# 4. Only then enable patch mode, still on the sandbox branch
harness run \
  --repo /tmp/harness-test \
  --mode patch \
  --adversarial-rounds 3 \
  --require-tests \
  --output ./harness-patched.json

A few flags matter more than they look:

• --adversarial-rounds: default is usually 1. Bump to 3+ for anything that touches auth, crypto, or input parsing. The marginal token cost is trivial compared to a bad patch shipping.
• --require-tests: refuses to emit a patch without a generated regression test. Turn this on and leave it on.
• --no-write: the harness will still produce diffs, it just won't apply them. This is the mode you want in CI.

The .harnessignore file (analogous to .gitignore) lets you fence off directories the agent must not touch — vendored dependencies, generated code, migrations. Use it.

Where this pattern breaks

I've now watched enough autonomous-patch demos to be honest about the failure modes.

Semantic-invariant bugs. The agent will happily rewrite a function to eliminate a null pointer, then break a subtle invariant the caller depended on. Adversarial panels catch about half of these — the half that shows up in existing tests. The other half only surfaces in production. If your test coverage is under 60%, the harness is a loaded weapon.

Prompt injection through code comments. If the target repo contains adversarial comments (someone else's supply-chain attack, or a malicious PR you haven't merged but is sitting in a branch), the patch-writing agent can be nudged. Visa's design mitigates this by isolating agent context per stage, but "mitigates" isn't "prevents."

Cost explosions on monorepos. The context-assembly stage is greedy by default. Pointing this at a 2M-line monorepo without scoping will burn through a serious token budget in one run. Scope it to a subdirectory or a set of changed files (--scope src/auth/) — the harness supports this and it's non-optional at scale.

False sense of coverage. The harness finds what its scanners know about. Novel logic bugs, business-logic authorization flaws, and race conditions are largely invisible to it. Treat it as a floor, not a ceiling.

The transferable pattern: guardrails, not gates

Here's why this matters even if you never touch the Visa harness. The pattern generalizes to any high-trust automation:

1. Isolate the actor from the reviewer. Different model, different prompt, different context. Not the same agent "double-checking" — that's theater.
2. Make the reviewer adversarial by mandate. The reviewer's job is not "confirm this is fine." It's "prove this is broken."
3. Require artifacts, not opinions. The reviewer must produce a failing test case, a bypass, or a concrete regression — not "looks good" or "I'm concerned."
4. Default to reversible actions. Write to a branch, emit a PR, produce a diff. Never mutate production state as the terminal step.
5. Cap blast radius explicitly. Scope, ignore-files, dry-run modes. Assume the operator will forget.

You can apply every one of those to a document-processing agent, a customer support triage agent, or an internal RPA workflow. The domain is different; the discipline is identical.

What this looks like for non-security agents

Let's translate the pattern into an invoice-processing pipeline, which is the automation most small teams actually need. Same 11-stage shape, different verbs:

pipeline:
  - stage: ingest
    action: pull_invoices_from_inbox
  - stage: classify
    action: identify_vendor_and_line_items
  - stage: extract
    model: claude-sonnet
    output: structured_json
  - stage: validate_syntax
    checks: [totals_match, tax_lines_present, po_number_format]
  - stage: cross_reference
    against: [known_vendors, open_purchase_orders]
  - stage: draft_action
    action: propose_gl_coding_and_approver
  - stage: adversarial_review
    model: claude-opus         # different model, hostile prompt
    mandate: "find one reason this posting is wrong"
  - stage: consensus
    require: adversary_signs_off OR flag_for_human
  - stage: emit
    output: draft_bill_in_accounting_system
    write: false               # human approves before post
  - stage: audit_log
    action: write_full_trace
  - stage: notify
    channel: slack

The adversarial-review stage is the one everyone skips and the one that matters most. In practice, running a second model with a "find the mistake" prompt catches ~15–25% of the errors the primary extractor makes in messy real-world documents — vendor name mismatches, currency confusion, duplicate invoices, off-by-a-decimal totals. It roughly doubles the token cost per invoice and eliminates most of the errors that would otherwise reach a human.

That's the actual trade: pay for the second pass, save the accountant's time, and catch the bad postings before they hit the general ledger.

A checklist before you enable auto-write on anything

If you're building or buying automation that acts on production systems, walk through this before flipping it on:

• Can the agent's action be reverted in under 60 seconds by one person?
• Is there a second, independent model reviewing before write?
• Does the reviewer have to produce a concrete artifact (test, bypass, contradiction) to block?
• Is there a hard scope limit (which repos, which folders, which vendors, which dollar amounts)?
• Is every action logged with the full prompt, model version, and input hash?
• Does the pipeline default to --no-write unless explicitly enabled?
• What happens if the agent's provider has a 30-minute outage mid-pipeline?
• Who gets paged when the adversarial reviewer disagrees with the actor?

If any of these are "we'll figure it out later," you're not ready to auto-write. You're ready to auto-draft. That's still valuable — a good draft is 70% of the work — and it keeps a human in the terminal step where the risk lives.

How BizFlowAI approaches this

The Visa harness is a security tool, but the harness pattern — actor agent, adversarial reviewer, scoped writes, full audit trail — is the same pattern we build for clients on the operational side: AP automation, contract review, lead triage, support-ticket classification. We use Claude agents in the actor role, a second model in the reviewer role with an adversarial prompt, and we default every pipeline to draft-mode with human approval on the terminal write. Same discipline, different domain.

If you're staring at a workflow where "an AI could do this, but I don't trust it to touch the real system yet," that gap is exactly what these patterns close. Book a discovery call and bring one workflow — we'll map it to an actor/reviewer/scope design and show you where the guardrails go before any code gets written.

Further reading

• Visa Technology Newsroom for the announcement and repo link
• OWASP LLM Top 10 — required reading before you deploy any agent with write access
• Anthropic's guidance on tool use and agent design — the practical patterns for scoping agent permissions cleanly

The lesson from Visa isn't that AI can now patch your code. It's that a well-designed adversarial loop makes autonomous action defensible. Copy the loop. Skip the hype.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.