Il 16 luglio 2026 Capital One ha pubblicato VulnHunter, uno scanner di sicurezza agentico rilasciato con licenza Apache 2.0. Il sistema è distribuito come insieme di skill componibili per Claude Code, gira su Claude Opus e ha taggato la versione v0.1.0 su GitHub il 18 luglio 2026, dopo una validazione interna su migliaia di repository distribuiti su decine di aree di business.
Capital One è una banca Fortune 100 che opera sotto alcuni dei regimi di governance software più severi al mondo. Questo contesto rende il rilascio significativo a livello architetturale: un'istituzione fortemente regolamentata ha portato l'analisi di sicurezza agentica dall'esperimento alla produzione, per poi pubblicare il sistema funzionante come codice aperto. Il repository github.com/capitalone/vulnhunter ha raccolto 539 stelle e 71 fork in pochi giorni, e il rilascio ha generato un thread tecnico molto attivo su Hacker News. Il progetto è arrivato completo di script di installazione, agente headless e harness di benchmarking: i segnali di uno strumento interno confezionato per l'uso esterno, altro che demo di ricerca. Per i leader ingegneristici il valore risiede in parte nello scanner stesso e soprattutto nel pattern di deployment che documenta.
Cosa è stato rilasciato: tre skill, una pipeline di falsificazione, un agente headless per CI/CD
VulnHunter è strutturato in tre skill componibili per Claude Code. /vulnhunt esegue la fase di caccia: mappa i punti di ingresso accessibili a un attaccante — API, messaggi di rete, upload di file — e traccia l'esecuzione in avanti attraverso la logica applicativa fino ai sink pericolosi. /vulnhunter-fix gestisce la remediation con modifiche al codice guidate dai test, dimostrazioni di exploit e generazione di pull request tramite la CLI di GitHub. /vulnhunt-fix-verify chiude il ciclo con una validazione indipendente che opera in modalità di pura lettura: l'esecuzione Bash e l'accesso di rete sono disabilitati by design. La logica completa del progetto è descritta nell'annuncio ufficiale di ingegneria.
Due scelte architetturali definiscono il sistema. La prima è il motore di falsificazione: prima che un finding raggiunga uno sviluppatore, la pipeline tenta attivamente di confutarlo, cercando assunzioni errate, lacune logiche o controlli di sicurezza esistenti in grado di bloccare il percorso di attacco. I finding che sopravvivono alla falsificazione arrivano con una catena di evidenze che mappa l'intero percorso di exploit, dal punto di ingresso all'impatto. La seconda è l'analisi forward attacker-first, che inverte la convenzione sink-first dell'analisi statica classica: invece di partire dalle chiamate pericolose e risalire all'indietro, l'agente simula un attaccante che parte dalle superfici raggiungibili dall'esterno e ragiona in avanti, come farebbe un red-teamer umano leggendo una codebase.
Il repository include anche l'infrastruttura di produzione. vulnhunter-agent/ è un runtime headless per pipeline CI/CD che apre issue GitHub in automatico; harness/ fornisce strumenti batch per scansionare liste di repository su larga scala tramite l'API di Anthropic. I prerequisiti sono concreti: la CLI di Claude Code con accesso a Opus, Python 3.12+, Git e la CLI di GitHub per il flusso di fix. Il codice è al 98,9% Python e il README dichiara apertamente che il framework dipende da capacità di ragionamento multi-step di classe frontier: le skill sono costruite e ottimizzate per modelli di classe Opus dentro Claude Code.
L'installazione segue il modello delle skill di Claude Code: clone del repository, script di installazione che copia le skill in ~/.claude/skills/, avvio di Claude Code con il modello Opus e invocazione di /vulnhunt su un target autorizzato. La distribuzione come skill è un punto chiave: la logica di sicurezza vive in pacchetti versionati di prompt e strumenti, leggibili riga per riga — una proprietà che i regolatori e i team di rischio interni apprezzeranno.
L'implicazione architetturale: l'output dell'agente è materiale da falsificare
L'idea più profonda di VulnHunter è una postura di sicurezza applicata all'agente stesso. Gli scanner basati su grandi modelli hanno storicamente sommerso i team di finding speculativi; la risposta di Capital One è strutturale: separare finder, fixer e verifier in ruoli distinti, dare al verifier una sandbox rigida — accesso ai file in lettura, zero shell, zero rete — e richiedere che ogni affermazione sopravviva a un passaggio avversariale di falsificazione prima di arrivare a un umano. È la separation of duties dei controlli finanziari, portata nell'architettura degli agenti. I team che costruiscono agenti interni per flussi ad alto rischio — code review, modifiche infrastrutturali, accesso ai dati — possono adottare questo pattern a tre ruoli così com'è, e il pattern viaggia ben oltre la scansione di sicurezza.
Il rilascio segna anche un punto di riferimento per l'adozione nei settori regolamentati. Una banca che pubblica strumenti di produzione costruiti su un agente di coding commerciale risponde, direttamente nel codice, a una domanda che i team di compliance pongono da due anni: la capacità dei sistemi agentici di operare dentro processi di change management di livello audit. Restano domande aperte, e LEON le segnala. La documentazione omette benchmark sui falsi positivi e numeri di accuratezza; la dichiarazione di validazione — migliaia di repository, decine di aree di business — arriva priva di metodologia pubblicata. Il ragionamento di classe Opus ha un costo reale per scansione che il README lascia privo di quantificazione. Il progetto è esplicitamente dual-use: la stessa analisi forward che trova percorsi di exploit per i difensori li descrive per gli attaccanti, e Capital One raccomanda l'iscrizione al Cyber Verification Program di Anthropic più un'autorizzazione esplicita per ogni codebase scansionata.
La decisione per la leadership ingegneristica
Eseguite un pilota delimitato e misurabile prima di qualunque impegno di piattaforma. Selezionate venti repository con finding storici noti, eseguite /vulnhunt in parallelo alla vostra baseline SAST esistente — Semgrep, CodeQL o lo scanner commerciale in uso — per trenta giorni e tracciate tre numeri: i percorsi di exploit confermati che la baseline ha mancato, il tasso di sopravvivenza alla falsificazione dei finding grezzi e i minuti di triage per finding presentato. Includete la spesa API per repository nel report finale, perché l'economia della scansione di classe Opus deciderà tra esecuzione a ogni commit e cadenza settimanale. Decidete su quei dati.
In parallelo, adottate il pattern anche a prescindere dal prodotto: finder, fixer e verifier in pura lettura come agenti separati con privilegi separati, e la falsificazione come gate obbligatorio prima che l'output di un agente raggiunga gli umani. Capital One ha pubblicato un blueprint funzionante di architettura agentica responsabile in un ambiente regolamentato: la cosa più utile che un leader ingegneristico possa fare questo trimestre è misurarlo contro il proprio stack.
Articolo di LEON — AI Agents & Systems
LEON copre il livello tecnico dove gli agenti AI vengono costruiti e distribuiti. Fonte: codice, documentazione, CVE.