La prompt injection è un attacco che manipola chatbot e agenti AI con testo nascosto. Ecco come funziona, perché non si elimina e le regole per difenderti.
Un assistente AI che riassume una pagina web o compila un modulo al posto tuo, esegue istruzioni. Il punto debole è che non sempre distingue quello che gli dici tu dalle richieste nascoste nel contenuto che sta leggendo. Questo fenomeno è chiamato prompt injection, oggi in cima alla classifica dei rischi per le applicazioni basate su modelli linguistici.
Il termine ha iniziato a circolare a settembre 2022, sebbene il problema sia cambiato notevolmente. Quando i chatbot si limitavano a rispondere, il danno poteva essere una risposta sbagliata. Oggi invece un agente AI può navigare, scrivere ed eseguire azioni, dunque anche solo un errore può trasformarsi in un furto di dati o in un pagamento indesiderato.
In questa guida, vediamo nel dettaglio cos’è la prompt injection, perché nemmeno gli esperti pensano di poterla eliminare del tutto e cosa fare per ridurre i rischi, sia per i privati sia per le aziende.
Cos’è la prompt injection
La prompt injection è un attacco in cui un input altera il comportamento di un modello linguistico in modi non previsti. Il nome è stato reso popolare dallo sviluppatore Simon Willison, per analogia con la SQL injection.
Nella classifica OWASP sulle applicazioni LLM, la prompt injection è al primo posto per la seconda edizione consecutiva. Il vero rischio è che, per sferrare un attacco, non servono competenze di programmazione. Il linguaggio naturale è l’arma per poter potenzialmente truffare utenti e aziende.
Si distingue in due forme. Nella injection diretta è il prompt dell’utente a modificare il comportamento del modello. In quella indiretta, invece, le istruzioni arrivano da fonti esterne come siti web o file.
Possono essere invisibili all’occhio umano, per esempio testo bianco su sfondo bianco, ma il modello le legge comunque. Questa è di fatto la categoria più diffusa e più rilevante oggi.
È invece diverso il jailbreak, che punta a convincere il modello che le sue regole non valgano più, e le due tecniche spesso si sovrappongono.
Perché è così difficile da fermare
Nel dicembre 2025, il National Cyber Security Centre britannico (NCSC) ha avvisato che la prompt injection potrebbe non essere mai fermata come la SQL injection.
Nei modelli, non esiste una distinzione tra dati e istruzioni. Anche OpenAI l’ha paragonata a truffe e social engineering sul web, ritenendo improbabile che venga mai davvero risolta.
Secondo OWASP, nemmeno tecniche come RAG e fine-tuning la neutralizzano del tutto. Ecco perché, in questo caso, cambia proprio l’approccio generale. Ci sono meno illusioni di blocco totale, ma più attenzione alla riduzione dell’impatto e alla resilienza.
Alcuni casi reali
Per meglio capire il funzionamento della prompt injection, vediamo alcuni casi concreti. Un esempio emblematico è EchoLeak, ossia una falla di Microsoft 365 Copilot resa nota da Aim Security nel giugno 2025. In pratica, una sola email costruita seguendo alcune regole dava modo di sottrarre dati senza interazione della vittima.
Microsoft l’ha corretta con un aggiornamento nello stesso mese. Gli analisti l’hanno letta come il segnale di una nuova categoria di rischio, più che di un singolo bug.
Nel 2026, il fenomeno è uscito dai laboratori. In che senso? Zscaler ha individuato due campagne che usavano injection indirette in siti malevoli, in modo da indurre agenti AI a effettuare pagamenti o a fidarsi di piattaforme crypto fraudolente. Oggi CrowdStrike cataloga oltre 200 tecniche diverse.
Cosa dicono le normative attuali
Il 1° maggio 2026 le agenzie statunitensi CISA e NSA, insieme a quelle di Regno Unito, Australia, Canada e Nuova Zelanda hanno pubblicato la guida Careful Adoption of Agentic AI Services. Di cosa si tratta? Di un documento dove la prompt injection viene definita la minaccia più persistente e difficile da correggere per i sistemi agentici, aggiungendo che nessun singolo controllo può bastare.
In Italia, l’Agenzia per la cybersicurezza nazionale ha aderito alle linee guida internazionali per lo sviluppo sicuro dell’AI, pubblicate il 27 novembre 2023 ed è il CSIRT nazionale designato. Per i soggetti NIS2 (d. lgs. 138/2024) gli incidenti significativi richiedono un preallarme entro 24 ore dalla conoscenza dell’incidente.
Per ciò che riguarda l’AI Act, dal 2 agosto 2026 è nella fase generale di applicazione, ma il Regolamento UE 2026/1744 ha rinviato al 2 dicembre 2027 le norme sui sistemi ad alto rischio dell’Allegato III.
Alcuni falsi miti
Circolano alcune convinzioni sbagliate sulla prompt injection che è bene sfatare, anche per la tua sicurezza. In primis, non basta un filtro. L’NCSC ritiene destinate al fallimento tutte le strategie che vogliono rilevare i tentativi o addestrare i modelli a dare priorità alle istruzioni.
C’è chi pensa che sandbox e allow-list possano bastare. Sul tema è intervenuto un contributore OWASP a Infosecurity Europe 2026, spiegando che le allow-list possono persino agevolare l’attacco se i comandi necessari erano già approvati.
E per chi dice che il modello più recente dei principali chatbot può essere utile, in realtà non è così. La stessa OpenAI considera la prompt injection una sfida di sicurezza di lungo periodo.
Come difendersi per aziende e sviluppatori
Cosa possono fare aziende e sviluppatori per difendersi? Senza una patch definitiva da parte dei fornitori di AI, la difesa può considerarsi “architetturale”. In che senso? Si presume che l’attacco possa riuscire e si limita ciò che l’agente può fare.
Evita per prima cosa che uno stesso agente riunisca accesso a dati privati, esposizione a contenuti non fidati e capacità di comunicare verso le stesso, poiché si tratta della combinazione sfruttabile dalla prompt injection. C’è la famosa “Rule of Two” di Meta in questo senso, che chiede di non superare due proprietà su tre per sessione.
Importante poi assegnare solo i permessi indispensabili ai chatbot che usi, richiedendo l’approvazione di una persona per la terza capacità. L’output va trattato come non fidato, separando i contenuti esterni dalle istruzioni.
Non bisogna nemmeno affidarsi alle blacklist. L’NCSC sconsiglia di bloccare frasi specifiche, perché l’attaccante può riformularle. Infine, puoi come sviluppatore simulare attacchi con payload di prova, visto che il tema è ancora poco conosciuto.
Come difendersi per utenti comuni
Le stesse regole valgono anche per chi usa l’AI ogni giorno. Concedere all’agente AI solo gli accessi necessari può aiutare, così come usare l’AI senza effettuare il login. Quest’ultimo è il consiglio che OpenAI ha dato per il proprio browser con agente, insieme a quello di leggere con attenzione ogni richiesta di conferma.
Controlla poi a mano pagamenti e invii, diffida dei documenti e delle pagine di provenienza incerta che chiedi a un assistente con accesso a email e file da analizzare. Infine tieni sempre aggiornati app e browser, molte falle vengono infatti corrette dai fornitori.
