Prompt injection: come può essere attaccato un sistema AI e come difenderlo
La prompt injection è una vulnerabilità che consente a un contenuto non affidabile di modificare in modo indesiderato il comportamento di un sistema basato su modelli linguistici. Il rischio non riguarda soltanto i chatbot: cresce quando l’AI legge documenti, consulta siti, usa strumenti o può eseguire azioni.
Un prompt di sistema ben scritto è utile per guidare il modello, ma non costituisce un confine di sicurezza. La protezione deve essere costruita anche nell’applicazione, nei permessi, nella validazione e nel controllo delle operazioni.
Che cos’è la prompt injection
Secondo la classificazione LLM01:2025 di OWASP, una prompt injection si verifica quando gli input alterano il comportamento o l’output del modello in modi non previsti. Le istruzioni possono essere visibili, nascoste o incorporate in contenuti che il sistema tratta come dati.
Il problema nasce perché il modello elabora nello stesso contesto istruzioni e informazioni. Può quindi interpretare come comando una parte che l’applicazione considerava soltanto contenuto da leggere.
Prompt injection diretta e indiretta
La distinzione principale riguarda l’origine dell’istruzione ostile:
- Diretta: l’utente inserisce il contenuto manipolativo nel campo di conversazione o in un parametro controllato direttamente.
- Indiretta: l’istruzione arriva da una fonte esterna consultata dal modello, come pagina web, email, PDF, ticket, repository o documento recuperato tramite RAG.
La forma indiretta è particolarmente insidiosa perché l’utente può chiedere un’attività legittima, mentre l’istruzione pericolosa si trova nel materiale analizzato. Nei sistemi multimodali può essere inclusa anche in immagini o in altri formati elaborati dal modello.
Prompt injection e jailbreak non sono sinonimi
I due termini sono collegati ma descrivono obiettivi diversi. Il jailbreak cerca normalmente di superare le salvaguardie del modello e ottenere una risposta vietata. La prompt injection mira a modificare il comportamento dell’applicazione, per esempio ignorando il compito, alterando un risultato o tentando di utilizzare uno strumento senza autorizzazione.
Una protezione contro contenuti inappropriati non risolve automaticamente il rischio applicativo. Un output apparentemente innocuo può comunque causare una decisione errata o attivare un flusso non previsto.
Dove può entrare l’istruzione ostile
La superficie di attacco aumenta con le fonti che il sistema può consultare:
- campi di chat, moduli e commenti;
- documenti caricati dagli utenti;
- pagine web recuperate automaticamente;
- email, ticket e messaggi interni;
- basi di conoscenza e sistemi RAG;
- metadati, nomi di file e descrizioni;
- immagini elaborate da modelli multimodali;
- output restituiti da strumenti o servizi esterni.
Ogni origine deve avere un livello di fiducia esplicito. Il fatto che un documento sia presente in una base aziendale non garantisce che il suo contenuto sia sicuro o aggiornato.
Perché il rischio cresce con strumenti e autonomia
In un assistente che genera soltanto testo, una prompt injection può produrre una risposta errata o divulgare informazioni presenti nel contesto. In un agente collegato a email, database o funzioni operative, lo stesso errore può tentare un’azione.
La gravità dipende quindi da dati accessibili, strumenti disponibili, privilegi e reversibilità. Prima di aggiungere autonomia conviene distinguere tra agenti AI e workflow deterministici e scegliere il livello minimo necessario.
Il modello di minaccia da costruire
Un’analisi efficace parte dal percorso completo:
- quali contenuti può ricevere il modello;
- quali dati sensibili sono presenti nel contesto;
- quali strumenti può richiamare;
- quali identità e credenziali vengono utilizzate;
- quali output diventano comandi, codice o decisioni;
- quali azioni richiedono conferma umana;
- come vengono registrati tentativi ed errori.
Il diagramma deve separare chiaramente contenuto fidato, contenuto esterno e componenti deterministiche. Senza questa mappa è difficile capire dove applicare controlli.
Difesa 1: separare istruzioni e contenuti non affidabili
Le fonti esterne devono essere etichettate e delimitate. Il prompt può spiegare che il materiale recuperato è informativo e non deve modificare il compito, ma questa istruzione è soltanto un livello di difesa.
L’applicazione dovrebbe limitare porzioni di contenuto, rimuovere elementi non necessari e conservare la provenienza. Nei sistemi RAG vanno controllati accesso ai documenti, integrità della base e criteri di recupero.
Difesa 2: minimo privilegio e strumenti specifici
Un modello non dovrebbe ricevere credenziali generiche o funzioni eccessivamente potenti. Ogni strumento deve svolgere un’operazione limitata, con parametri validati dal codice.
È preferibile distinguere tra leggere, proporre e modificare. Un agente può preparare una bozza senza poterla inviare; può suggerire una modifica senza applicarla. Per le operazioni sensibili servono autorizzazioni lato server e verifica dell’identità, non una semplice conferma testuale prodotta dal modello.
Quando dati e strumenti vengono collegati tramite Model Context Protocol, i confini di fiducia e i permessi devono restare espliciti.
Difesa 3: validare output e azioni
L’output del modello va considerato non affidabile. Se deve diventare JSON, query, HTML, codice o argomento di una funzione, deve superare controlli deterministici.
- Usare schemi e liste di valori consentiti;
- rifiutare parametri fuori perimetro;
- verificare destinazioni, importi e identità;
- applicare limiti di frequenza e di spesa;
- impedire che l’output venga eseguito direttamente;
- richiedere approvazione per operazioni irreversibili.
Gli output strutturati migliorano la forma, ma non garantiscono che il contenuto sia corretto o autorizzato.
Difesa 4: filtri, monitoraggio e test avversari
I filtri in ingresso e in uscita possono individuare pattern sospetti, richieste fuori dominio o tentativi di ottenere dati riservati. Non sono una soluzione completa: attacchi offuscati o distribuiti su più fonti possono superarli.
È necessario registrare contenuti recuperati, strumenti richiesti, esiti delle autorizzazioni e decisioni bloccate. I test avversari devono includere prompt diretti, documenti contaminati, istruzioni nascoste, input multilingua, errori degli strumenti e sequenze su più turni.
La metrica utile non è soltanto “l’attacco è stato riconosciuto”, ma anche “nessuna azione non autorizzata è stata eseguita”.
Esempio: assistente che analizza documenti
Immaginiamo un sistema che riceve contratti e produce una sintesi. Il file è contenuto non fidato. Il modello può estrarre clausole, ma non deve cambiare le regole di analisi, consultare altri contratti o inviare risultati.
Una progettazione più sicura prevede archivio isolato, recupero limitato al documento autorizzato, output conforme a uno schema, verifica delle citazioni e approvazione prima di esportare la sintesi. Se viene rilevata un’istruzione rivolta al modello, il sistema la segnala come contenuto del documento anziché eseguirla.
Checklist di sicurezza
- Le fonti esterne sono identificate come non affidabili?
- I dati sensibili vengono esclusi quando non necessari?
- Ogni strumento applica autorizzazioni lato server?
- Il modello dispone soltanto dei privilegi minimi?
- Gli output vengono validati prima dell’uso?
- Le azioni ad alto impatto richiedono approvazione?
- Esistono limiti a iterazioni, tempo e costo?
- I log permettono di ricostruire contenuti e operazioni?
- I test includono prompt injection indirette e multimodali?
Domande frequenti
Un prompt di sistema può impedire ogni prompt injection?
No. Può ridurre alcuni comportamenti indesiderati, ma non costituisce un confine affidabile. Permessi e validazioni devono essere applicati fuori dal modello.
Il RAG elimina il rischio?
No. Migliora l’accesso alle informazioni, ma i documenti recuperati possono contenere istruzioni ostili o dati non autorizzati.
È sufficiente bloccare frasi come “ignora le istruzioni precedenti”?
No. Gli attacchi possono essere indiretti, offuscati, multilingua o distribuiti. Il filtro testuale è soltanto una difesa parziale.
Quando serve l’approvazione umana?
Quando l’azione modifica dati, comunica all’esterno, comporta spese, concede accessi o produce conseguenze difficili da annullare.
La sicurezza deve stare attorno al modello
La prompt injection non si risolve cercando una formula perfetta nel prompt. Un sistema robusto separa istruzioni e dati, limita i privilegi, valida gli output e controlla ogni azione importante. Il modello può essere probabilistico; autorizzazioni e confini di sicurezza devono restare deterministici.