Una semplice istruzione nascosta in una pagina web, in un PDF o in un’email può influenzare un agente AI e le azioni che esegue. Il pericolo cresce con l’accesso a dati e servizi, mentre pratiche di minimo privilegio, controlli sui tool e supervisione umana riducono l’impatto.
Da chatbot a agente operativo
Un dipendente chiede al proprio assistente aziendale di controllare le email ricevute durante la mattinata, individuare quelle più urgenti e preparare una sintesi. È uno scenario sempre meno futuristico: gli strumenti di intelligenza artificiale stanno progressivamente uscendo dalla semplice finestra di chat e vengono collegati a posta elettronica, documenti, repository, browser, database e servizi esterni.
Tra le email analizzate, però, ce n’è una che contiene istruzioni pensate non per la persona che la riceve, ma per il sistema AI che potrebbe leggerla. Il dipendente non ha dato alcun comando particolare; è il modello ad averlo trovato nel contenuto che stava elaborando.
È in situazioni di questo tipo che la prompt injection smette di sembrare un curioso limite dei chatbot e comincia a diventare un vero problema di sicurezza informatica.
Perché il rischio aumenta con gli agenti
Finché un modello si limita a ricevere una domanda e produrre una risposta, anche un comportamento anomalo tende a rimanere confinato alla conversazione: una risposta sbagliata, un contenuto indesiderato, magari la divulgazione di informazioni presenti nel contesto. Quando però lo stesso modello ha accesso a strumenti e sistemi esterni, il problema cambia scala. Può leggere file, interrogare servizi, usare API, preparare email, modificare informazioni o avviare azioni.
A quel punto non basta più chiedersi se un modello possa essere convinto a dire qualcosa che non dovrebbe. Bisogna chiedersi cosa succede quando può essere convinto a fare qualcosa che non dovrebbe.
Come funziona la prompt injection
Una parte del problema nasce dal modo stesso in cui funzionano i modelli linguistici. Nel software tradizionale siamo abituati a distinguere abbastanza chiaramente codice e dati. Il programma esegue istruzioni definite dallo sviluppatore e tratta gli input come informazioni da elaborare.
Con un Large Language Model (LLM) questa separazione è molto meno intuitiva. Nel contesto del modello possono finire contemporaneamente le istruzioni definite dall’applicazione, la richiesta dell’utente, la cronologia della conversazione, documenti recuperati da un sistema RAG, pagine web, email, risultati restituiti da API o output prodotti da altri strumenti.
Per noi questi elementi non hanno lo stesso peso. Una direttiva interna dell’applicazione non dovrebbe valere quanto una frase trovata dentro un documento. Una mail ricevuta da un mittente sconosciuto non dovrebbe avere la stessa autorevolezza delle istruzioni impartite allo strumento da chi lo ha progettato. Per il modello, però, tutto questo diventa semplicemente linguaggio da interpretare.
Ed è proprio qui che nasce una parte importante del rischio: contenuti che dovrebbero essere semplicemente letti possono cercare di comportarsi come istruzioni.
Classificazione OWASP
OWASP colloca infatti la prompt injection al primo posto nella propria Top 10 2025 dedicata alle applicazioni basate su modelli linguistici. Il rischio non riguarda soltanto input esplicitamente malevoli inseriti dall’utente, ma più in generale la possibilità che un contenuto alteri il comportamento previsto del sistema.
- Prompt injection diretta: l’attaccante interagisce con il modello e tenta di farlo ignorare le istruzioni precedenti, rivelare informazioni riservate o superare limiti di sicurezza.
- Prompt injection indiretta: le istruzioni malevole sono nascoste in una fonte esterna (pagina web, PDF, email, documento condiviso, ticket, README) che il modello consulta successivamente.
La forma più semplice è quella diretta. L’utente parla con il modello e prova a convincerlo a ignorare le istruzioni precedenti, cambiare comportamento, rivelare informazioni o superare determinati limiti. È il caso delle formule ormai note del tipo “ignora tutte le istruzioni precedenti”. In questi casi il tentativo di manipolazione è evidente: l’attaccante sta interagendo direttamente con il sistema.
La situazione diventa più interessante quando l’attaccante non parla affatto con l’AI. Nella prompt injection indiretta le istruzioni vengono inserite all’interno di una fonte esterna che il modello potrebbe consultare successivamente. Può essere una pagina web, un PDF, un’email, un documento condiviso, un ticket di assistenza, un README o qualsiasi altro contenuto destinato a entrare nel contesto del sistema.
Perché le fonti apparentemente innocue sono pericolose
L’AI recupera quella fonte per svolgere un compito del tutto legittimo e, insieme alle informazioni utili, riceve anche il testo predisposto dall’attaccante. Nella prompt injection diretta l’attaccante deve interagire con il sistema. In quella indiretta può limitarsi a lasciare un contenuto in un luogo che il sistema potrebbe visitare in futuro.
Questo rende il problema particolarmente rilevante per tutti gli strumenti che lavorano in autonomia con dati esterni. Un agente incaricato di fare ricerche online, per esempio, può trovarsi a leggere pagine completamente fuori dal controllo dell’organizzazione che lo utilizza. Lo stesso vale per un assistente che analizza posta elettronica, repository o documentazione caricata dagli utenti.
Nel caso della prompt injection non è necessario nulla di malevolo a livello di file: macro, script, exploit o allegati eseguibili. Un documento può essere perfettamente innocuo per il sistema operativo e allo stesso tempo essere problematico per il modello che lo legge. Può trattarsi di un PDF normale, di un file di testo o di una pagina HTML senza codice dannoso.
Il bersaglio non è necessariamente il software che apre il documento, ma il sistema che ne interpreta il contenuto.
Esempio pratico di RAG aziendale
Immaginiamo un’applicazione RAG (Retrieval‑Augmented Generation) utilizzata all’interno di un’azienda. Un dipendente pone una domanda, il sistema cerca i documenti più rilevanti, ne recupera alcuni passaggi e li inserisce nel contesto del modello affinché possa formulare una risposta.
Se uno dei documenti contiene istruzioni rivolte al modello, quel documento smette di essere soltanto una fonte di informazioni. Diventa anche un possibile tentativo di influenzare il comportamento del sistema. Il retrieval, quindi, non rende automaticamente affidabile ciò che viene recuperato: aumenta le informazioni a disposizione del modello, ma introduce anche nuovi contenuti che devono essere considerati potenzialmente non attendibili.
Agenti con tool: il salto di scala
La questione diventa molto più seria con gli agenti. Un chatbot che genera soltanto testo ha un impatto relativamente limitato. Un agente, invece, può disporre di strumenti: leggere una casella email, interrogare un database, accedere a un repository, consultare un CRM, navigare sul web o utilizzare API. In alcuni sistemi può anche modificare dati, inviare messaggi o avviare procedure.
A quel punto una prompt injection non cerca più soltanto di modificare la risposta prodotta dal modello. Può cercare di influenzare il modo in cui vengono usati gli strumenti.
Il rischio dipende quindi anche dai privilegi concessi all’agente. Un modello isolato può essere manipolato, ma ha poche possibilità operative. Un agente che può leggere documenti riservati, comunicare all’esterno e usare servizi aziendali si trova in una situazione completamente diversa.
Il NIST ha utilizzato il termine “agent hijacking” per descrivere scenari in cui contenuti controllati da un attaccante riescono a deviare il comportamento di un agente verso obiettivi non previsti. Non è difficile capire perché questo passaggio sia importante: se il modello sbaglia una risposta, abbiamo un problema di affidabilità; se utilizza male un permesso, abbiamo anche un problema di sicurezza.
Privilegi combinati
Un altro elemento spesso sottovalutato è la combinazione dei privilegi. Un agente può avere accesso in lettura ai documenti interni. Separatamente può avere accesso a Internet. Presi singolarmente, sono due permessi legittimi. Insieme, creano una nuova possibilità: leggere un’informazione dall’interno e trasmetterla verso l’esterno.
Lo stesso vale per altre combinazioni: accesso a un repository e possibilità di eseguire codice; lettura della posta e capacità di inviare messaggi; accesso a un database e possibilità di chiamare servizi esterni. Ogni combinazione amplifica la superficie di attacco.
Strategie di mitigazione
Per ridurre il rischio di prompt injection è necessario adottare un approccio multilivello:
- Minimo privilegio: concedere agli agenti solo i permessi strettamente necessari per il compito specifico.
- Sanitizzazione dei contenuti: filtrare o rimuovere istruzioni potenzialmente malevole da documenti, email e pagine web prima di inserirle nel contesto del modello.
- Separazione dei canali di input: distinguere chiaramente tra istruzioni interne dell’applicazione e contenuti esterni provenienti da fonti non controllate.
- Supervisione umana: richiedere revisione manuale per azioni critiche, specialmente quando il modello deve inviare messaggi, modificare dati o eseguire script.
- Audit e logging: registrare tutte le interazioni dell’agente con strumenti esterni e analizzare i log per individuare pattern sospetti.
- Modelli di difesa a più strati: combinare filtri basati su regole, analisi del contesto e modelli di rilevamento delle anomalie per identificare tentativi di injection.
In aggiunta, è consigliabile implementare test di sicurezza specifici per i sistemi RAG, includendo scenari di prompt injection sia diretta che indiretta, e valutare periodicamente la robustezza dei controlli di accesso.
Il ruolo della community e delle linee guida
Organizzazioni come OWASP, NIST e la OpenAI Community stanno pubblicando linee guida e best practice per la progettazione sicura di agenti basati su LLM. Queste includono raccomandazioni su:
- l’uso di “system prompts” immutabili e separati dai dati utente,
- l’applicazione di “guardrails” per limitare le azioni eseguibili,
- l’adozione di sandbox isolate per operazioni ad alto rischio.
Seguire queste indicazioni aiuta a costruire una difesa più resiliente contro le tecniche di prompt injection emergenti.
Conclusioni
La prompt injection non è più un mero problema teorico di chatbot; è una minaccia reale per gli agenti AI che operano con privilegi e accesso a risorse aziendali. La capacità di un modello di interpretare qualsiasi testo lo rende vulnerabile a contenuti che si mascherano da informazioni innocue ma che, in realtà, contengono istruzioni malevole.
Affrontare questo rischio richiede una combinazione di progettazione prudente, controlli di accesso rigorosi, supervisione umana e monitoraggio continuo. Solo con un approccio olistico è possibile sfruttare il potenziale degli agenti AI senza compromettere la sicurezza delle informazioni e dei sistemi aziendali.