“Hai assunto un assistente brillante che crede a tutto ciò che legge, e gli hai dato le chiavi.”
Il confine che svanisce
In un'applicazione normale, il codice è codice e i dati sono dati. Una query SQL è un insieme di istruzioni; il nome dell'utente è un dato. Decenni di pratica della sicurezza (validazione degli input, query parametrizzate, escaping) esistono per mantenere netta quella linea. L'intera disciplina della difesa dalle injection consiste nel non lasciare che i dati diventino istruzioni.
Un modello di linguaggio cancella quella linea. Il prompt è un unico flusso di testo che contiene le tue istruzioni, l'input dell'utente e ogni documento recuperato, e il modello legge il tutto come istruzioni che potrebbe seguire. Non esiste una sintassi che dica "questa parte è un dato, non obbedirle". Il modello decide cosa trattare come comando, e decide male sotto pressione.
I confini di fiducia, ridisegnati
La sicurezza parte da una domanda: di cosa ti fidi, e dove l'attendibile incontra il non attendibile? Con un LLM la risposta onesta è scomoda. Tutto ciò che il modello legge (messaggi dell'utente, documenti recuperati, output di tool, il contenuto di una pagina web che ha visitato) è non attendibile e potrebbe trasportare istruzioni. E tutto ciò che il modello può fare (chiamare tool, restituire dati, innescare azioni) è una capacità che un attaccante può provare a prendere in prestito.
Perché il vecchio manuale non basta più
La sicurezza applicativa tradizionale vale ancora: ti servono comunque autenticazione, autorizzazione, cifratura e tutto il resto. Ma è stata progettata per sistemi deterministici con grammatiche di input chiare. Un LLM non ha una grammatica di input; un "input valido" è qualsiasi testo in qualsiasi lingua, incluso un testo costruito per manipolare il modello. Non puoi scrivere una regex per la malizia espressa in italiano corrente.
Quindi la sicurezza dell'IA è additiva, non un sostituto. Conservi tutto ciò che già fai, e aggiungi uno strato per le specifiche modalità di guasto del modello: seguire istruzioni provenienti da contenuto non attendibile, divulgare ciò che gli è stato detto, farsi convincere ad aggirare i propri guardrail, e agire oltre ciò che avevi previsto. I prossimi cinque capitoli trattano queste modalità di guasto; l'ultimo riguarda come governare il tutto.
Una mappa di ciò che può andare storto
La comunità ha convenuto su una tassonomia approssimativa: la OWASP Top 10 per le applicazioni LLM ne è la versione più citata, e vale la pena leggerla per intero. I rischi principali si raggruppano in poche famiglie:
- Prompt injection: contenuto non attendibile dirotta le istruzioni del modello (capitolo 2).
- Divulgazione di informazioni sensibili: il modello fa trapelare dati che gli sono stati forniti o su cui è stato addestrato (capitolo 3).
- Jailbreak e abuso: il modello viene guidato oltre i suoi guardrail di sicurezza (capitolo 4).
- Rischi della catena di fornitura: dati avvelenati, modelli con backdoor, pacchetti e tool malevoli (capitolo 5).
- Agentività eccessiva: al modello è permesso fare più di quanto sarebbe sicuro (tema trasversale).
Nessuno di questi rischi è esotico. Sono le conseguenze prevedibili di un sistema che segue istruzioni in linguaggio naturale e che hai collegato a capacità reali. Capirli è gran parte della difesa.
Una riga per ciascuno
- Gli LLM cancellano il confine istruzioni/dati su cui poggia la sicurezza classica: tutto ciò che sta nel prompt viene letto come potenziali istruzioni.
- Tratta ogni token che il modello legge come non attendibile, e ogni azione che può compiere come potenzialmente abusata.
- La sicurezza dell'IA è additiva: conserva tutta la sicurezza applicativa tradizionale, e aggiungi uno strato per le specifiche modalità di guasto del modello.
- Le tassonomie standard (OWASP LLM Top 10, MITRE ATLAS) sono una mappa utile, non una difesa. Orientano la tua modellazione delle minacce, non la sostituiscono.
Dove andare ora