Misure

Red-teaming e vulnerability assessment per i sistemi di IA

6 min di lettura Aggiornato: 18/03/2026

Il red-teaming dedicato ai sistemi di intelligenza artificiale è l’attività che mette alla prova, in modo controllato, la resilienza di un modello linguistico e dei suoi componenti operativi. Il perimetro comprende il modello, i prompt di sistema, le pipeline RAG e gli agenti che dispongono di strumenti o permessi.

Per pipeline RAG si intende la catena di componenti che, prima della risposta del modello, recupera informazioni da un archivio di documenti e le inserisce nel contesto. Tipicamente include ingestione e segmentazione dei documenti (chunking), creazione di embedding e indicizzazione, retrieval e reranking dei risultati, costruzione del prompt con le fonti e controlli come filtri, citazioni, logging e monitoraggio.

Red-teaming dell'IA

Nel red-teaming classico l’obiettivo è spesso la violazione di un perimetro logico o fisico, in quello IA si cerca di indurre il sistema a comportarsi in modo deviante rispetto alle proprie policy o istruzioni di sicurezza. La differenza principale risiede nel fatto che l’oggetto dell’attacco non è un codice, ma una funzione di interpretazione linguistica: il red-teamer non cerca una falla di sistema, ma una formulazione linguistica o contestuale che possa manipolare la generazione del modello.

La fase di scoping assume quindi un valore conoscitivo prima che operativo. Definire gli asset da testare, cioè il modello, le versioni, i prompt di sistema, le sorgenti RAG, i privilegi concessi agli agenti significa conoscere quali istruzioni il modello considera vincolanti, da dove ricava conoscenza, che cosa può fare in autonomia, quali azioni richiedono approvazione umana, come e quando deve intervenire il monitoraggio umano.

Le regole d’ingaggio includono safe-words semantiche (parole o temi che segnalano il superamento di una soglia di rischio), limiti temporali di esecuzione e ambienti isolati (sandbox) che permettono la simulazione di abusi senza conseguenze operative. Ad esempio, si può manipolare un agente IA affinché utilizzi strumenti esterni in modo non previsto (come indurlo a inviare query a endpoint esterni che esfiltrano dati), oppure si possono iniettare istruzioni malevole nella memoria persistente dell’agente per influenzare decisioni future.

La superficie di attacco è, conseguentemente, semantica. Un modello può essere indotto a rivelare parti del system prompt, a ignorare restrizioni o a usare strumenti integrati in modi non previsti. Allo stesso modo, una pipeline RAG può essere influenzata inserendo documenti contaminati nelle fonti, mentre gli agenti possono essere spinti a sequenze di azioni fuori policy o a consumi eccessivi di risorse.

Tassonomia degli attacchi

Le tecniche impiegate nel red-teaming IA possono essere raggruppate in tre categorie principali:

  • La prompt injection, che può essere diretta o indiretta e include i jailbreak, le tecniche di obfuscation e i tentativi di far emergere il system prompt.
  • Gli attacchi alle pipeline RAG, dove l’obiettivo è influenzare il contenuto recuperato o saturare il contesto per ridurre l’affidabilità delle risposte.
  • Gli agenti dotati di strumenti, che possono essere manipolati per eseguire operazioni non autorizzate, superare i limiti dimensionali previsti o consumare risorse in modo anomalo.
Per strutturare il lavoro si possono utilizzare alcuni riferimenti consolidati. L’OWASP LLM Top 10 fornisce una tassonomia di rischi che aiuta a verificare che la campagna copra le principali categorie di vulnerabilità, oltre a una guida specifica per i test da effettuare sui sistemi AI. MITRE ATLAS offre, invece, una mappa di tattiche e tecniche che permette di collegare ogni attacco a un modello operativo più ampio. Nei sistemi agentici è altrettanto utile definire una policy di agency, chiarendo quali azioni l’agente può svolgere autonomamente e quali richiedono l’intervento umano. Queste policy diventano un elemento centrale del test.

Progettazione delle campagne

Le campagne manuali si basano su librerie di pattern linguistici, che includono varianti di role-play, obfuscation, suffix injection, multilingua o multi-turno, ciascuna pensata per testare la capacità del modello di mantenere coerenza e aderenza alle policy di sicurezza.

Dall’altro lato, le campagne automatiche impiegano mutatori semantici, cioè algoritmi che producono variazioni di un prompt per esplorare lo spazio linguistico circostante a un attacco noto. Il principio è analogo al fuzzing del software, ma a livello “concettuale”: si genera rumore semantico per osservare come la probabilità di risposta del modello cambi al variare delle formulazioni. In contesti RAG si possono, ad esempio, inserire documenti contaminati nel corpus di retrieval per verificare se il modello li assimila e li cita, mentre per gli agenti si simulano scenari di privilege escalation, inducendoli a usare strumenti al di fuori della policy dichiarata.

Quando sono coinvolti agenti autonomi, le campagne di attacco si concentrano sull’escalation di privilegi, sull’uso di catene di strumenti per finalità non autorizzate e sulla simulazione di obiettivi ingannevoli. In questi casi, l’attaccante può cercare di indurre l’agente a violare le policy interne, a generare cicli infiniti o sprechi di token (token wasting), oppure a eseguire azioni di denial-of-service (DoS) logico che saturano le sue risorse.

L’ambiente di prova deve essere progettato per la riproducibilità. Tale condizione è complessa poiché le risposte di un modello linguistico non sono deterministiche. Serve dunque un reset controllato che includa seed del modello, versione, stato dell’indice RAG e parametri di generazione, così da poter replicare il comportamento osservato. Per questo, nella sandbox ogni famiglia d’attacco deve poter produrre un flag verificabile, cioè una prova tangibile che il sistema ha violato una regola o rivelato un’informazione sensibile in modo da poter misurare i test svolti.

Nel red-teaming tradizionale, il successo è binario (violato o non violato), nell’IA, la valutazione dei risultati si fonda su metriche quantitative e qualitative. Il tasso di successo per categoria di attacco, il tempo necessario per ottenere una compromissione (time-to-compromise), il numero di iterazioni richieste, il leakage rate del system prompt e, nei contesti RAG, la groundedness, ossia il grado di coerenza con le fonti previste. Per gli agenti, la metrica chiave è il rapporto tra azioni bloccate e azioni eseguite nonostante le policy di sicurezza.

Gestione dei risultati e rafforzamento continuo

L’hardening in ambito IA non consiste in patch di codice o modifiche infrastrutturali, ma in interventi sul linguaggio e sul contesto. Una volta identificati i comportamenti indesiderati, è necessario tradurli in un processo di hardening che combina elementi linguistici, procedurali e organizzativi. Il ciclo operativo si articola in una sequenza reiterativa di attacco, correzione, regressione automatizzata, aggiornamento delle policy e nuova campagna di test.

Ogni vulnerabilità individuata genera un Red Team Brief, documento che riporta lo scenario, la catena di compromissione, la prova riproducibile, l’impatto operativo e il fix proposto, accompagnato da un test di regressione associato. In tal modo si costruisce una base di conoscenza verificabile che consente di tracciare l’efficacia delle correzioni e di ridurre la probabilità di ricadute.

L’adozione di indicatori di performance come il tempo medio di mitigazione delle vulnerabilità (Mean Time To Remediate), la percentuale di regressioni superate e il monitoraggio del drift comportamentale tra versioni successive del modello consente di quantificare la resilienza del sistema nel tempo.

Automazione

Alcuni strumenti di AI (ad esempio, Petri ) stanno iniziando a strutturare lo svolgimento e l'automatizzazione del processo di red-teaming, ad esempio generando varianti di prompt malevoli, simulando attacchi di injection o eseguendo fuzzing semantico su larga scala. Tuttavia, è fondamentale affiancare a tali strumenti il giudizio umano, capace di contestualizzare e valutare, ad esempio, una correlazione anomala, un pattern imperfetto o un comportamento ambiguo che merita attenzione.