Prevenzione della prompt injection: i 4 livelli di difesa dell'IA

TL;DR

La prevenzione della prompt injection e difesa in profondita, non una patch. La causa di fondo e architetturale: un modello linguistico non riesce a separare le istruzioni dello sviluppatore dai dati dell'utente quando entrambi vivono nello stesso flusso di token. La strategia che funziona impila quattro livelli, guardrail di input, hardening del system prompt, addestramento di allineamento e guardrail di output, poi limita il raggio d'azione con il privilegio minimo, il logging e l'approvazione umana per le azioni rischiose. Ogni livello ha un bypass documentato, quindi nessuno puo essere saltato.

Questa e la Parte 3 di una serie in tre parti, e si regge da sola. Non hai bisogno di aver letto la Parte 1: Le fondamenta o la Parte 2: Il playbook offensivo per seguirla, anche se affineranno tutto cio che c'e qui. Se costruisci, questo e il tuo progetto. Se sei un bug bounty hunter, capire le difese rende i tuoi attacchi piu affilati.

Ogni azienda di IA sostiene che il suo chatbot e sicuro. Ognuna di loro sbaglia, almeno un po'. Ho visto aziende innestare un filtro a parole chiave sulla loro IA, annunciare di essere "a prova di prompt injection" e perdere quel filtro entro venti minuti di testing. Questo articolo e la meta della storia che riguarda il difensore, ed e onesto su cosa funziona, cosa no e perche.

Perche la prevenzione e difesa in profondita, non una patch

Per capire perche la prompt injection non puo essere semplicemente corretta con una patch, devi ricordare cos'e un large language model. Togli il marketing e un LLM e un motore di predizione statistica, lo stesso tipo di indovino del token successivo del completamento automatico del tuo telefono, scalato per predire paragrafi a partire da schemi appresi attraverso gran parte di internet.

Nel software tradizionale, codice e dati sono tenuti separati. SQL ha un linguaggio di query e parametri di input separati, e i dati non possono essere eseguiti come codice quando il sistema e costruito correttamente. I large language model non hanno un muro simile. Il system prompt dello sviluppatore, il messaggio dell'utente e qualsiasi contenuto esterno che il modello legge vengono tutti appiattiti in una sequenza continua di token. Se un pezzo di input dell'utente sembra un'istruzione, il modello potrebbe seguirla. Non perche e stato ingannato. Perche non ha alcun meccanismo per distinguere la differenza.

Quel singolo fatto e il motivo per cui la prompt injection sta al numero uno della OWASP Top 10 for LLM Applications, perche i tassi di successo degli attacchi documentati vanno dal 50 all'84 percento, e perche i modelli di frontiera restano vulnerabili dopo le loro migliori difese. Non e un bug in attesa di una patch. E l'architettura. Quindi i difensori smettono di cercare di rimuovere il difetto e iniziano a costruire strati attorno ad esso.

I 4 livelli di difesa dell'IA

La maggior parte delle applicazioni di IA ha quattro livelli difensivi, ognuno a protezione di tipi di attacco diversi. Pensa alla sicurezza aeroportuale. Il Livello 1 e il metal detector all'ingresso, il guardrail di input. Il Livello 2 e la carta d'imbarco che definisce dove ti e permesso andare, il system prompt. Il Livello 3 e l'addestramento del pilota che impedisce manovre pericolose, l'allineamento integrato nel modello. Il Livello 4 e l'agente di sicurezza a bordo che sorveglia i problemi una volta che sei gia sull'aereo, il guardrail di output.

Livello 1: guardrail di input

I guardrail di input ispezionano il prompt dell'utente prima ancora che raggiunga il modello. La validazione basata sui caratteri usa una regex per inserire in whitelist i caratteri consentiti, il che funziona per una calcolatrice ma e inutile per un chatbot general purpose. La validazione basata sui contenuti filtra sul significato invece che sui caratteri, spesso usando un modello classificatore piu piccolo per giudicare se l'intento dietro un messaggio sia malevolo. Questo intercetta molto di piu, ma costa latenza e denaro su ogni singola richiesta.

Il compromesso di fondo e inevitabile: i filtri a parole chiave rigidi sono banali da aggirare con encoding o parafrasi, mentre i filtri semantici sono piu difficili da ingannare ma piu lenti e inclini ai falsi positivi. Ecco perche tanti sistemi in produzione vengono rilasciati con filtri deboli, e perche un attaccante che prova Base64, inserimento Unicode o una lingua diversa di solito trovera una falla. Un guardrail di input e un dosso, non un muro.

Livello 2: hardening del system prompt

Il system prompt e la leva piu diretta dello sviluppatore, e tre tecniche lo rinforzano contro i dati non fidati che scorrono nello stesso flusso. La delimitazione marca il confine tra istruzioni fidate e input non fidato con simboli speciali, dicendo al modello di non obbedire mai alle istruzioni trovate tra di essi. Il datamarking va oltre, intervallando un carattere speciale tra ogni parola dell'input non fidato in modo che sia sintatticamente distinto dalle istruzioni. La codifica prende l'input non fidato e lo codifica, tipicamente in Base64, istruendo il modello a decodificare e riassumere ma a non trattare mai il testo decodificato come nuove istruzioni.

Nessuna di queste e infallibile. Un payload sufficientemente creativo puo comunque funzionare dentro i delimitatori, e un modello puo essere convinto a ignorare il datamarking. Ma ognuna alza il costo di un attacco riuscito, e alzare il costo e l'intero scopo. La ricerca di Microsoft su queste tecniche di spotlighting e la descrizione piu chiara di fin dove l'hardening del system prompt puo e non puo portarti.

Livello 3: addestramento di allineamento e fine-tuning

Questa e la difesa integrata nei pesi del modello anziche nel codice applicativo attorno ad esso. Il fine-tuning addestra ulteriormente un modello general purpose su dati specifici di dominio, cosi un modello di assistenza messo a punto solo su ticket di supporto resiste naturalmente al riutilizzo, semplicemente perche la sua distribuzione di addestramento non copre l'uso improprio. Piu stretto e il fine-tuning, piu piccola e la superficie.

L'addestramento avversariale sui prompt e una delle mitigazioni piu efficaci disponibili oggi. Il modello viene addestrato su prompt injection e payload di jailbreak noti come esempi negativi, allo stesso modo in cui un vaccino addestra un sistema immunitario su un patogeno indebolito. Il limite e ovvio una volta enunciato: l'addestramento avversariale protegge solo contro schemi che il modello ha gia visto, quindi i payload nuovi passano indisturbati. Ecco perche il red teaming regolare non e opzionale, e l'unico modo per mantenere aggiornate le difese del modello. Il prompt engineering come difesa, dire semplicemente al modello "non rivelare mai i segreti", e la mitigazione piu comune e anche la piu debole, banalmente aggirabile con role play o encoding. Appartiene allo stack, mai come unico livello.

Livello 4: guardrail di output

I guardrail di output scansionano la risposta del modello prima che raggiunga l'utente. Se la risposta contiene un system prompt, una chiave API, dati personali o contenuti dannosi, viene bloccata. Il bypass e elegante nella sua semplicita: chiedi al modello di codificare il proprio output, e un guardrail che cerca segreti in chiaro vede una stringa di Base64 e la lascia passare, mentre l'attaccante decodifica il risultato dalla sua parte.

I guardrail piu sofisticati usano la classificazione basata sull'IA, lo schema "LLM come giudice", dove un secondo modello valuta se l'input o l'output del modello primario sia malevolo. Questo aggiunge protezione reale, ma raddoppia il costo computazionale e introduce una nuova superficie di attacco. Se il modello giudice e a sua volta vulnerabile alla prompt injection, un attaccante puo convincerlo ad approvare contenuti malevoli. La difesa contro gli attacchi IA e un'altra IA che puo a sua volta essere attaccata. Questo e lo stato attuale del campo, ed e il caso di soffermarcisi un momento.

Una checklist di difesa per chi costruisce

Se stai costruendo qualunque cosa con un LLM nel ciclo, ecco lo stack minimo, scritto in prosa perche ogni elemento dipende dagli altri. Inizia con un filtro di input che abbina un classificatore semantico a una blocklist a parole chiave, sapendo che l'encoding puo comunque aggirarlo. Aggiungi l'hardening del system prompt tramite delimitazione o datamarking, sapendo che il framing creativo puo comunque passare. Applica il privilegio minimo affinche il modello possa toccare solo gli strumenti e i dati di cui ha strettamente bisogno, il che non ferma un attacco ma limita il raggio d'azione quando uno riesce, lo stesso principio dietro lo zero trust.

Poi aggiungi un filtro di output con uno scanner basato sull'IA piu il rilevamento dei dati personali, sapendo che l'output codificato puo sfuggire. Applica la limitazione della frequenza per utente per finestra, sapendo che gli attacchi lenti e distribuiti la aggirano. Registra ogni prompt e risposta, perche il logging e la differenza tra intercettare un attacco in minuti anziche in mesi. Richiedi un umano nel ciclo per le azioni ad alto rischio come i rimborsi, sapendo che un attaccante potrebbe provare a fare social engineering anche sul revisore. E fai red teaming su base ricorrente, perche emergono costantemente nuove tecniche. Nessun singolo elemento e sufficiente. Implementali tutti, e metti in conto il fatto che persino tutti insieme non saranno perfetti.

La superficie di attacco oltre la casella di chat

La maggior parte delle persone immagina la prompt injection come qualcosa che accade dentro una finestra di chat. La superficie di attacco reale e molto piu ampia, e gran parte di essa non ha nulla a che fare con una casella di chat. Io la penso come sette livelli, e la casella di chat e un piccolo pezzo di uno di essi.

Il livello dell'interfaccia sono i runtime LLM locali come Ollama, Llama.cpp e LM Studio, spesso esposti su HTTP senza autenticazione e individuabili tramite semplici search dork. Il livello di agente e orchestrazione sono i motori di workflow e le UI di chat come n8n, Flowise, Open WebUI e LibreChat, che possono far trapelare la cronologia delle chat o essere indotti al server side request forgery. Il livello di dati e memoria sono i vector store come Chroma, Weaviate e Qdrant, dove una collezione aperta puo essere avvelenata per influenzare cosa un'IA recupera e di cosa si fida. Il livello di ML engineering sono le dashboard come Ray, MLflow e ClearML, spesso distribuite senza autenticazione. Il livello di gateway e telemetria sono i gateway LLM come LiteLLM e Langfuse che stanno davanti a tutto il traffico dei modelli. Il livello di artefatti e plugin sono gli hub di modelli e i server MCP, dove un singolo plugin compromesso puo avvelenare ogni agente che si connette ad esso. E il livello di identita sono le chiavi API esposte per i principali fornitori, ognuna con uno schema distinto e facilmente cercabile. Sette livelli, e la casella di chat e solo la punta visibile.

OWASP Top 10: il framework che conta

Tre elenchi OWASP Top 10 separati coprono ora la sicurezza dell'IA, e capire tutti e tre ti da un modello di minaccia completo. La LLM Top 10 e l'originale: la prompt injection al numero uno, seguita dalla divulgazione di informazioni sensibili, dagli attacchi alla supply chain, dal poisoning di dati e modelli, dalla gestione impropria dell'output, dall'agency eccessiva, dal leak del system prompt, dalle debolezze di vettori ed embedding, dalla disinformazione e dal consumo illimitato.

La MCP Top 10 copre l'ecosistema del Model Context Protocol: cattiva gestione dei token, escalation dei privilegi tramite scope creep, tool poisoning, attacchi alla supply chain, command injection, prompt injection contestuale, autenticazione insufficiente, mancanza di audit logging, server MCP ombra e condivisione eccessiva del contesto. La Agentic Top 10 copre gli agenti autonomi: dirottamento degli obiettivi, uso improprio degli strumenti, abuso di identita e privilegi, compromissione della supply chain, esecuzione di codice inattesa, poisoning di memoria e contesto, comunicazione insicura tra agenti, fallimenti a cascata, sfruttamento della fiducia umana e agenti indebiti. C'e anche una ML Top 10 dedicata sottostante per i rischi classici del machine learning come il data poisoning, l'inversione del modello, l'inferenza di appartenenza e il furto del modello. Se sei un tester, mappa ogni finding a una di queste categorie. Se costruisci, tratta tutti e quattro gli elenchi come il tuo modello di minaccia, non solo il primo.

La difesa piu forte non e un filtro intelligente. E una decisione architetturale: non dare mai a un singolo sistema, contemporaneamente, dati privati, contenuti non fidati e un canale esterno.

IA agentica: la prossima frontiera

Tutto quanto sopra si applica a un semplice chatbot che risponde a domande. Il settore si muove rapidamente verso l'IA agentica, e la posta sale di un ordine di grandezza. I sistemi agentici non sono solo chatbot. Navigano sul web, inviano email, eseguono codice, modificano file, effettuano chiamate API e parlano con altri agenti. Combina quella portata con una prompt injection e l'impatto si sposta da "il modello ha detto qualcosa di imbarazzante" a "il modello ha cancellato dati di produzione" o "il modello ha inviato via email segreti aziendali a un indirizzo esterno".

E qui che la trifecta letale diventa essenziale per i difensori, non solo per gli attaccanti. Qualsiasi sistema agentico che simultaneamente ha accesso a dati privati, e esposto a contenuti non fidati e puo comunicare esternamente e banalmente sfruttabile. La soluzione non e un filtro intelligente, e rimuovere una gamba del triangolo.

Gli attacchi indiretti multi hop, dove un payload passa attraverso piu agenti prima di attivarsi, sono in rapida crescita, e i worm IA che si auto-propagano attraverso sistemi connessi sono gia stati dimostrati in ricerche controllate. L'esempio pubblico piu chiaro di rischio agentico finora e l'operazione GTG-1002, che ho analizzato in come gli hacker usano l'IA: gli attaccanti hanno collegato un agente a una macchina Kali Linux, esposto strumenti offensivi tramite MCP e lo hanno lasciato eseguire ricognizione, sfruttamento e movimento laterale in gran parte da solo. Il pericolo cresceva con l'autonomia, non con la pura potenza del modello. Per i bug bounty hunter, e qui che vivono le vere ricompense. Una prompt injection che fa trapelare un system prompt e informativa. Una che fa emettere a un agente un rimborso non autorizzato o cancellare un database e critica. Stessa abilita di fondo, posta drammaticamente piu alta.

Una checklist di testing per i cacciatori

Se stai testando un'applicazione di IA per la prompt injection, procedi in questo ordine e documenta tutto, ricordando che lo stesso payload potrebbe non funzionare due volte, quindi riprova ogni tecnica tre volte e affina la formulazione. Inizia con la ricognizione: identifica il modello e la sua architettura, per cosa e stato messo a punto, quali strumenti puo chiamare e ogni canale di input incluso testo, file, immagini e URL. Passa all'iniezione diretta: estrai il system prompt tramite tecniche dirette e indirette, testa i bypass tramite encoding su Base64, ROT13, esadecimale e l33t speak, testa il cambio di lingua, testa il role play e il dirottamento di persona, e testa l'escalation multi turno su cinque o piu turni.

Poi testa l'iniezione indiretta tramite testo nascosto in PDF, commenti HTML e testo bianco su bianco, e testa i bypass tramite encoding dell'output chiedendo al modello di codificare le sue risposte. Infine, fai escalation: testa l'abuso di strumenti e azioni inclusi le azioni indebite e il server side request forgery, testa l'iniezione markdown tramite tag immagine per l'esfiltrazione di dati, e concatena tre o piu tecniche in un unico payload per il massimo impatto. Tutto il dettaglio offensivo per ognuna di queste vive nella Parte 2: Il playbook offensivo. Documenta tutto, fai screenshot di tutto e segnala con passi di riproduzione chiari e impatto dimostrato.

Ecco la verita che nessuno ti dice

Stiamo correndo a distribuire agenti autonomi che compiono azioni nel mondo reale su una fondazione che tutti nel settore sanno essere rotta. Il difetto architetturale che rende possibile la prompt injection non e stato risolto, e non e stato nemmeno risolto in parte. Ogni difesa in questo articolo e un cerotto su quella ferita, e la superficie di attacco cresce piu in fretta di quanto i cerotti possano essere applicati.

Questo non significa che la difesa sia inutile. La difesa in profondita funziona davvero: rende gli attacchi piu lenti, piu difficili e molto piu rilevabili, e contro la maggior parte degli attaccanti questo basta a vincere. Questo campo non si sta esaurendo, si sta espandendo. Il numero di applicazioni integrate con l'IA cresce in modo esponenziale, e il numero di persone che sanno testarle o difenderle non tiene il passo. Quel divario e l'opportunita, da qualunque lato del tavolo tu sieda.

Conclusione

La prompt injection e la vulnerabilita determinante dell'era dell'IA, allo stesso modo in cui la SQL injection ha definito l'era delle applicazioni web. A differenza della SQL injection, non esiste un equivalente del prepared statement, perche la causa di fondo e l'assenza di un confine tra istruzioni e dati dentro il modello stesso. Il massimo che chiunque possa fare e impilare strati, monitorare in modo aggressivo, limitare cio che gli agenti possono toccare e restare un passo avanti agli attaccanti, a cui basta una sola falla.

Se questo suona scoraggiante, ribaltalo. Ogni sistema spinto in produzione oggi e un futuro bersaglio di test, una futura bug bounty, un futuro paper di ricerca. I team che capiscono l'impalcatura, e decidono deliberatamente dove un umano deve restare nel ciclo, sono quelli che mantengono il controllo man mano che gli agenti si fanno carico di sempre piu lavoro. E esattamente la mentalita che costruiamo nel bootcamp di cybersecurity di Unihackers. Vai a testare. Vai a costruire. Vai a rendere i sistemi di IA piu sicuri di quelli che hai trovato.

Continua a cacciare. Resta curioso.