Prompt injection: come proteggere chatbot e agenti AI (OWASP Top 10 LLM)

La prompt injection è un attacco in cui qualcuno inserisce istruzioni malevole nel testo che un modello linguistico legge, per fargli fare qualcosa che non dovrebbe: rivelare informazioni riservate, ignorare le regole, usare uno strumento in modo dannoso. Funziona perché per un modello istruzioni e dati sono lo stesso testo: non esiste una separazione rigida tra “quello che deve fare” e “quello che sta leggendo”. È il primo rischio della OWASP Top 10 per le applicazioni basate su LLM.

Prompt injection diretta e indiretta

• Diretta: l’attaccante scrive le istruzioni nella chat. Per esempio chiede al chatbot del sito di “ignorare le regole precedenti” e mostrare il prompt di sistema o un codice sconto riservato.
• Indiretta: le istruzioni arrivano da un contenuto che l’agente legge durante il lavoro. Un’email con testo nascosto, una pagina web, un PDF caricato da un cliente, un ticket, una recensione. L’utente legittimo non vede nulla di strano, ma l’agente esegue.

La forma indiretta è la più pericolosa perché colpisce proprio gli agenti più utili: quelli che leggono la posta, navigano, consultano documenti e possono agire.

Perché è il rischio numero uno: la OWASP Top 10 per gli LLM

L’edizione 2025 della OWASP Top 10 per le applicazioni LLM elenca i dieci rischi principali. Molti sono collegati tra loro:

Codice	Rischio	In pratica
LLM01	Prompt injection	Istruzioni malevole nel testo cambiano il comportamento del modello
LLM02	Divulgazione di informazioni sensibili	Il modello rivela dati personali, segreti o informazioni riservate
LLM03	Supply chain	Modelli, librerie o dati di terze parti compromessi
LLM04	Avvelenamento di dati e modelli	Dati di addestramento o di contesto manipolati
LLM05	Gestione impropria dell’output	L’output del modello viene usato senza controlli, per esempio in una query o in una pagina web
LLM06	Autonomia eccessiva	L’agente ha più permessi o strumenti del necessario
LLM07	Esposizione del prompt di sistema	Istruzioni interne e segreti scritti nel prompt finiscono all’esterno
LLM08	Debolezze di vettori ed embedding	Accessi non controllati alle basi di conoscenza usate per il RAG
LLM09	Disinformazione	Risposte false presentate come vere
LLM10	Consumo illimitato	Richieste che fanno esplodere costi o carico

La prompt injection è spesso la porta d’ingresso; l’autonomia eccessiva (LLM06) e la gestione impropria dell’output (LLM05) determinano quanto danno può fare.

Quattro scenari concreti

1. L’assistente email. Un agente riassume la posta e può rispondere. Un’email in arrivo contiene, in bianco su bianco, l’istruzione di inoltrare le ultime fatture a un indirizzo esterno. Se l’agente ha il permesso di inviare email senza conferma, lo fa.
2. Il chatbot sul sito. Un utente convince il chatbot a mostrare il prompt di sistema, dove qualcuno aveva scritto una chiave API “per comodità”.
3. L’agente con accesso al CRM. Una richiesta ben costruita porta l’agente a estrarre l’elenco completo dei clienti invece della sola scheda richiesta.
4. La base di conoscenza avvelenata. Un documento caricato in un sistema RAG contiene istruzioni che, quando viene recuperato, cambiano le risposte date a tutti gli utenti.

Le difese che funzionano

Non esiste un filtro che blocchi tutte le prompt injection. La protezione efficace è a strati e sta soprattutto fuori dal modello.

1. Permessi minimi sugli strumenti

L’agente deve poter fare solo ciò che serve al compito, con i permessi dell’utente per cui sta lavorando. Nei sistemi che progettiamo, gli strumenti a disposizione dell’agente dipendono dal ruolo e il controllo avviene a ogni chiamata. Se un agente non può esportare l’elenco clienti, nessuna istruzione nascosta potrà fargliela esportare.

2. Conferma umana per le azioni a rischio

Pagamenti, invii a destinatari esterni, cancellazioni e modifiche massive devono passare da una conferma esplicita. L’agente prepara, la persona approva.

3. Separare istruzioni e dati

Il contenuto esterno va passato al modello delimitato e marcato come dato non fidato. Non basta da solo, ma riduce molto gli attacchi più banali e rende più facili i controlli.

4. Controllare ciò che esce

Molti attacchi puntano a far uscire dati: link verso domini esterni, immagini che caricano un indirizzo con i dati nella query, chiamate API. Conviene ammettere solo domini noti, validare l’output prima di usarlo in altri sistemi e non eseguire mai codice o query generati senza controllo.

5. Nessun segreto nel prompt

Chiavi, password e regole riservate non vanno scritte nel prompt di sistema: prima o poi qualcuno riesce a farlo ripetere. I segreti stanno nei sistemi che l’agente chiama, protetti dai loro controlli di accesso.

6. Limiti, registri e allarmi

Limiti di uso per utente, registro di ogni azione e allarmi sui comportamenti anomali permettono di accorgersi di un attacco e di limitarne i danni, anche economici.

7. Red teaming prima e dopo

Un assistente AI va attaccato di proposito da qualcuno che conosce le tecniche, prima di andare online e dopo ogni cambiamento di modello, prompt o strumenti.

Come testiamo un assistente AI

Nei nostri test di sicurezza dei sistemi AI seguiamo una sequenza precisa:

1. Modello delle minacce: cosa può fare l’assistente, quali dati vede, chi può scrivergli, da quali fonti legge.
2. Attacchi diretti: tentativi di aggirare le regole, ottenere il prompt di sistema, far dire o fare cose non previste.
3. Attacchi indiretti: documenti, email e pagine preparate con istruzioni nascoste, inseriti nei canali che l’agente legge.
4. Esfiltrazione e abuso degli strumenti: tentativi di far uscire dati o di usare gli strumenti oltre il loro scopo.
5. Report: ogni vulnerabilità con gravità, prove, impatto e correzione consigliata, poi un nuovo test dopo le correzioni.

Checklist rapida

• L’agente ha solo gli strumenti e i dati indispensabili al compito?
• I permessi seguono il ruolo dell’utente e sono verificati a ogni chiamata?
• Le azioni irreversibili richiedono una conferma umana?
• Nel prompt di sistema non ci sono segreti né informazioni riservate?
• I contenuti esterni sono trattati come dati non fidati?
• L’output è validato prima di finire in altri sistemi o in una pagina web?
• I link e le immagini verso domini esterni sono limitati?
• Ci sono limiti di uso e allarmi sui comportamenti anomali?
• Ogni azione dell’agente è registrata?
• È stato fatto un red teaming prima del rilascio?

Se stai portando un chatbot o un agente AI in produzione, possiamo testarlo prima che lo faccia qualcun altro.