Il manuale OWASP sul red teaming GenAI estende i test oltre il modello

OWASP ha pubblicato il proprio manuale sul red teaming GenAI il 20 ottobre, introducendo otto fasi di test che vanno oltre le risposte del modello per includere applicazioni e agenti connessi. La versione 1.0 affronta sicurezza, protezione e resistenza ai guasti nei sistemi che combinano contenuti generati con accesso ai dati e azioni. L'implicazione centrale è semplice: valutare un modello da solo lascia senza risposta interrogativi sul prodotto costruito attorno ad esso.

Il manuale OWASP sul red teaming GenAI mette in discussione una scorciatoia consolidata nella valutazione dell'affidabilità: trattare i risultati di sicurezza di un modello come prova valida per un'intera implementazione. Il red teaming consiste in test autorizzati che adottano la prospettiva di un avversario per scoprire vulnerabilità. Nei prodotti AI connessi, il fallimento più rilevante potrebbe riguardare un'azione non autorizzata anziché una risposta discutibile.

OWASP aveva già pubblicato una guida correlata nel gennaio 2025, quindi questa versione non introduce il red teaming AI da zero. Il manuale di ottobre fornisce un riferimento operativo più dettagliato. Per sviluppatori e acquirenti aziendali, la sua rilevanza consiste nel collegare le debolezze rilevate a evidenze riproducibili, conseguenze per l'azienda e correzioni verificate. Ne deriva un compromesso impegnativo: test più ampi producono garanzie più utili, ma richiedono accesso, coordinamento e tempo di sviluppo che una dimostrazione di chatbot non può offrire.

Cosa aggiunge il manuale OWASP sul red teaming GenAI

La pubblicazione offre ai team una struttura condivisa per gli incarichi, anziché un'altra raccolta isolata di prompt avversariali.

OWASP descrive un processo che comprende pianificazione, ricognizione, mappatura della superficie d'attacco, sfruttamento, persistenza, valutazione dell'impatto, reportistica e correzione. L'ambito dichiarato include modelli, applicazioni, agenti e interfacce multimodali, che accettano o producono formati come testo, immagini e audio. La pagina della risorsa sottolinea inoltre test etici, risultati misurabili e integrazione con le operazioni difensive.

Questa ampiezza conta perché un fallimento dell'AI raramente si presenta con una comoda etichetta organizzativa. Una risposta dannosa potrebbe avere origine nel comportamento del modello, nelle istruzioni dell'applicazione, nel materiale recuperato o in un servizio connesso. Componenti diversi sono controllati da team diversi. Un processo condiviso offre loro un modo per indagare sullo stesso evento senza presumere che la responsabilità termini al confine del proprio componente.

La distinzione storica è importante. La precedente guida sul red teaming di OWASP sosteneva già la valutazione delle vulnerabilità dei modelli insieme alle debolezze di integrazione e al monitoraggio continuo. La pubblicazione di ottobre rappresenta quindi un ulteriore sviluppo di questo approccio. Definirla il primo riconoscimento da parte di OWASP del rischio applicativo traviserebbe i fatti.

La nuova versione cambia anche ciò che i lettori dovrebbero aspettarsi dalla parola “testato”. Un'organizzazione può affermare correttamente di aver testato un modello lasciando però intatti i suoi connettori documentali. Un'altra può testare l'interfaccia dell'applicazione escludendo i servizi che eseguono azioni. Queste affermazioni descrivono coperture diverse, anche quando compaiono entrambe sotto la stessa voce di sicurezza.

Una struttura comune per gli incarichi aiuta a rendere visibili tali differenze. Incoraggia un acquirente a esaminare cosa ha coperto un test, quale accesso hanno ricevuto i tester e cosa è rimasto fuori ambito. Il valore analitico deriva da una maggiore specificità. Un nome noto di framework non può sostituire queste risposte.

Si consideri un assistente aziendale esemplificativo che legge file di progetto e redige comunicazioni per i clienti. Valutare la qualità della sua scrittura dice poco sul rispetto delle autorizzazioni dei file. Valutare l'accesso ai file dice poco sul fatto che una comunicazione successiva esponga materiale a un destinatario non autorizzato. Il prodotto combina questi comportamenti, quindi una valutazione deve spiegarne la relazione.

La pubblicazione del manuale non dimostra che le organizzazioni seguano già questo approccio. Fornisce un riferimento rispetto al quale è possibile esaminare le loro dichiarazioni. Adozione, qualità dell'implementazione e risultati di sicurezza restano questioni distinte.

Questa distinzione mantiene la pubblicazione nella giusta prospettiva. OWASP ha pubblicato indicazioni che supportano test più disciplinati. Che esse migliorino i prodotti implementati dipende da come i team traducono tali indicazioni in decisioni riguardanti accesso, prontezza al rilascio e correzione.

Gli acquirenti aziendali ereditano il rischio di integrazione

L'organizzazione che collega un modello AI ai sistemi aziendali rimane responsabile delle autorizzazioni e delle conseguenze di tale collegamento.

Un fornitore di modelli e uno sviluppatore di applicazioni rispondono a domande di sicurezza diverse. Il fornitore valuta il comportamento nell'ambiente di test a sua disposizione. Lo sviluppatore sceglie quali documenti, identità, servizi e azioni circondano il modello. L'implementazione aziendale aggiunge un ulteriore livello tramite configurazione, autorizzazioni degli account e dati specifici dell'organizzazione.

Questo crea un problema pratico di approvvigionamento. Gli acquirenti possono ricevere una documentazione estesa sul modello, pur apprendendo poco sul flusso di lavoro esatto che i dipendenti utilizzeranno. Una valutazione favorevole delle risposte generate non stabilisce se un assistente separi gli account dei clienti o limiti l'autorità di un connettore. Queste proprietà dipendono dall'applicazione implementata.

Le linee guida separate di OWASP sui test di sicurezza delle applicazioni rafforzano questa distinzione. Trattano modelli, recupero delle informazioni, strumenti e autorizzazioni come una superficie di test combinata. Identificano inoltre la prompt injection, ovvero istruzioni malevole incorporate negli input, come un potenziale problema di autorizzazione quando gli agenti possono usare strumenti connessi.

La pressione ricade quindi su diversi gruppi. I team di prodotto devono descrivere il comportamento consentito con precisione sufficiente per poterlo testare. I team di sicurezza necessitano dell'accesso alla configurazione implementata. I team di approvvigionamento necessitano di report che spieghino le esclusioni. I responsabili aziendali devono decidere quali rischi residui giustifichino il rinvio o la limitazione di una funzionalità.

Un assistente esemplificativo per il supporto clienti rende chiara la divisione. Il suo modello potrebbe rifiutare correttamente richieste di informazioni private in una conversazione diretta. L'applicazione circostante potrebbe comunque recuperare i record del cliente sbagliato. Il comportamento di rifiuto del modello e la separazione degli account nell'applicazione richiedono evidenze diverse.

Lo stesso problema si presenta nei sistemi di conoscenza interni. Un assistente potrebbe riassumere accuratamente un documento rendendo tuttavia quel riepilogo disponibile a qualcuno che non ha accesso all'originale. L'accuratezza migliora l'utilità, ma non risolve l'autorizzazione. Una risposta ben rifinita può nascondere l'errore di accesso sottostante.

Per i team che creano una base di conoscenza ricercabile, la domanda rilevante va oltre il reperimento delle informazioni corrette. Include anche la conservazione delle condizioni in base alle quali una persona può recuperarle e riutilizzarle. L'aggiunta dell'AI modifica l'interfaccia attraverso cui operano tali confini.

Questa analisi non implica che ogni implementazione richieda la medesima profondità di test. Uno strumento limitato alle informazioni pubbliche presenta conseguenze diverse rispetto a un agente autorizzato a modificare record aziendali. La decisione dovrebbe seguire l'effettiva autorità e l'esposizione dell'applicazione.

L'implicazione commerciale è più concreta di un generico appello a una maggiore sicurezza. I fornitori subiscono pressione affinché documentino i propri confini di integrazione. Gli acquirenti subiscono pressione affinché richiedano tale documentazione prima di concedere un accesso più ampio. Nessuna delle due parti può risolvere la questione basandosi soltanto su un benchmark del modello.

Gli agenti connessi trasformano le risposte in conseguenze

La sicurezza di un agente dipende da ciò che il software circostante consente a una decisione generata di fare.

Un agente AI è un software che usa l'output di un modello per selezionare ed eseguire azioni tramite strumenti connessi. Questo crea una transizione dalle conseguenze concrete. Un testo che altrimenti resterebbe un suggerimento può diventare una richiesta di inviare informazioni, modificare un record o richiamare un altro servizio.

Il manuale di 144 pagine collega le verifiche sui modelli con recupero delle informazioni, identità, autorizzazione e strumenti. I suoi contenuti affrontano anche la persistenza, in cui l'influenza di un attaccante sopravvive oltre un'interazione immediata. Questi temi estendono la valutazione dai singoli output al comportamento di un sistema connesso nel tempo.

L'esempio seguente è illustrativo e non un incidente riportato. Si immagini un assistente di ricerca che esamina un documento fornito dall'esterno. Il documento contiene istruzioni che chiedono all'assistente di divulgare materiale interno non correlato. Leggere il documento è legittimo. Trattare le sue istruzioni come autorizzazione per accedere e trasmettere altre informazioni oltrepassa un confine diverso.

Questa differenza spiega perché il solo filtraggio delle risposte fornisca un quadro incompleto. Una risposta finale potrebbe apparire innocua anche se l'assistente ha tentato in precedenza un'azione non autorizzata. Al contrario, una richiesta generata potrebbe sembrare pericolosa mentre il servizio connesso la blocca correttamente. Osservare l'azione e il suo risultato cambia la valutazione.

Ciò crea una distinzione utile tra comportamento tentato e danno effettivamente arrecato. Un valutatore dovrebbe evitare di trattare ogni frase sospetta come una compromissione riuscita. Allo stesso modo, una risposta finale pulita non dovrebbe cancellare l'evidenza che un servizio connesso abbia eseguito una richiesta inappropriata. Il comportamento effettivo del prodotto determina la conseguenza.

La persistenza aggiunge un'altra complicazione. Si supponga che l'assistente esemplificativo memorizzi una preferenza influenzata da un attaccante e la utilizzi in un'attività successiva. Una conversazione che sembra risolta potrebbe lasciare uno stato residuo che modifica il comportamento futuro. Valutare solo lo scambio originario non rileverebbe questa influenza continua.

Il sistema più ampio modifica anche il significato di una difesa riuscita. Se un modello segue un'istruzione malevola ma un controllo delle autorizzazioni blocca l'accesso, l'applicazione ha contenuto quell'azione tentata. Il risultato merita comunque un'indagine, ma differisce da una divulgazione effettiva. I report dovrebbero preservare questa distinzione.

Il compromesso diventa più netto man mano che i prodotti acquisiscono capacità utili. L'accesso in sola lettura supporta attività più circoscritte. L'autorizzazione a modificare record consente un'automazione più ampia, aumentando al contempo le conseguenze di un'istruzione errata. I test devono riflettere la capacità che rende il prodotto prezioso.

Ciò non dimostra che gli agenti siano intrinsecamente inadatti all'uso aziendale. Dimostra perché l'autorità meriti evidenze proprie. Il confronto rilevante è tra ciò che un agente può tentare, ciò che i servizi circostanti consentono e ciò che l'utente intendeva.

Il manuale OWASP sul red teaming GenAI rende esplicita questa prospettiva combinata. Il suo significato pratico consiste nel sottoporre il comportamento dell'applicazione allo stesso esame già riservato alle risposte del modello.

Un metodo condiviso affronta un problema di evidenze

Una valutazione strutturata migliora la qualità delle domande, ma le sue conclusioni restano limitate dai test, dall'ambiente e dalle evidenze che le sostengono.

Il supporto dei contributori aiuta a spiegare perché una metodologia comune possa risultare interessante per i professionisti. L’account del contributore di NeuralTrust, datato 1 luglio 2026, descrive la partecipazione a una versione sottoposta a consultazione pubblica. L’azienda presenta gli incarichi ripetibili come un miglioramento rispetto a tecniche di attacco scollegate tra loro. È la prospettiva di un partecipante, non una prova indipendente di una riduzione degli incidenti.

Anche la cronologia merita attenzione. NeuralTrust ha discusso un manuale in consultazione pubblica prima della pubblicazione della pagina delle risorse di OWASP a ottobre. I lettori dovrebbero distinguere l’attività preliminare sulle bozze dalla data associata all’attuale release ufficiale. Nessuna delle due date stabilisce quando una determinata organizzazione abbia adottato la metodologia.

La domanda scettica riguarda l’implementazione. Un report può usare intestazioni coerenti pur documentando esperimenti deboli. Una valutazione lunga può omettere lo strumento più rilevante. Un ambiente di test può assomigliare visivamente alla produzione pur usando autorizzazioni diverse. Una struttura formale rende questi limiti più facili da descrivere, ma non li elimina automaticamente.

C’è anche una sfida di misurazione. Il risultato di un test dipende da ciò che viene considerato successo o fallimento. Un assistente che menziona informazioni riservate è diverso dal recuperarle, mostrarle o trasmetterle all’esterno. Riunire questi eventi sotto una vaga etichetta di “fuga di dati” rende il risultato difficile da interpretare.

I confronti tra prodotti affrontano lo stesso problema. Un sistema con ampie autorizzazioni può esporre percorsi di fallimento più gravi rispetto a un assistente sottoposto a restrizioni rigorose. Un conteggio grezzo degli attacchi riusciti non spiega se i prodotti abbiano affrontato compiti, accessi o condizioni comparabili. L’ambito deve accompagnare il risultato.

I test automatizzati introducono un’ulteriore fonte di incertezza. Un modello usato per giudicare il comportamento di un altro modello può fraintendere il compito o classificare erroneamente un esito. Questo non rende inutile la valutazione automatizzata. Significa che il processo di giudizio richiede scrutinio, soprattutto quando i risultati influenzano le decisioni di rilascio.

Anche qui conta la distinzione tra sicurezza e utilità. Un assistente che rifiuta ogni richiesta può sembrare resistente agli abusi, pur non svolgendo il compito per cui è stato progettato. Una valutazione significativa deve preservare l’esecuzione di compiti legittimi insieme ai confini che dovrebbe far rispettare. Altrimenti, un miglioramento apparente può nascondere funzionalità perse.

Si tratta di limiti analitici, non di prove che il manuale fallisca. Nessuna metodologia può trasformare un esercizio circoscritto in una prova relativa a ogni futura interazione. La conclusione difendibile identifica le condizioni testate, gli esiti osservati e l’incertezza residua.

La pubblicazione dovrebbe quindi alzare le aspettative in materia di prove senza incoraggiare rassicurazioni generiche. “Valutato usando le linee guida OWASP” descrive un approccio. Gli acquirenti devono comunque comprendere cosa sia accaduto durante la valutazione e quali risultati abbiano ricevuto correzioni verificate.

I budget per i test devono coprire l’intero flusso di lavoro

La parte più impegnativa dei test AI più ampi è coordinare le persone e i sistemi che controllano il flusso di lavoro.

Un esercizio focalizzato sui prompt può spesso iniziare con l’accesso a un’interfaccia conversazionale. Una valutazione del flusso di lavoro richiede più contesto. I tester devono comprendere il compito previsto dell’applicazione, le informazioni a cui può accedere e gli effetti che i suoi strumenti possono produrre. Ottenere questa comprensione richiede impegno organizzativo prima ancora che inizi un attacco.

Questo costo fa parte del compromesso di sicurezza. Un ambito più ampio supporta conclusioni che rispecchiano meglio un prodotto distribuito. Un ambito più ristretto riduce il lavoro necessario, ma limita ciò che il report risultante può dimostrare. Nessuna delle due scelte dovrebbe scomparire dietro un’affermazione generica secondo cui i test sono completi.

La differenza influisce anche sulla correzione. Se una debolezza deriva da un account di servizio con autorizzazioni troppo ampie, modificare le istruzioni del modello potrebbe lasciare intatta l’autorità sottostante. Se il problema riguarda un accesso legittimo usato per uno scopo non previsto, rimuovere ogni accesso potrebbe impedire al prodotto di svolgere il suo compito. L’ingegneria necessita di una diagnosi sufficientemente specifica da supportare una correzione utile.

La proprietà può diventare l’ostacolo centrale. Un team del modello controlla la configurazione, un team applicativo controlla l’orchestrazione e un team dell’identità controlla le autorizzazioni. Un’unità aziendale possiede il flusso di lavoro interessato. Un rilievo che attraversa questi confini richiede una decisione su chi debba modificare cosa.

Un assistente documentale esemplificativo mostra come ciò avvenga. Il prodotto recupera file interni e prepara un riepilogo esterno. Un test scopre che contenuti riservati entrano nella bozza. L’azione correttiva potrebbe riguardare le autorizzazioni di recupero, i controlli sui destinatari, la classificazione dei documenti o la fase di approvazione del flusso di lavoro. Questi rimedi affrontano cause diverse.

Un esito utile spiegherebbe quale confine abbia fallito e se il rimedio selezionato abbia bloccato il percorso osservato. Limitarsi ad aggiungere formulazioni più severe alle istruzioni dell’assistente fornirebbe prove più deboli, a meno che il fallimento sottostante non riguardasse la gestione delle istruzioni. La riparazione dovrebbe seguire il meccanismo dimostrato.

Gli strumenti disponibili supportano parti diverse di questo lavoro. Le linee guida OWASP per i test delle applicazioni elencano garak di NVIDIA per la scansione delle vulnerabilità dei modelli e PyRIT di Microsoft per l’orchestrazione delle interazioni avversarie. Questi strumenti supportano attività di test, mentre una metodologia di incarico organizza ambito, interpretazione e attività successive. I loro ruoli si sovrappongono senza essere intercambiabili.

I confronti tra strumenti dovrebbero quindi concentrarsi sulla copertura piuttosto che sulla preferenza di marca. Uno scanner che genera input vari non può stabilire automaticamente se un record aziendale sia stato modificato in modo appropriato. Un framework di orchestrazione non può decidere i confini di autorità accettabili per un’organizzazione senza un compito e una policy definiti.

L’enfasi del manuale sulla riproducibilità e sull’integrazione difensiva punta a un esito operativo: risultati che i team di ingegneria e sicurezza possano usare. Il valore aziendale dipende da questo passaggio di consegne. Scoprire una risposta insolita è meno utile quando nessuno può riprodurne le conseguenze o verificare la correzione.

Osservare le prove di adozione fino a gennaio

Il segnale più forte sarà una prova pubblica che le organizzazioni abbiano modificato l’ambito delle valutazioni e verificato le correzioni dopo aver usato il manuale.

Il primo segnale da osservare è la qualità dei casi di studio pubblicati. Fino a gennaio 2027, resoconti utili descriverebbero l’applicazione testata, le sue capacità connesse e i confini esclusi dalla valutazione. Un annuncio di approvazione o download dimostra interesse. Un incarico documentato rivela come la metodologia funzioni sotto vincoli reali.

Tali resoconti rafforzerebbero il caso a favore del manuale se collegassero una debolezza scoperta a una specifica modifica correttiva. Indebolirebbero affermazioni più ampie se riportassero solo risposte insolite del modello lasciando inesplorate le conseguenze applicative. La distinzione segue l’ambito dichiarato della release.

Il segnale successivo riguarda il modo in cui i fornitori descrivono la copertura nelle loro offerte di valutazione. L’iniziativa di red teaming di OWASP presenta già il manuale insieme a risorse per la valutazione e la selezione dei fornitori. Ciò crea un punto di riferimento per esaminare cosa includa un servizio. Gli acquirenti dovrebbero cercare descrizioni più chiare degli strumenti, dell’accesso ai dati e del comportamento degli agenti coperti.

Una rendicontazione più specifica sosterrebbe l’idea che linee guida condivise migliorino la comparabilità. Affermazioni generiche di allineamento a OWASP senza un ambito documentato offrirebbero prove più deboli. Il cambiamento significativo apparirebbe nei deliverable e nelle aspettative contrattuali, anziché in un nuovo badge sulla pagina di un fornitore.

Il segnale finale è ciò che avviene dopo la correzione. Risultati di follow-up pubblicati mostrerebbero se un’organizzazione abbia ritestato il fallimento originario ed esaminato percorsi correlati. Un resoconto che si fermi alla scoperta lascia senza risposta la domanda operativa centrale: il prodotto è diventato più sicuro mantenendo la sua funzione prevista?

Questi sono criteri di osservazione, non impegni annunciati da OWASP o dai fornitori partecipanti. Non esistono ancora dati verificati sull’adozione o misurazioni della riduzione degli incidenti che stabiliscano l’impatto del manuale. La release fornisce un quadro per indagare tale impatto, mentre devono ancora seguire prove di implementazione.

Per gli sviluppatori, l’implicazione immediata è collegare i risultati dei test alla configurazione effettivamente usata dai clienti. Per gli acquirenti enterprise, è distinguere le garanzie sul modello dalle prove relative alla distribuzione. Per gli utenti, la preoccupazione pratica resta se un assistente rispetti i confini relativi alle loro informazioni e azioni.

Leggete il manuale OWASP sul red teaming GenAI insieme alle prove di valutazione dei sistemi AI che la vostra organizzazione distribuisce effettivamente. Chiedete al proprietario del prodotto di spiegare quali flussi di lavoro siano stati testati e quali autorizzazioni siano rimaste fuori ambito. Verificate se il report distingua tra azioni tentate ed effetti completati. Controllate se l’ingegneria abbia verificato le correzioni rispetto al fallimento originario. Queste domande mantengono la discussione legata a comportamenti osservabili anziché a un’etichetta di framework. Rivelano inoltre dove un riepilogo sicuro di sé poggi su un esperimento ristretto. Prima di concedere a un assistente un accesso più ampio, richiedete prove che coprano l’autorità aggiunta. L’ultima valutazione descrive il prodotto usato dai dipendenti, o soltanto il modello sottostante?