La prompt injection è un male strutturale dei Large language model (LLM) e non un bug correggibile. OpenAI è tornata sull’argomento pubblicando un documento relativo a ChatGPT Atlas, il browser che integra l’AI nella navigazione web.
Il discorso si estende però a tutti i LLM, nei quali le tecniche di prompt injection sono endemiche. Non si tratta di un “problema” causato da un errore ma, per usare un termine mutuato dalla biologia, è parte integrante dell’anatomia dei modelli AI.
La questione non può essere archiviata con rassegnazione, perché parte integrante delle capacità difensive di ogni organizzazione che fa uso delle AI o intende farne uso in futuro.
Ci sono modi per limitare i rischi e ogni azienda dovrebbe metterli in pratica, perché non c’è e non ci sarà mai una “patch” miracolosa che risolve queste vulnerabilità.
A costo di ribadire l’ovvio, anche le misure per contrastare gli attacchi prompt injection sono, prima di ogni altra cosa, esercizi di organizzazione dei flussi aziendali e di diffusione del sapere tra i dipendenti.
Indice degli argomenti
Prompt Injection: anatomia di una vulnerabilità strutturale nei LLM
Il termine prompt injection si riferisce a una vulnerabilità dei modelli di linguaggio che consente l’uso di input manipolati al fine di alterare il comportamento di un’AI.
Tema datato e sempre attuale, perché affine ai limiti intrinseci dei LLM che non riconoscono in modo netto le istruzioni e il contenuto, argomento questo sul quale torniamo tra poco.
Un attacco di tipo prompt injection può essere diretto (scritto dall’attaccante) oppure indiretto, ovvero perpetrato mediante istruzioni celate nei dati, nei documenti oppure all’interno di risorse web.
La prompt injection dà esiti potenzialmente nefasti quali la manipolazione delle funzionalità dei modelli IA, la disattivazione di strumenti di sicurezza o di restrizioni e, non da ultimo, la divulgazione di informazioni riservate.
È una delle poche vulnerabilità che non nasce da un errore o da un difetto di implementazione. Al contrario, è una vulnerabilità che emerge direttamente dal modo in cui i LLM sono costruiti, addestrati e utilizzati.
Un LLM non è un mero interprete di comandi ma un sistema che, facendo leva sulla statistica, prevede la parola successiva di una frase sulla scorta di correlazioni linguistiche.
Non è, per sua stessa natura, capace di distinguere tra istruzioni e contenuto, non ha idea di cosa sia un privilegio o una restrizione, non ha una grammatica interna che lo mette in condizione di separare concettualmente ciò che va eseguito da ciò che va esaminato.
Riceve del testo che, nel suo insieme, viene trattato come parte del contesto a partire dal quale generare la risposta più probabile.
Ed è proprio questa caratteristica a rendere la prompt injection un problema strutturale: un LLM non ha strumenti proprietari per comprendere se le istruzioni provengono da utenti legittimi o da malintenzionati.
Gli attacchi indiretti
Il problema diventa ancora più marcato quando gli attacchi sono indiretti. La narrativa popolare sulla prompt injection si concentra sui jailbreak espliciti, ma la vera minaccia è – più in generale – nei contenuti che il modello deve elaborare autonomamente.
Occorre introdurre brevemente le differenze tra attacchi prompt injection e jailbreaking. Mentre i primi mirano a minare la logica operativa per esfiltrare dati o impartire comandi inattesi e non autorizzati, gli attacchi jailbreaking puntano a disattivare i filtri etici e di sicurezza.
Gli assistenti AI, anche quelli più “banali” che esaminano e riassumono documenti, estraggono dati da pagine web o interagiscono con contenuti generati da terzi sono sempre esposti a vettori di attacco.
Paragrafi di documenti, commenti html o metadati possono contenere payload nascosti che il modello interpreta come parte del contesto, arrivando così a scostarsi dall’input originale e a compiere azioni che l’utente non ha mai effettivamente richiesto.
La situazione peggiora drasticamente quando il modello non si limita a generare testo, ma può invocare strumenti esterni.
I moderni sistemi di AI agentiva consentono ai modelli AI di creare o modificare file, di fare chiamate API, dialogare con database e persino organizzare e dispiegare flussi di lavoro articolati.
L’assenza di filtri
Non esiste (e non può esistere) un filtro: ogni tentativo di bloccare la prompt injection tramite blacklist, pattern matching o prompt engineering è destinato a fallire.
La creatività degli attaccanti è dinamica e quella di ogni potenziale filtro non tiene il passo. Un payload può essere mascherato, codificato, offuscato, distribuito lungo più frasi o reso apparentemente innocuo.
Pensare a un algoritmo capace di distinguere le istruzioni malevole è un esercizio di fantasia sterile che, in ogni caso, non risolve il problema.
Il punto essenziale è persino banale: la sicurezza dei LLM non può essere demandata a dei LLM.
È necessario creare architetture che considerano i LLM inaffidabili, ed è una cultura tipica dei sistemi Zero Trust.
La mitigazione
Le istruzioni dell’applicazione, così i contenuti dell’utente e le regole di sistema devono essere separati e ogni output del modello deve essere validato da un motore esterno prima che possa produrre effetti reali.
Le azioni devono essere eseguite solo da componenti privilegiati e mai dal modello stesso. Il modello deve essere confinato in una sandbox con privilegi minimi, incapace di accedere direttamente a risorse critiche. E ogni interazione deve essere monitorata, registrata e analizzata per individuare comportamenti anomali.
La mitigazione richiede un cambio radicale nel modo in cui si progettano i sistemi che integrano modelli di IA generativa e impone alle aziende di integrare strategie di sicurezza adattiva.
Misure di controllo degli input
I prompt devono essere esaminati per individuare pattern sospetti o manipolatori. Operazione assai complessa dai risultati incerti che ha un senso propedeutico come anello di una catena di controlli più lunga e ramificata.
L’uso di gateway o wrapper AI consente un maggiore livello di sicurezza. Un wrapper AI è una sorta di involucro software, porzioni di codice che preparano una richiesta prima che questa venga inviata al modello, intermediando anche la risposta che il modello restiuisce.
Questi sistemi non si limitano a veicolare il traffico, ma permettono l’applicazione di protocolli di validazione degli input capaci di scansionare i prompt alla ricerca di pattern manipolatori o istruzioni nascoste prima che queste possano corrompere la logica del sistema.
Parallelamente, è essenziale imporre un rigoroso isolamento del contesto, garantendo che le sessioni dei singoli utenti rimangano compartimentate. Ciò impedisce ai malintenzionati di influenzare interazioni altrui o di accedere a dati sensibili elaborati in contesti differenti.
Non di meno, impostare rate limit può essere salvifico, ancorché insufficiente, nel bloccare attività insolite, spesso strettamente legate a richieste multiple fatte a un sistema AI in rapidissima successione e non di rado sinonimo di attacchi in corso.
Gestione e monitoraggio dei sistemi
La prima regola è quella di limitare le interazioni con i sistemi AI. Diventa essenziale quindi impostare permessi rigorosi per i prompt che coinvolgono informazioni sensibili.
Inoltre, test e audit iterati con buona regolarità, consentono di ridurre il rischio che input malevoli possano aggirare le misure di sicurezza implementate.
Questo perché i modelli IA adottati dalle organizzazioni devono essere visti come endpoint critici e, come tali, necessitano di continue verifiche che consentano di misurarne le capacità di difesa e di resilienza.
Monitoraggio e test vanno estesi ai modelli IA così come ci si attende che ogni impresa li garantisca per server, client e per tutti i dispositivi aziendali, anche quelli IoT e IIoT (Internet of Things e Industrial Internet of Things) .
Una strategia di difesa realmente efficace deve quindi fondarsi su un approccio di cybersicurezza adattiva che riconosca l’unicità dei rischi legati ai prompt.
Le strategie organizzative
In ultima analisi, la protezione contro prompt injection e jailbreaking richiede l’adozione di un framework di governance delle AI che integri controlli di accesso granulari e una formazione specialistica per il personale.
Solo trattando l’IA come una componente critica della strategia di sicurezza dei dati, le aziende possono mitigare i rischi di violazioni della conformità (come il GDPR) e prevenire la perdita di proprietà intellettuale, trasformando una potenziale vulnerabilità in un asset sicuro e affidabile.
Educare dipendenti e collaboratori sul funzionamento della prompt injection, insegnando loro a riconoscere input sospetti e a segnalare tempestivamente potenziali incidenti.
La letteratura di riferimento
Per quanto sia dibattuto, il tema della prompt injection può essere solo di rado coperto integralmente. È un campo potenzialmente minato di dimensioni tanto ampie quanto l’uso che un’organizzazione fa delle AI.
Se, come citato in apertura, OpenAI invita al rafforzamento (di Atlas) pure riconoscendo che non esiste una soluzione che possa fissare il problema in modo definitivo e invitando alle strategie di mitigazione multilivello, Microsoft non si distanzia molto. Infatti, il gigante di Redmond, nelle proprie linee guida sulla sicurezza dei sistemi basati su LLM, invita alla cautela estrema e mette a disposizione sistemi e filtri difensivi.
Al di là delle soluzioni proposte da questo o da quel venditore, il National Institute of Standards and Technology (NIST) offre una panoramica sui rischi sistemici e sulla necessità di governance e validazione continua.
Allo stesso modo, l’organizzazione no-profit Open Worldwide Application Security Project (OWASP) si spende molto nel dibattito relativo alla mitigazione dei rischi connessi alla prompt injection (e alle tecniche di jailbreaking).
