Come si struttura un LLM Red Teaming: metodo, test e assessment

Quando il test deve dimostrare qualcosa

Nel primo approfondimento abbiamo visto perché un LLM Red Teaming non coincide con un penetration test tradizionale.
Qui viene la parte più interessante: capire come trasformare il testing avversariale in qualcosa che abbia un valore reale per la sicurezza.

Far produrre a un modello una risposta assurda può essere divertente. Convincerlo a ignorare un’istruzione può essere tecnicamente interessante. Ma il punto cambia completamente quando quella manipolazione permette di raggiungere dati, utilizzare un tool, superare un confine tra utenti o produrre un’azione che il sistema non avrebbe dovuto consentire. È in quel momento che si smette di giocare con il chatbot e si comincia a testare davvero il sistema.

Strutturare un LLM Red Teaming significa comprendere l’architettura nella quale opera il modello, individuare ciò che deve essere protetto e costruire scenari capaci di mettere in discussione le assunzioni di sicurezza del sistema.

Il test non riguarda soltanto l’LLM. Riguarda anche system prompt, RAG, dati, API, tool, agenti, identità e autorizzazioni. Il risultato utile non è una collezione di jailbreak riusciti, ma la capacità di dimostrare che cosa può essere manipolato, quanto è realistico sfruttarlo, fin dove può arrivare l’attacco e quale controllo può interrompere quella catena.

Prima di attaccare bisogna capire cosa abbiamo davanti

La tentazione è partire immediatamente dai prompt. È anche il modo migliore per ottenere risultati senza sapere bene che cosa significhino. Un’applicazione basata su LLM raramente coincide con il solo modello. Dietro possono esserci un motore RAG, documenti aziendali, un vector database, API, sistemi di autenticazione, strumenti esterni e magari agenti autorizzati a compiere azioni. Prima di testare bisogna quindi capire come questi elementi comunicano tra loro e soprattutto quali capacità vengono trasferite al modello.

Un LLM isolato che viene convinto a ignorare una regola può produrre una risposta indesiderata. Lo stesso modello collegato a una casella email, a un CRM e a un filesystem aziendale può produrre conseguenze decisamente meno teoriche.

La prima domanda diventa quindi molto semplice: che cosa può realmente raggiungere questo sistema? La seconda arriva subito dopo: con quale autorità può farlo?

Il vero bersaglio sono spesso le assunzioni di sicurezza

Ogni architettura contiene assunzioni. Alcune sono esplicite, altre vengono date per scontate durante la progettazione. Possiamo presumere, per esempio, che un documento recuperato dal RAG contenga informazioni e non istruzioni capaci di modificare il comportamento del modello. Possiamo presumere che un utente non riesca a far emergere dati appartenenti a un altro contesto. Oppure che un agente utilizzi un determinato tool soltanto quando l’intenzione dell’utente è coerente con lo scopo previsto.

Il lavoro avversariale comincia proprio quando si prende una di queste convinzioni e la si mette sotto pressione.

La domanda non è soltanto “quale vulnerabilità conosco e posso provare?”. È piuttosto: quale cosa stiamo considerando sicura e cosa succede se smette di esserlo?

Molti finding interessanti nascono così. Non da un attacco particolarmente esotico, ma da una fiducia concessa nel posto sbagliato.

Uno scenario di test deve avere una storia

Immaginiamo un agente AI utilizzato per elaborare documenti ricevuti dall’esterno. Il sistema legge il contenuto, recupera eventualmente altre informazioni e dispone di una funzione aziendale che può utilizzare quando necessario.

Dentro uno dei documenti compare un’istruzione malevola.

A questo punto non interessa soltanto sapere se l’LLM la interpreta. Bisogna osservare che cosa succede dopo. Il modello la considera autorevole? Cerca di utilizzare uno strumento? Quel tool possiede privilegi? Esiste una conferma umana prima dell’azione? Il comportamento viene registrato?

La prompt injection, da sola, potrebbe non essere nemmeno il finding più importante.

Il problema vero potrebbe essere che un contenuto non fidato è riuscito a influenzare una decisione alla quale il sistema aveva associato un privilegio reale.

Quando un test riesce a ricostruire questa sequenza, comincia a produrre informazioni utili anche per chi dovrà correggere l’architettura.

Con gli agenti AI il rischio cambia natura

Finché un modello produce soltanto testo, buona parte delle conseguenze rimane confinata all’output. Con gli agenti il quadro cambia, perché l’AI può utilizzare strumenti e concatenare operazioni.

Può leggere informazioni, interrogare un database, utilizzare un servizio esterno, scrivere in un CRM o eseguire altre azioni previste dall’applicazione. A quel punto diventa fondamentale distinguere tra la capacità del modello di suggerire qualcosa e l’autorità che il sistema gli concede per farlo davvero.

Se riesco a manipolare l’LLM, la domanda più importante diventa quindi: quale potere eredito indirettamente dai tool e dalle credenziali che gli sono state assegnate?

È uno dei motivi per cui il principio del minimo privilegio rimane valido anche quando al posto di un utente umano abbiamo un agente. Un modello non dovrebbe poter utilizzare più dati, più strumenti o più autorizzazioni di quelli strettamente necessari.

Altrimenti il problema non è che l’AI abbia avuto una cattiva idea. È che qualcuno le ha anche consegnato le chiavi.

RAG: quando un dato rischia di diventare un’istruzione

Il RAG rende i modelli molto più utili perché permette loro di lavorare su informazioni che non fanno parte della conoscenza originaria. Ma introduce anche nuove fonti di fiducia.

Una pagina web, un documento, un ticket o una mail dovrebbero rappresentare contenuti da elaborare. Se però il modello interpreta parte di quel contenuto come un’istruzione, il confine tra dato e comando comincia a diventare pericolosamente sottile.

Il testing deve quindi osservare non soltanto quali informazioni vengono recuperate, ma anche da dove provengono, chi può modificarle, come vengono separate tra utenti e quanto possono influenzare il comportamento del sistema.

È lo stesso tipo di problema che emerge negli attacchi che manipolano gerarchie e istruzioni, come quelli affrontati nell’analisi sulla Policy Puppetry.

Il principio da difendere è semplice: un’informazione non dovrebbe trasformarsi silenziosamente in un ordine.

Una risposta strana non è ancora una vulnerabilità

Questa è una distinzione fondamentale, perché con gli LLM i comportamenti inattesi non sono esattamente una rarità.

Prima di classificare qualcosa come vulnerabilità bisogna capire quanto sia ripetibile, quali condizioni siano necessarie per sfruttarla e soprattutto dove possa portare. Un modello che ignora una regola in un ambiente isolato può avere un impatto minimo. Lo stesso comportamento assume un significato completamente diverso se consente di raggiungere dati, tool o privilegi che avrebbero dovuto restare fuori portata.

È qui che entrano in gioco exploitability e impatto reale.

Non interessa soltanto sapere che una manipolazione è possibile. Serve capire quanto sia realistico riprodurla, quale vantaggio possa ottenere un attaccante e quali conseguenze produca sul sistema.

È la differenza tra dire “sono riuscita a far ignorare un’istruzione al modello” e dire “attraverso quella manipolazione posso indurre un agente a utilizzare un tool con privilegi che l’utente non possiede”.

Sembrano risultati simili. Non lo sono affatto.

Le catene di attacco contano più del singolo errore

Nei sistemi complessi il rischio emerge spesso dalla concatenazione di più debolezze, una indirect prompt injection può essere poco significativa da sola. Ma immaginiamo che il modello la interpreti, possa selezionare autonomamente un tool, utilizzi credenziali troppo permissive e non richieda alcuna conferma prima dell’azione.

Abbiamo appena costruito una catena: contenuto ostile → modello manipolato → tool selezionato → privilegio utilizzato → conseguenza sul sistema.

È questo tipo di percorso che il Red Teaming dovrebbe cercare.

Non soltanto “dove riesco a entrare?”, ma “una volta entrata, fin dove posso arrivare?”

La seconda risposta è spesso quella che determina la vera priorità del finding.

Documentare un comportamento probabilistico

Con gli LLM compare poi un problema che nella sicurezza tradizionale non sempre pesa allo stesso modo: lo stesso input può non produrre sempre esattamente lo stesso risultato. Per questo “a me una volta ha funzionato” non è una gran metodologia.

Un finding importante deve poter essere ricostruito. Bisogna conoscere il prompt, il contesto, la versione del modello, gli eventuali documenti recuperati, i tool disponibili e le condizioni nelle quali il comportamento si presenta, se e quando nel caso, un’anomalia compare una volta su cento abbiamo un’informazione. Se compare novanta volte su cento ne abbiamo un’altra. Il punto non è pretendere che un sistema probabilistico diventi improvvisamente deterministico, ma bisogna raccogliere abbastanza evidenza da poter distinguere un episodio curioso da una debolezza riproducibile.

Mitigare significa spezzare la catena, non nascondere il prompt

Una volta individuato il problema arriva la parte meno spettacolare e più importante: correggerlo. La soluzione peggiore è spesso bloccare esattamente la stringa che ha fatto riuscire il test. Il prompt smette di funzionare e tutti sono contenti per circa venti minuti.

La domanda corretta è invece: quale meccanismo ha reso possibile l’attacco?

A volte la correzione riguarda il modello o il system prompt. In altri casi il problema è nei privilegi concessi a un tool, nell’assenza di separazione tra dati e istruzioni, nella mancata validazione degli output o nell’autonomia eccessiva dell’agente. Una buona mitigazione può persino lasciare il modello ancora manipolabile, ma fare in modo che quella manipolazione non possa più trasformarsi in un danno concreto, dal punto di vista della sicurezza è un risultato molto più interessante.

Il retest è il momento della verità

La frase “abbiamo corretto” non chiude un finding, chiude il test, perchè dopo la mitigazione bisogna ripetere lo scenario originale e provare anche alcune varianti, perché una correzione costruita soltanto sul percorso già conosciuto può lasciare intatta la debolezza sottostante.

Il retest serve proprio a capire se abbiamo rimosso il problema oppure se lo abbiamo semplicemente spostato un po’ più in là, magari dietro una porta con un cartello nuovo.

Framework e tassonomie servono, ma non pensano al posto nostro

Riferimenti come OWASP GenAI Security Project, MITRE ATLAS e le pubblicazioni del NIST sono importanti perché permettono di organizzare il testing e di non dimenticare intere classi di rischio. Sono mappe.

Ma una mappa non conosce l’applicazione che abbiamo davanti, non sa quale dato abbia valore per quell’organizzazione e non conosce l’API che qualcuno ha collegato venerdì sera perché “serviva urgentemente”. Le tassonomie aiutano a stabilire dove guardare.

L’assessment deve ancora capire che cosa stiamo realmente vedendo.

Dal test alla decisione

Alla fine di un LLM Red Teaming le domande importanti sono sorprendentemente poche.

Il comportamento osservato è realmente sfruttabile? Quanto è realistico riprodurlo? Quale asset permette di raggiungere? Che conseguenza può produrre? Quale controllo interrompe la catena e abbiamo verificato che quel controllo funzioni?

È in questo passaggio che il testing avversariale smette di essere una dimostrazione tecnica e diventa uno strumento per prendere decisioni.

Perché convincere un’AI a fare una sciocchezza, tutto sommato, non è così difficile.

Capire se quella sciocchezza può diventare un incidente è tutto un altro mestiere.

Il quadro generale delle superfici di rischio è raccolto nella pagina AI Security e LLM Red Teaming.

La differenza tra questo tipo di testing e il penetration testing tradizionale è invece approfondita in LLM Red Teaming: cos’è, cosa testa e perché un penetration test non basta.

 

Ringrazio sempre il grande supporto dell’AI, per aver correlato testi a link, e per avermi dato delle ottime dritte in campo lavorativo!