Prompt injection: cos’è e come proteggere il vostro chatbot

Sempre più aziende integrano un modello linguistico nei propri servizi: un chatbot per i clienti, un assistente interno che risponde sui documenti aziendali, un agente che apre ticket o compila ordini. Insieme alle opportunità arriva una vulnerabilità nuova, che la OWASP mette al primo posto nella sua Top 10 per le applicazioni LLM: la prompt injection.

Cos’è la prompt injection

Un modello linguistico riceve insieme le istruzioni dello sviluppatore (il prompt di sistema) e i testi da elaborare (le domande dell’utente, i documenti, le pagine web). Non ha un modo affidabile per distinguere le une dagli altri. La prompt injection sfrutta proprio questo: un testo costruito per essere interpretato come istruzione anziché come dato, che fa ignorare al modello le regole previste.

È l’equivalente, per i modelli linguistici, della SQL injection per i database. Con una differenza: non esiste ancora una soluzione definitiva.

Diretta e indiretta

Prompt injection diretta

È l’utente stesso a scrivere il messaggio malevolo: chiede al chatbot di dimenticare le istruzioni, di rivelare il prompt di sistema, di comportarsi in un altro modo. È la forma più nota e, spesso, la meno pericolosa.

Prompt injection indiretta

Le istruzioni sono nascoste nei contenuti che il modello legge: un documento caricato, un’email, una pagina web, un campo di un database. Chi usa l’applicazione non vede nulla, ma il modello esegue. È la forma più insidiosa, perché l’attaccante non ha bisogno di accedere all’applicazione: gli basta far arrivare un testo dove il modello lo leggerà.

Perché è pericolosa

Il danno dipende da cosa il modello può vedere e fare:

• Fuga di dati: il modello rivela informazioni presenti nel contesto, documenti di altri utenti, il prompt di sistema con dettagli interni.
• Azioni non autorizzate: se il modello può chiamare strumenti (inviare email, modificare record, eseguire ordini), un input malevolo può fargliele eseguire.
• Esfiltrazione silenziosa: il modello viene indotto a inserire dati in un link o in un’immagine che, una volta visualizzati, li inviano all’attaccante.
• Danni alla reputazione: risposte offensive, false o compromettenti a nome dell’azienda.

Le contromisure che funzionano

Non esiste un filtro che blocchi tutte le prompt injection. La protezione efficace è architetturale:

• Minimo privilegio: il modello deve poter vedere e fare solo ciò che serve. Ogni strumento affidato va trattato come un permesso.
• Permessi applicati fuori dal modello: chi può leggere quali documenti lo decide il codice, non il prompt. Nei sistemi RAG il filtro per utente va fatto prima di passare i documenti al modello.
• Conferma umana per le azioni rilevanti: pagamenti, invii, cancellazioni non devono partire solo perché il modello lo ha deciso.
• Output trattati come input non fidati: ciò che il modello restituisce va validato prima di finire in una pagina web, una query o un comando.
• Separazione dei contenuti: i testi esterni vanno marcati come dati e mai concatenati alle istruzioni senza controllo.
• Monitoraggio e limiti: registrare le interazioni, limitare le richieste, accorgersi di comportamenti anomali.

Usare un provider affidabile non basta

OpenAI, Anthropic, Google e gli altri provider proteggono il modello, ma non possono proteggere la vostra applicazione: prompt di sistema, dati passati al modello, strumenti collegati e controlli sugli output sono responsabilità di chi costruisce il servizio. È lì che si trovano le vulnerabilità.

Come si verifica

Il modo più affidabile è un test di sicurezza specifico, che unisca le tecniche della OWASP Top 10 for LLM Applications al classico web application penetration test, perché un chatbot è prima di tutto un’applicazione web. Lo descriviamo nella pagina penetration test di applicazioni AI, chatbot e LLM. Se l’applicazione è stata anche sviluppata con l’aiuto dell’AI, vale la pena leggere i rischi del vibe coding.