LLM Red Teaming: cos’è, cosa testa e perché un penetration test non basta

LLM Red Teaming: mettere alla prova l’AI prima dell’attaccante

Un Large Language Model può funzionare perfettamente durante i test funzionali e rimanere comunque vulnerabile, può rispondere correttamente alle domande previste, rispettare apparentemente le istruzioni e superare i normali controlli applicativi, ma comportarsi in modo completamente diverso quando riceve input costruiti intenzionalmente per manipolarlo.

È qui che entra in gioco il LLM Red Teaming.

Il suo obiettivo non è verificare semplicemente se un chatbot “funziona”. Serve a comprendere come può fallire quando qualcuno smette di utilizzarlo nel modo previsto.

Prompt injection, jailbreak, data leakage, poisoning, backdoor, RAG manipolati, tool abuse e agenti con privilegi eccessivi introducono una superficie di attacco che non può essere valutata soltanto con i metodi tradizionali di sicurezza applicativa.

LLM Red Teaming, non sono i nuovi cartoon

LLM Red Teaming è un’attività strutturata di testing avversariale applicata a Large Language Model, applicazioni di AI generativa e sistemi agentici. Ha l’obiettivo di individuare vulnerabilità, comportamenti inattesi e possibilità di abuso verificando non soltanto il modello, ma anche prompt, dati, RAG, API, tool, autorizzazioni, agenti e sistemi collegati.

Un penetration test tradizionale non viene sostituito dal Red Teaming AI: i due approcci coprono superfici differenti e possono essere complementari. Il pentest ricerca vulnerabilità sfruttabili nell’infrastruttura e nell’applicazione; il LLM Red Teaming verifica anche come linguaggio, contesto, istruzioni e autonomia del modello possano essere manipolati fino a produrre conseguenze tecniche o operative.

Che cos’è il LLM Red Teaming

Il termine Red Teaming nasce dalla sicurezza tradizionale: un gruppo assume il punto di vista dell’avversario e tenta di individuare debolezze che i normali controlli potrebbero non evidenziare.

Con l’intelligenza artificiale il concetto si amplia.

Il NIST definisce l’AI Red Teaming come uno sforzo strutturato di testing finalizzato a individuare difetti e vulnerabilità nei sistemi di intelligenza artificiale, generalmente attraverso metodi avversariali e in ambiente controllato.

Nel caso degli LLM il bersaglio non è soltanto il software.

Occorre considerare:

• il modello;
• il system prompt;
• le istruzioni dell’utente;
• i dati utilizzati come contesto;
• RAG e vector database;
• API e servizi esterni;
• plugin e tool;
• identità e autorizzazioni;
• agenti AI;
• modelli e componenti di terze parti;
• pipeline di sviluppo e deployment.

L’OWASP GenAI Red Teaming Guide struttura infatti il problema considerando quattro aree: valutazione del modello, testing dell’implementazione, assessment dell’infrastruttura e analisi del comportamento runtime.

È questa estensione del perimetro a distinguere il Red Teaming AI da un semplice test del chatbot.

Perché un penetration test non basta

Un penetration test tradizionale rimane fondamentale, sempre ed in ogni caso, ci mancherebbe altro perchè individua vulnerabilità nell’applicazione, nelle API, nelle configurazioni, nelle identità, nell’infrastruttura o nei controlli di accesso.

Ma un sistema AI introduce anche una componente che interpreta linguaggio e contesto,  è proprio questa capacità a creare nuove classi di rischio, e far si che si possano comprendere velocemente!

Un endpoint può essere perfettamente protetto dal punto di vista tradizionale e consentire comunque al modello di elaborare istruzioni malevole contenute in un documento,  un’API può applicare correttamente autenticazione e cifratura mentre l’agente AI che la utilizza dispone di privilegi superiori a quelli necessari.

Un database può essere tecnicamente sicuro e contemporaneamente fornire al sistema RAG contenuti manipolati che alterano il comportamento del modello, un penetration test e un LLM Red Teaming rispondono quindi a domande differenti, mi pare una logica lampante!

Il pentest domanda: “Posso compromettere tecnicamente questo sistema?”

Il Red Teaming AI aggiunge: “Posso manipolare il comportamento dell’AI affinché il sistema faccia qualcosa che non avrebbe dovuto fare?”

Le due domande possono convergere nello stesso incidente, e fare in modo che tutta la problematica sia più comprensibile.

Prompt injection: quando l’istruzione diventa superficie di attacco

La prompt injection è uno dei problemi più caratteristici dei sistemi basati su LLM. Il modello riceve istruzioni provenienti da fonti differenti e deve stabilire implicitamente quali abbiano maggiore autorità. L’attacco può essere diretto, ovvero quando l’utente cerca deliberatamente di modificare il comportamento del sistema attraverso il prompt.

Può essere anche indiretto, e quindi più subdolo. In questo caso l’istruzione malevola può trovarsi in una qualsiasi pagina web, in un  documento, come in una email, dentro ad un repository; oppure in un record recuperato dal RAG, ed infine molto subdolo, in un contenuto elaborato automaticamente dall’agente.
L’utente potrebbe quindi non aver inviato direttamente alcuna istruzione pericolosa, ma è ovviamente recuperata dal sistema stesso, in modo autonomo, dando modo a gli  agenti AI accesso ad email, file, browser, repository e servizi esterni, questo problema diventa particolarmente importante, ed impattante! Nel marzo 2026 anche il NIST ha evidenziato il rischio di agent hijacking tramite indirect prompt injection nell’analisi di una competizione di red teaming su larga scala.

Jailbreak e aggiramento delle restrizioni

Il jailbreak cerca di indurre il modello a superare vincoli e meccanismi di sicurezza, ma non tutti i jailbreak hanno la stessa rilevanza.

Ottenere una risposta insolita da un chatbot sperimentale può avere impatto minimo, ma è palese che un comportamento non autorizzato da un sistema collegato a informazioni riservate, strumenti o processi aziendali può invece produrre conseguenze molto più serie, se non addirittura catastrofiche. Per questo motivo chi opera come  Red Teaming non considera sufficiente classificare un test come “riuscito”.

Occorre valutare in modo certo, che cosa è stato realmente superato; quali capacità sono diventate disponibili; quali asset possono essere raggiunti e quali conseguenza può derivarne. La vulnerabilità acquista significato soltanto nel contesto dell’architettura nella quale il modello opera.

RAG: quando anche la conoscenza può essere manipolata

Il Retrieval-Augmented Generation consente al modello di utilizzare informazioni esterne alla propria conoscenza originaria, è una capacità estremamente utile, ma introduce altre relazioni da proteggere.

Un sistema RAG deve poter stabilire:

• quali fonti può interrogare;
• quali documenti appartengono a ciascun utente;
• quali informazioni possono essere recuperate;
• come vengono indicizzati i contenuti;
• quanto una fonte può influenzare la risposta;
• se un contenuto recuperato contiene istruzioni ostili.

Il Red Teaming deve quindi verificare non soltanto la qualità della risposta, ma anche isolamento dei dati, autorizzazioni, provenienza del contenuto e possibilità di manipolazione del retrieval. Un modello perfettamente allineato non può compensare automaticamente un contesto contaminato.

Agenti AI: quando il modello può agire

Il rischio aumenta ulteriormente quando l’LLM non produce soltanto testo, un agente può utilizzare strumenti, scegliere azioni, interrogare sistemi e concatenare più operazioni. Può, per esempio, avere accesso a: email, CRM, repository, database, filesystem, browser, servizi in cloud, e non per ultimo alle API aziendali.

A quel punto una manipolazione del modello può trasformarsi in un’azione concreta, e devastante. Il Red Teaming deve verificare se esistono separazioni sufficienti tra: ciò che il modello può proporre e ciò che il sistema gli permette realmente di eseguire.

Il principio del minimo privilegio diventa quindi essenziale anche nell’AI: un agente non dovrebbe possedere più dati, strumenti o autorizzazioni di quelli necessari al proprio compito.

Ho approfondito il funzionamento di questi sistemi nell’articolo Agenti AI: cosa sono e come automatizzano l’intelligenza artificiale nelle aziende.

Data leakage e separazione tra utenti

Un altro obiettivo del test riguarda la possibilità che il sistema riveli informazioni che non dovrebbe esporre. Il problema può coinvolgere:

• system prompt;
• dati sensibili;
• documenti del RAG;
• informazioni appartenenti ad altri utenti;
• credenziali o token;
• dati presenti nei log;
• output di strumenti collegati.

Il test deve distinguere tra semplice generazione plausibile e reale accesso a informazioni che il modello non avrebbe dovuto conoscere. Una risposta convincente non è necessariamente una fuga di dati. Nel Red Teaming serve evidenza, non impressione.

Backdoor, poisoning e supply chain del modello

La compromissione può essere precedente all’utilizzo dell’AI. Dataset, fine-tuning, modelli scaricati da repository, adapter, componenti open source e pipeline di sviluppo costituiscono una supply chain che deve essere considerata nell’assessment. Un modello compromesso può comportarsi normalmente nella maggior parte dei casi e modificare il proprio comportamento soltanto in presenza di particolari condizioni o trigger. Questo rende backdoor e poisoning particolarmente difficili da individuare attraverso test funzionali ordinari.

Ho analizzato questo tema in Come rilevare le Backdoor AI. Anche il NIST SP 800-218A estende il Secure Software Development Framework con pratiche specifiche per modelli e sistemi di intelligenza artificiale, includendo nel perimetro di sicurezza modelli, pesi, pipeline e altri componenti del ciclo di sviluppo.

Dal concetto al test operativo

Comprendere quali rischi introduce un sistema basato su LLM è il primo passaggio. Il successivo è trasformare queste classi di rischio in scenari di test ripetibili, evidenze documentabili e valutazioni di exploitability e impatto. Nel prossimo approfondimento vedremo quindi come si struttura un LLM Red Teaming: dalla mappatura dell’architettura alla costruzione degli scenari avversariali, fino alla documentazione dei finding, alla mitigazione e al retest.