Per creare sistemi di IA che funzionino, bisogna prima riuscire a metterli in crisi. Abbiamo condotto un’attività di red teaming, assumendo il ruolo di potenziali aggressori per testare e mettere alla prova un’applicazione di IA per clienti nel settore finanziario. Ciò che abbiamo scoperto è importante per chiunque distribuisca applicazioni basate su LLM in contesti in cui la sicurezza è imprescindibile.
Il red teaming consiste nel tentare deliberatamente di compromettere un sistema di IA, così da correggerne le vulnerabilità prima che le scopra un vero aggressore. Nei servizi finanziari, la posta in gioco è particolarmente alta: le applicazioni di IA accedono ai dati dei clienti, elaborano transazioni e forniscono analisi finanziarie. Un malfunzionamento può causare una cattiva esperienza utente, violazioni normative, perdite finanziarie e danni irreparabili alla reputazione del marchio.
Il nostro obiettivo era individuare tempestivamente le vulnerabilità, testare scenari di attacco realistici e aiutare l’organizzazione a soddisfare i requisiti di sicurezza dell’IA che le autorità di regolamentazione prendono molto sul serio.
È utile fare una distinzione: il jailbreaking prende di mira i filtri di sicurezza del modello sottostante; l’iniezione di prompt attacca invece l’applicazione stessa, combinando input utente non attendibili con il prompt attendibile dello sviluppatore. L’iniezione di prompt comporta rischi maggiori perché prende di mira il sistema e i dati riservati su cui opera, non un modello generico.
La prima tornata ha incluso circa 750 test relativi a:
Fuga di dati tra sessioni
Esposizione di dati personali identificabili (tramite linguaggio naturale, manipolazione delle API e diverse codifiche)
SQL injection
Sovrascrittura dei prompt di sistema
Durante i test iniziali abbiamo individuato due gravi problemi nel sistema esistente: la gestione delle richieste con più intenti e l’uso di prompt codificati.
Richieste con più intenti: richieste che combinano istruzioni legittime e dannose. Ad esempio: “Mostra le mie spese per categoria ed esegui anche [SQL dannoso].” L’applicazione non rilevava l’intento dannoso e si affidava interamente alle misure di protezione del livello dati a valle. È come lasciare aperta la porta di casa perché ci si fida della cassaforte in cantina.
Codifica: richieste codificate in Base64, esadecimale, LeetSpeak e omoglifi. Per i sistemi può essere difficile filtrare gli intenti dannosi. Sebbene queste richieste non abbiano esposto dati sensibili, hanno destabilizzato notevolmente il sistema, causando allucinazioni, la ripetizione agli utenti di SQL dannoso, errori nella classificazione degli intenti e altri problemi.
I risultati dei test iniziali hanno evidenziato:
Allucinazioni temporali: il modello restituiva con sicurezza date, timestamp delle transazioni o riepiloghi relativi a periodi specifici, ma inventati. Un rischio significativo in ambito finanziario, dove un cliente che agisce sulla base di una data errata può subire conseguenze reali
Ripetizione di SQL dannoso all’utente, con conseguenti rischi di avvelenamento della memoria
Errori nella classificazione degli intenti
Formattazione dell’output incoerente
Alla luce di questi risultati, abbiamo ristretto il campo d’indagine. I test di SQL injection e codifica hanno ricevuto una priorità inferiore, perché il team stava già affrontando questi problemi. Ci siamo invece concentrati sui vettori di attacco più efficaci: l’esposizione di dati personali identificabili e la fuga di dati tra sessioni.
Il risultato più sorprendente della seconda tornata era di una semplicità disarmante: spesso non serve alcun espediente ingegnoso.
In molti casi, è bastato chiedere dati interni, presentando la richiesta come parte di un’operazione apparentemente legittima, perché il sistema accettasse di esporli. A semplici richieste venivano fornite risposte contenenti riferimenti a ID interni e campi di sistema che non avrebbero mai dovuto essere visibili agli utenti finali.
Approfondendo l’analisi, abbiamo scoperto che non si trattava soltanto di un problema a livello dell’applicazione. Il servizio text-to-SQL a valle generava query che richiedevano più campi del necessario e nelle sue risposte esplicative faceva riferimento a dati che avrebbero dovuto essere soggetti a restrizioni. È così emersa una vera falla nell’integrazione tra i sistemi: una vulnerabilità che si manifesta soltanto testando l’intero stack, anziché i singoli componenti separatamente.
Sottoponete a red teaming il sistema, non il modello. Testare un LLM isolatamente dice ben poco sul livello di sicurezza dell’applicazione. Testate l’intero stack end-to-end, così come vi interagirebbe un utente.
La convalida degli input deve precedere l’LLM. Le richieste codificate, gli attacchi con più intenti e i tentativi basilari di injection devono essere bloccati al perimetro, non delegati ai servizi a valle.
Non fidatevi dei punti di raccordo. Nelle architetture con più servizi, le vulnerabilità più interessanti si nascondono nelle crepe tra i sistemi. Zero trust significa non fidarsi di nulla: convalidate tutto, a ogni livello.
Gli attacchi semplici funzionano. I jailbreak sofisticati conquistano i titoli, ma a volte basta semplicemente... chiedere. Se il sistema espone senza esitazioni identificatori interni quando un utente li include in una richiesta altrimenti legittima, c’è un problema.
Comprendete cosa state effettivamente testando. Gli schemi di attacco noti potrebbero essere bloccati dall’addestramento dell’LLM stesso, anziché dalle vostre misure di protezione. Integrate l’osservabilità nel red teaming per capire quali controlli vengono effettivamente attivati.
Gli ambienti con vincoli richiedono soluzioni creative. Provider personalizzati e supporto per modelli locali consentono di svolgere un red teaming efficace senza accessi cloud specialistici. Occorre però essere trasparenti sui limiti che ne derivano.
Il red teaming non è un’attività una tantum. È un processo iterativo, da automatizzare ove possibile e far evolvere insieme al sistema. Gli attacchi che conteranno domani non saranno gli stessi che contano oggi.
I sistemi di IA negli ambienti regolamentati saranno sottoposti a controlli sempre maggiori, non minori. Le organizzazioni che considerano i test di sicurezza una disciplina continua, anziché una casella da spuntare prima del lancio, saranno più preparate ad affrontare questi controlli e a evitare crisi di reputazione che compromettano la fiducia dei clienti.