IN BREVE
Una prompt injection si verifica quando un’istruzione contenuta nell’input o nel materiale acquisito interferisce con il compito affidato a un sistema di intelligenza artificiale. Può essere diretta, quando viene inserita nel messaggio dell’utente, oppure indiretta, quando raggiunge il modello attraverso un documento, una pagina web, un’e-mail o una fonte recuperata mediante RAG. Il sistema può interpretare come comando ciò che dovrebbe trattare soltanto come contenuto, producendo una risposta alterata o tentando di utilizzare impropriamente gli strumenti disponibili. La prompt injection non coincide con un’allucinazione e richiede misure specifiche, tra cui separazione tra dati e istruzioni, limitazione dei permessi, controllo degli output e supervisione umana.
Quando chiediamo a un sistema di intelligenza artificiale di riassumere un documento, analizzare una pagina web o confrontare più file, tendiamo a considerare i contenuti acquisiti come semplici informazioni. Il sistema dovrebbe leggerli, individuare gli elementi rilevanti e svolgere il compito che gli abbiamo assegnato. Questa rappresentazione è intuitiva, ma non descrive interamente ciò che può accadere.
Un modello linguistico elabora sequenze di testo. Nella stessa finestra di contesto possono confluire le istruzioni predisposte dall’applicazione, la richiesta formulata dall’utente, i documenti recuperati da fonti esterne e altri contenuti necessari per generare la risposta. Il modello deve quindi distinguere le parti che indicano che cosa deve fare da quelle che costituiscono soltanto il materiale sul quale lavorare.
Questa separazione non è sempre perfetta. Un documento destinato a essere analizzato può contenere una frase che, per un lettore umano, appartiene semplicemente al testo, ma che il modello può interpretare come una nuova istruzione. Se quella frase interferisce con il compito originario e riesce a modificare il comportamento del sistema, si verifica il fenomeno chiamato prompt injection.
Quando il contenuto interferisce con il compito
Immaginiamo di chiedere a un assistente di intelligenza artificiale di leggere una relazione e prepararne una sintesi. La richiesta è chiara. Il sistema dovrebbe individuare i passaggi principali, organizzarli e restituire un testo più breve.
All’interno della relazione potrebbe però comparire una frase rivolta non al lettore, ma al sistema incaricato di elaborarla. Il modello si troverebbe così davanti a due indicazioni diverse. Da una parte vi è il compito assegnato dall’utente. Dall’altra vi è una sequenza contenuta nel documento che potrebbe essere interpretata come un comando.
Un sistema ben progettato dovrebbe trattare quella frase come parte del documento e non come un’istruzione autorizzata. Il problema nasce quando il modello non riesce a mantenere questa distinzione e lascia che il contenuto esterno influenzi la risposta.
La prompt injection sfrutta proprio questa difficoltà. Non altera necessariamente il software, non richiede sempre l’accesso all’infrastruttura e non coincide con un attacco informatico tradizionale. Agisce sul modo in cui il sistema interpreta il linguaggio e attribuisce una funzione alle diverse parti del contesto.
OWASP considera la prompt injection una delle principali vulnerabilità delle applicazioni basate su modelli linguistici. Il fenomeno si verifica quando un input modifica in modo non previsto il comportamento o l’output del sistema. L’elemento determinante non è che l’istruzione sia evidente per una persona. È sufficiente che il contenuto venga acquisito e interpretato dal modello.
Che cos’è una prompt injection
Una prompt injection consiste nell’inserimento, nell’input o nei contenuti elaborati, di istruzioni capaci di modificare, deviare o condizionare il comportamento previsto di un sistema di intelligenza artificiale.
Non ogni frase formulata all’imperativo costituisce una prompt injection. Un documento può contenere legittimamente ordini, clausole, domande, esempi di prompt o conversazioni riportate. Il fenomeno assume rilievo tecnico quando quel contenuto interferisce con il compito assegnato al sistema o tenta di orientarlo verso un comportamento diverso.
L’effetto dipende dall’intera applicazione. Contano il modello utilizzato, la struttura delle istruzioni, il modo in cui vengono acquisiti i documenti, i controlli predisposti, i permessi attribuiti e gli eventuali strumenti ai quali il sistema può accedere. La stessa sequenza può essere innocua in un ambiente e produrre conseguenze in un altro.
È quindi più corretto considerare la prompt injection come un problema del sistema complessivo e non soltanto del modello. L’applicazione deve organizzare istruzioni, dati, fonti e autorizzazioni in modo da ridurre il rischio che un contenuto non affidabile assuma un ruolo che non dovrebbe avere.
Perché dati e istruzioni possono confondersi
Quando interagiamo con un chatbot vediamo soprattutto il messaggio che scriviamo. Dietro quella richiesta possono però esistere altre istruzioni predisposte dal fornitore o dallo sviluppatore. Queste indicano al sistema il ruolo da svolgere, i limiti da rispettare, il formato della risposta e le operazioni consentite.
A tali istruzioni si aggiungono la domanda dell’utente e i contenuti necessari per rispondere. Se il sistema deve esaminare un contratto, una relazione o un altro documento, anche quel testo entra nel contesto. Il modello riceve dunque una combinazione di elementi che svolgono funzioni differenti.
Per un programma tradizionale, un dato e un comando possono essere rappresentati mediante strutture nettamente separate. In un sistema generativo, invece, entrambi possono essere espressi attraverso il linguaggio naturale. Una frase contenuta in un documento può avere la stessa forma linguistica di una frase rivolta direttamente al modello. Il sistema deve ricostruirne la funzione in base al contesto, alla provenienza e alle regole predisposte dall’applicazione.
La sicurezza dipende anche dalla capacità di mantenere una separazione tra le istruzioni affidabili e i contenuti che devono essere trattati come dati.
La prompt injection diretta
La prompt injection è diretta quando l’istruzione interferente viene inserita dall’utente nel messaggio rivolto al sistema. Il tentativo di modificarne il comportamento si trova nello stesso canale attraverso il quale viene assegnato il compito.
Non ogni cambiamento della richiesta è ostile. Un utente autorizzato può normalmente correggere il proprio prompt, aggiungere dettagli o chiedere un risultato diverso. Il problema emerge quando si tenta di superare le regole dell’applicazione, ottenere informazioni non accessibili o indurre il sistema a svolgere operazioni non consentite.
La prompt injection diretta è generalmente più riconoscibile, perché l’input proviene dalla persona che sta interagendo con il sistema. L’applicazione può analizzare quel messaggio, applicare controlli e limitare le operazioni disponibili. Ciò non elimina il rischio, ma rende più evidente la provenienza dell’istruzione.
La prompt injection indiretta
La prompt injection è indiretta quando l’istruzione non viene scritta direttamente dall’utente, ma arriva attraverso un contenuto che il sistema acquisisce per svolgere il proprio compito.
Può trovarsi in una pagina web, in un’e-mail, in un allegato, in un documento acquisito mediante riconoscimento ottico dei caratteri o in un testo recuperato da un archivio. L’utente può non conoscere la presenza dell’istruzione e può limitarsi a chiedere al sistema di analizzare il materiale ricevuto.
Questo rende il fenomeno particolarmente insidioso. Il contenuto esterno entra nel flusso di lavoro con l’apparenza di una fonte informativa, ma può includere una sequenza destinata a influenzare il modello. Il sistema potrebbe quindi allontanarsi dal compito originario, omettere alcuni elementi, alterare la sintesi o tentare di utilizzare strumenti che non sarebbero necessari.
La prompt injection indiretta mostra perché non sia sufficiente controllare soltanto ciò che scrive l’utente. Occorre considerare anche i materiali che il sistema recupera autonomamente o riceve da soggetti terzi.
- Compito legittimoL’utente assegna un’attività al sistema.
- Documento esternoIl sistema acquisisce contenuti da leggere o analizzare.
- Istruzione ostileIl contenuto può includere un tentativo di deviare il compito.
- Possibile deviazioneIl sistema può interpretare quella parte come istruzione.
- ControlloSeparare dati e istruzioni, limitare strumenti e verificare risultati e azioni.
Schema del rischio, non descrizione di un esito inevitabile.
Quando un documento diventa anche un’istruzione
Per una persona, un documento è normalmente un insieme di informazioni da leggere e interpretare. Per un sistema di intelligenza artificiale, lo stesso documento è una sequenza di testo inserita nel contesto. Alcune parti possono essere elaborate come informazioni, mentre altre possono assumere la forma di istruzioni.
Questo non significa che ogni documento debba essere considerato pericoloso. Significa che la sua funzione non dipende soltanto dal contenuto visibile e dall’intenzione dell’autore. Dipende anche dal modo in cui l’applicazione lo acquisisce, lo prepara e lo presenta al modello.
Un testo può essere chiaramente visibile, collocato in una parte marginale oppure reso poco percepibile per un lettore. Può emergere dall’OCR applicato a un’immagine o essere incorporato in contenuti recuperati da una fonte esterna. Dal punto di vista del modello, ciò che conta è che quella sequenza entri effettivamente nel materiale da elaborare.
La verifica non può quindi fermarsi all’apparenza grafica del documento. Deve riguardare l’intero processo con cui il contenuto viene estratto e trasferito nel contesto del sistema.
Perché il RAG amplia il problema
Un sistema RAG permette al modello di utilizzare fonti esterne. Prima di generare la risposta, l’applicazione ricerca i contenuti pertinenti in un archivio o in un insieme di documenti e inserisce nel contesto le parti considerate utili.
Questo meccanismo può migliorare l’affidabilità delle risposte, perché il modello non deve fare affidamento soltanto sulle informazioni apprese durante l’addestramento. Il RAG introduce però anche un nuovo passaggio. Il sistema deve poter confidare nel fatto che i contenuti recuperati siano pertinenti, integri e trattati come fonti informative.
Se un documento presente nell’archivio contiene un’istruzione interferente, il sistema può recuperarla insieme alle informazioni legittime. L’istruzione entra così nella context window senza essere stata scritta dall’utente nella conversazione corrente.
Il rischio non dimostra che il RAG sia insicuro. Mostra piuttosto che la qualità delle fonti non riguarda soltanto la correttezza delle informazioni. Occorre considerare anche provenienza, integrità, modalità di acquisizione e possibili contenuti capaci di condizionare il modello.
Perché gli agenti richiedono maggiore cautela
Un chatbot tradizionale riceve una richiesta e genera una risposta testuale. Un agente può disporre di capacità ulteriori. Può consultare archivi, leggere e modificare documenti, interrogare servizi, utilizzare applicazioni o attivare procedure.
Quando il sistema può compiere azioni, una deviazione dal compito originario non incide soltanto sul testo restituito. Può influire sulle operazioni che l’agente decide di eseguire o sugli strumenti che tenta di utilizzare.
Il rischio aumenta se l’agente dispone di autorizzazioni molto ampie, se può agire senza conferma o se non esistono registri sufficienti per ricostruire ciò che è accaduto. Un agente dovrebbe poter utilizzare soltanto gli strumenti necessari, entro limiti definiti e con un intervento umano nei passaggi più delicati.
La sicurezza non può essere affidata esclusivamente alla capacità del modello di riconoscere un’istruzione sospetta. Deve essere sostenuta dall’architettura dell’applicazione, dalla separazione degli ambienti, dai limiti alle autorizzazioni e dalla verifica delle operazioni.
La prompt injection non è un’allucinazione
Prompt injection e allucinazione possono entrambe produrre un risultato inattendibile, ma nascono da dinamiche diverse. Nell’allucinazione il modello genera un contenuto falso, inesatto o non sostenuto dalle fonti. Nella prompt injection un input o un contenuto interferisce con il compito e condiziona il comportamento del sistema.
Il jailbreak descrive più specificamente il tentativo di superare deliberatamente limiti o regole imposte al sistema. Il data poisoning agisce invece sui dati utilizzati durante l’addestramento o in altre fasi del ciclo di vita.
I fenomeni possono anche combinarsi. Un sistema deviato da un’istruzione esterna può produrre una risposta che contiene a sua volta informazioni inventate o inesatte. Mantenere distinte le diverse categorie aiuta a comprendere il problema e a scegliere le misure appropriate.
La verifica delle fonti è essenziale contro le allucinazioni, ma non basta da sola a impedire che un contenuto influenzi il comportamento di un agente. Allo stesso modo, filtrare alcune espressioni sospette non elimina il rischio se il sistema conserva permessi eccessivi.
Quali effetti può produrre
Una prompt injection può alterare la risposta, indurre il sistema a ignorare una parte del compito oppure orientarlo verso informazioni non pertinenti. In applicazioni più complesse può tentare di provocare la divulgazione di contenuti riservati, l’utilizzo improprio di strumenti o l’esecuzione di operazioni non necessarie.
Non tutti i tentativi riescono e non tutti producono conseguenze significative. L’effetto dipende dalle difese presenti, dall’affidabilità del modello, dalla struttura dell’applicazione e dalle autorizzazioni disponibili.
Non esiste una singola frase capace di manipolare indistintamente ogni sistema. Non esiste neppure una misura isolata che elimini completamente il rischio. La sicurezza deriva dalla combinazione di più controlli.
Come si riduce il rischio
Il primo principio consiste nel trattare i contenuti esterni come materiale non necessariamente affidabile. Un documento deve essere acquisito per il compito previsto senza potersi trasformare liberamente in una nuova fonte di istruzioni.
L’applicazione dovrebbe separare, per quanto possibile, le indicazioni autorizzate dai dati da analizzare. È utile verificare la provenienza dei contenuti, controllare i formati, limitare l’accesso alle fonti e individuare sequenze anomale. Questi controlli non sono infallibili, perché un’istruzione può essere formulata in molti modi diversi.
Un secondo livello riguarda i permessi. Anche quando il modello interpreta erroneamente un contenuto, le conseguenze possono essere contenute se il sistema non dispone di accessi non necessari. Un agente che può soltanto leggere un archivio presenta rischi diversi da uno che può modificare file, inviare comunicazioni o utilizzare servizi esterni.
Occorre poi controllare gli output e le azioni. Il risultato deve essere confrontato con il compito originario e con le fonti utilizzate. Le operazioni più delicate non dovrebbero essere eseguite automaticamente, ma sottoposte a un’autorizzazione umana effettiva.
Logging e tracciabilità aiutano a ricostruire quali contenuti siano stati acquisiti, quali strumenti siano stati utilizzati e in quale momento il comportamento abbia iniziato a deviare. La formazione consente infine agli utilizzatori di riconoscere segnali inattesi e di non considerare l’output affidabile soltanto perché appare coerente.
OWASP sottolinea che nessuna singola difesa offre una protezione completa. Il rischio richiede un approccio composto da separazione tra istruzioni e dati, controllo degli input e degli output, privilegi minimi e supervisione umana.
Perché riguarda chi lavora con documenti
Studi professionali, imprese e pubbliche amministrazioni utilizzano documenti provenienti da fonti diverse. Contratti, relazioni, e-mail, allegati e fascicoli possono essere analizzati mediante sistemi generativi, RAG o agenti.
In questi contesti non è sufficiente chiedersi se il documento contenga informazioni corrette. Occorre considerare anche come il sistema lo leggerà, quali parti entreranno nel contesto, quali strumenti saranno disponibili e quali controlli verranno applicati prima di utilizzare il risultato.
Il professionista mantiene un ruolo essenziale. Deve conoscere la provenienza del materiale, comprendere i limiti dello strumento e verificare che il risultato corrisponda al compito assegnato. Se il sistema ha accesso ad altre funzioni, deve controllare anche le operazioni che propone o tenta di eseguire.
La prompt injection ci costringe quindi ad abbandonare un’idea troppo semplice del documento digitale. Quando un contenuto viene elaborato dall’intelligenza artificiale, non è necessariamente soltanto qualcosa da leggere. Può diventare anche qualcosa che il sistema interpreta come un’istruzione.
Comprendere questa possibilità è il primo passo per utilizzare RAG, agenti e strumenti di analisi documentale con maggiore consapevolezza. Gli effetti giuridici dell’inserimento di istruzioni destinate a influenzare l’IA all’interno di un atto processuale richiedono invece un esame autonomo. Sono esaminati nell’approfondimento già disponibile: Prompt injection negli atti processuali: quando un documento tenta di impartire istruzioni all’IA.
Fonti tecniche
La ricostruzione è basata sulla documentazione OWASP LLM01 Prompt Injection, sulla OWASP LLM Prompt Injection Prevention Cheat Sheet e sul rapporto NIST AI 100-2e2025 Adversarial Machine Learning.