Visa ha ampliato il funzionamento del Visa Vulnerability Agentic Harness, il framework open source progettato per individuare vulnerabilità software mediante agenti di intelligenza artificiale. La nuova versione non si limita più a identificare e verificare i problemi di sicurezza, ma può generare autonomamente una correzione, modificare i file sorgente presenti nella copia di lavoro del repository e sottoporre la patch a un panel di validazione avversariale prima che venga esaminata da un essere umano. Una singola scansione può attraversare tutte le undici fasi della pipeline e arrivare fino alla modifica del codice, a meno che l’operatore non interrompa esplicitamente il processo prima delle fasi di remediation.
L’evoluzione di VVAH arriva mentre Visa sta ampliando anche le attività di Visa Consulting & Analytics e si inserisce in un contesto nel quale la sicurezza degli agenti AI sta diventando un problema operativo sempre più concreto. Diciotto giorni prima dell’annuncio, Tenet Security aveva presentato al DEF CON 34 GhostJacking, una catena di attacco nella quale un agente legge da un file di log un payload controllato dall’attaccante e utilizza successivamente credenziali valide per modificare il DNS. Poco prima, Steve Wilson, Chief AI and Product Officer di Exabeam e co-responsabile del progetto OWASP Top 10 for LLM Applications, aveva sostenuto un principio differente: consentire all’agente di proporre una modifica infrastrutturale, ma impedire che possa attribuirsi autonomamente l’autorità necessaria per eseguirla. Secondo Wilson, le indicazioni di sicurezza inserite nei prompt influenzano il comportamento del modello, ma non costituiscono controlli vincolanti, motivo per cui l’autorizzazione dovrebbe essere gestita esternamente al modello.
La posizione di Visa parte invece dalla constatazione che il principale collo di bottiglia nella gestione delle vulnerabilità si è spostato. Secondo Rajat Taneja, presidente della divisione Technology di Visa, i modelli di intelligenza artificiale stanno ormai individuando vulnerabilità con una velocità superiore a quella storicamente raggiungibile dai team umani e il problema principale non è più semplicemente scoprirle, ma correggerle e dimostrare che la correzione sia realmente efficace. VVAH è stato quindi esteso da una pipeline orientata a “scoprire, verificare e segnalare” a un ciclo che comprende scoperta, verifica, remediation, validazione e iterazione. Quando una patch non riesce a neutralizzare l’exploit, il risultato della validazione viene trasformato in feedback strutturato e riutilizzato dal tentativo successivo.
Il framework nasce dal lavoro svolto da Visa nel Project Glasswing di Anthropic. Durante il progetto, Visa ha utilizzato Claude Mythos per analizzare la propria infrastruttura, che supporta miliardi di transazioni giornaliere, osservando la capacità del modello di trasformare vulnerabilità apparentemente limitate in exploit concretamente funzionanti. La prima versione di VVAH utilizzava esclusivamente Mythos e proprio quella fase ha mostrato a Visa il potenziale dei modelli capaci di effettuare ragionamento semantico sui percorsi di attacco. Successivamente il framework è stato reso indipendente dal singolo modello e pubblicato su GitHub.
La crescita del repository è stata rapida. Il 20 luglio contava 595 stelle e 97 fork, mentre al 25 agosto aveva superato le 2.300 stelle e i 300 fork. Taneja ha inoltre stimato un rapporto tra cloni e visitatori vicino al 9% e ha indicato che alcune aziende di grande rilievo hanno già iniziato a utilizzare il framework. Visa continua tuttavia a controllare direttamente lo sviluppo del progetto: il repository non accetta attualmente contributi di codice esterni, quindi il fatto che VVAH possa modificare il codice dei repository sui quali viene eseguito non implica che le modifiche degli utenti confluiscano nel codice sorgente dello stesso framework.
Alla base della nuova pipeline si trova anche una revisione del modo in cui viene rappresentato il codice da analizzare. La scansione è stata rifattorizzata attorno a un grafo astratto delle chiamate costruito dall’albero sintattico, che permette di rappresentare le chiamate alle subroutine e i possibili percorsi attraversabili da un attaccante. Secondo Visa, questo approccio consente di ridurre il consumo di token fornendo contemporaneamente più contesto al modello e migliorando il ragionamento relativo all’effettiva sfruttabilità delle vulnerabilità. La piattaforma aggiunge inoltre osservabilità sulle diverse fasi del processo, visualizzazioni in tempo reale dell’avanzamento e misurazioni del tempo necessario per passare dalla scoperta alla risoluzione.
Questa misurazione è sintetizzata da Visa nell’MTTA, Mean Time to Adapt, una metrica sviluppata insieme all’infrastruttura del framework. Nella formulazione più sintetica, l’MTTA rappresenta il tempo che intercorre tra la scoperta di un percorso di attacco e la sua risoluzione, con casi nei quali Visa afferma di essere passata da tempi nell’ordine delle settimane a tempi nell’ordine delle ore. Il concetto è però utilizzato con più definizioni. Nel materiale pubblicato in precedenza comprende l’aggiornamento dell’inventario, il numero di percorsi sfruttabili per release e la durata del ciclo di validazione, mentre il repository fa riferimento anche al tempo che trascorre dalla scoperta tramite AI fino alla disponibilità di una correzione validata in produzione. Il punto comune è che la metrica non vuole limitarsi al numero di vulnerabilità corrette, ma includere l’effettiva validazione della remediation. Taneja considera per questo l’MTTA una delle metriche strategiche principali: il parametro rilevante non diventa quanti problemi vengono scoperti, ma quanto rapidamente l’organizzazione riesca ad adattarsi e a neutralizzarli.
L’automazione non elimina tuttavia il controllo umano. VVAH non inserisce direttamente la patch nel ramo di produzione né effettua autonomamente il merge. Visa definisce il sistema un framework e non uno strumento di merge: nella fase 10 vengono scritte le correzioni candidate nella copia di lavoro del repository, mentre la fase 11 sottopone ogni patch a un panel di validazione avversariale. Il risultato può essere “validato”, “validazione fallita” oppure “necessita di revisione”. La validazione cerca di stabilire se la patch neutralizzi effettivamente l’exploit che aveva dimostrato la vulnerabilità, ma non sostituisce il normale flusso di compilazione, build, test, code review e integrazione utilizzato dal team di sviluppo.
La fase 11 opera inoltre in sola lettura e VVAH non compila, non crea automaticamente una build e non esegue i normali test software sull’albero modificato. La correzione prodotta dall’agente deve quindi continuare a essere verificata nell’ambiente di sviluppo dell’organizzazione. Visa colloca il controllo umano in tre punti: prima dell’esecuzione del framework, nella revisione delle patch generate e prima del merge definitivo. La decisione finale sull’adozione di qualsiasi correzione rimane quindi nelle mani dei team di sicurezza e di ingegneria.
La distinzione rispetto al modello di autorizzazione proposto da Wilson riguarda soprattutto il momento nel quale viene applicato il gate. Nella sua impostazione, una modifica ad alto impatto dovrebbe richiedere un’autorizzazione prima ancora di essere eseguita. Nel flusso predefinito di VVAH, invece, l’autorizzazione umana viene fornita prima dell’avvio dell’intero strumento e torna a intervenire dopo che la patch è stata materialmente scritta nella copia di lavoro. Rimangono comunque separati dal modello sia l’autorizzazione generale all’esecuzione sia la revisione e l’approvazione finale. Visa specifica inoltre che VVAH è destinato a operatori autorizzati che lavorano su codice di loro proprietà all’interno di ambienti controllati.
Questo principio è coerente con il modello di governance descritto da Visa nel proprio white paper, che include tra i dodici principi non negoziabili l’affermazione secondo cui gli agenti AI devono essere trattati come identità. Un agente che modifica sistemi o codice deve quindi operare con privilegi limitati, autorizzazioni circoscritte, tracciabilità delle operazioni e governance IAM. Il principio del minimo privilegio rimane particolarmente importante perché VVAH può arrivare a modificare file sorgente e viene eseguito con privilegi sufficienti per accedere al repository analizzato.
Per questo motivo, l’ambiente operativo nel quale viene eseguito il framework diventa una parte essenziale della sicurezza. Visa raccomanda di definire con precisione i repository ai quali il sistema può accedere, utilizzare ambienti temporanei, limitare le credenziali disponibili, evitare la presenza di segreti di produzione e restringere l’accesso di rete al repository di destinazione e agli endpoint dei modelli necessari. Il problema è particolarmente rilevante proprio alla luce di attacchi come GhostJacking, nei quali dati letti da un agente possono trasformarsi indirettamente in azioni operative. Il README segnala inoltre che i ruoli instradati attraverso backend SDK, OpenAI o DeepAgents inviano i dati presenti nei prompt verso gli endpoint dei rispettivi provider.
Un approccio prudente consiste quindi nell’utilizzare inizialmente VVAH soltanto per la parte di analisi. Il framework può essere eseguito con l’opzione --stop-after s9, fermando la pipeline prima della fase nella quale vengono modificati i file sorgente e consentendo al team di esaminare preventivamente l’output SARIF. Solo dopo avere definito responsabilità, autorizzazioni, ambiente di esecuzione e processo di revisione può essere attivata la remediation automatica.
La validazione della patch rimane distinta anche dalla verifica completa della vulnerabilità nel prodotto finale. Il verdetto prodotto dalla fase 11 riguarda la capacità della correzione di contrastare l’exploit costruito durante l’analisi, mentre build, test, revisione del codice e una nuova verifica della vulnerabilità continuano a essere responsabilità del normale processo di sviluppo. Prima del merge è quindi necessario verificare che il codice corretto compili, superi i test e non introduca regressioni o nuove condizioni di rischio.
Visa utilizza già direttamente il framework sul proprio codice. L’azienda si definisce il “cliente zero” di VVAH e afferma di avere deciso di rendere disponibile il progetto open source soltanto dopo averne verificato internamente l’impatto. Una delle caratteristiche ritenute più importanti riguarda l’inserimento del contesto aziendale nell’analisi: VVAH può combinare informazioni provenienti da CMDB, modelli di minaccia e valutazioni del rischio di business, andando oltre la semplice individuazione tecnica della vulnerabilità. Il sistema cerca così di determinare quali problemi debbano essere corretti per primi sulla base del funzionamento reale dell’organizzazione e dell’esposizione associata ai diversi componenti.
La nuova versione amplia anche l’orchestrazione multi-modello. VVAH era stato progettato fin dall’inizio per non dipendere necessariamente da un solo modello, ma la scelta del backend può ora essere configurata separatamente per ciascuna fase della pipeline senza modificare il codice del framework. Taneja ha indicato, ad esempio, che Mythos presenta un recall molto elevato mentre Opus offre una precisione particolarmente elevata, rendendo possibile utilizzare modelli differenti in base alla funzione svolta. Nell’ensemble possono essere inserite anche le versioni più recenti dei modelli GPT e modelli open-weight, questi ultimi particolarmente utili quando il costo di elaborazione rappresenta un fattore rilevante.
La scelta del modello diventa quindi una decisione relativa alla singola fase e non più necessariamente all’intera scansione. Il runtime condiviso consente di mantenere configurazione, prompt tuning e cache a livello comune, mentre l’orchestratore può inviare compiti differenti ai backend ritenuti più adatti. Rispetto alla versione di giugno è stato inoltre rimosso un limite importante: inizialmente l’applicazione delle correzioni richiedeva un backend Anthropic, mentre i backend compatibili con OpenAI potevano essere utilizzati soltanto per produrre report. L’attuale implementazione estende remediation e validazione anche ai modelli compatibili con OpenAI e ai modelli open-weight attraverso un runtime condiviso indipendente dal provider, anche se il routing predefinito delle relative fasi continua a utilizzare Anthropic.
L’orchestrazione multi-modello richiede comunque una valutazione autonoma da parte delle organizzazioni. Precisione e recall variano in base al modello e alla fase e il repository non pubblica ancora dati completi che permettano di confrontare quantitativamente tutte le configurazioni. I team che adottano VVAH devono quindi misurare direttamente il comportamento dei modelli impiegati, soprattutto nelle fasi che generano o validano modifiche del codice e che presentano di conseguenza un impatto potenziale maggiore.
L’interesse verso strumenti di questo tipo si colloca in un mercato nel quale la sicurezza degli agenti AI sta diventando una priorità per molte imprese. Una ricerca VentureBeat Pulse relativa al secondo trimestre del 2026 ha rilevato che il 59% delle organizzazioni prevede di adottare o sostituire strumenti dedicati alla sicurezza degli agenti entro l’anno, mentre l’82% continua ad affidarsi principalmente ai controlli messi a disposizione direttamente dai provider. Visa ha inoltre annunciato l’intenzione di contribuire con VVAH all’Open Secure AI Alliance di Nvidia come framework indipendente dal modello e di collaborare al Project Lightwell, l’iniziativa da 5 miliardi di dollari promossa da IBM e Red Hat per rafforzare i componenti open source.
L’altra componente dell’espansione riguarda Visa Consulting & Analytics. La divisione sta introducendo workshop rivolti ai dirigenti, valutazioni della maturità basate sul modello operativo di VVAH e roadmap dedicate alla prioritizzazione del rischio informatico. La maturità viene espressa attraverso un punteggio da uno a cinque collegato al framework NIST. L’espansione dei servizi di consulenza deriva anche dalle richieste ricevute da organizzazioni interessate a utilizzare il framework ma prive delle competenze o dell’infrastruttura necessarie per integrarlo autonomamente nei propri processi.
Il modello operativo proposto da Visa sposta quindi l’attenzione dalla semplice capacità dell’intelligenza artificiale di individuare vulnerabilità alla costruzione di un ciclo completo di remediation. VVAH può scoprire un problema, dimostrarne l’effettiva sfruttabilità, produrre una patch, verificare in maniera avversariale se la correzione interrompa l’exploit e, in caso contrario, utilizzare il fallimento come input per un nuovo tentativo. Gli esseri umani rimangono responsabili dell’autorizzazione iniziale, della revisione del codice e dell’approvazione finale, mentre build, test e integrazione restano all’esterno della pipeline agentica. Il cambiamento principale è quindi nell’ordine del lavoro: invece di consegnare ai team una quantità crescente di segnalazioni da analizzare manualmente, il sistema tenta di portare fino alla revisione umana una vulnerabilità già verificata e accompagnata da una correzione che è stata sottoposta a un primo tentativo strutturato di compromissione.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)