Prompt injection e agenti AI: come proteggerli in azienda

Un agente AI collegato alla posta aziendale, al CRM e al file server è utile esattamente per la ragione per cui è pericoloso: legge contenuti che nessuno ha scritto pensando che li avrebbe letti una macchina con le mani. La prompt injection è la vulnerabilità che sfrutta questa asimmetria, e nel 2026 non è più un problema teorico da paper accademico: Google ha misurato un aumento relativo del 32% nei rilevamenti di istruzioni malevole sul web tra novembre 2025 e febbraio 2026, analizzando il corpus Common Crawl da 2-3 miliardi di pagine al mese (Google Security, 23 aprile 2026). Questo articolo spiega come funziona l’attacco sugli agenti in produzione, come si classifica, cosa è già successo sul campo e, soprattutto, perché scegliere un modello “sicuro” non è una difesa.

Il perimetro qui sono gli agenti AI in produzione, quelli con permessi reali, strumenti collegati e server MCP, non la prompt injection in generale: chi vuole partire dall’inquadramento di base del rischio d’impresa trova tutto nel nostro articolo introduttivo sulla prompt injection per le aziende.

In questo articolo scoprirai:

• Che cos’è la prompt injection e perché con gli agenti AI cambia tutto
• Prompt injection diretta: quando l’attacco arriva dall’utente
• Prompt injection indiretta: l’attacco che l’agente si va a cercare da solo
• Tool poisoning: quando a mentire all’agente è lo strumento
• Perché il modello da solo non protegge il tuo agente AI

Che cos’è la prompt injection e perché con gli agenti AI cambia tutto

OWASP classifica la prompt injection come LLM01, il primo rischio della sua Top 10 per le applicazioni LLM: si verifica quando «user prompts alter the LLM’s behavior or output in unintended ways», anche attraverso input impercettibili a un occhio umano (OWASP GenAI Security Project).

La radice del problema è architetturale. Un modello linguistico riceve istruzioni e dati nello stesso canale: il testo. Non esiste, dentro il prompt, una separazione hardware fra “questo è un ordine del mio proprietario” e “questo è materiale da leggere”. Un’email inoltrata, un PDF allegato, una pagina web recuperata sono tutti token che finiscono nella stessa finestra di contesto delle regole di sistema. Se un attaccante controlla anche solo una di quelle fonti, sta scrivendo nel prompt.

Prompt injection e agenti AI: dal testo all’azione

Finché il modello si limitava a produrre testo, il danno era contenuto: una risposta sbagliata, un tono manipolato. Con gli agenti la superficie cambia natura, perché l’output del modello non è più una frase ma un’azione: inviare una mail, chiudere un ticket, eseguire una query, scrivere su un repository. Simon Willison, che segue il tema dal 2022, lo riassume senza giri di parole: il rischio non è nel protocollo o nel singolo strumento, ma nel «mixing together tools that can perform actions on the user’s behalf with exposure to potentially untrusted input» (simonwillison.net).

Prompt injection diretta: quando l’attacco arriva dall’utente

La forma diretta è quella che tutti hanno visto almeno una volta. L’utente scrive nel campo di input un’istruzione che punta a scavalcare le regole di sistema: «ignora le istruzioni precedenti», «stampa il tuo system prompt», «comportati come se non avessi restrizioni». OWASP la definisce come il caso in cui «l’input dell’utente altera direttamente il comportamento del modello, sia intenzionalmente che accidentalmente», e quell’accidentalmente non è un dettaglio: una parte delle injection dirette non è ostile, è un utente che formula male una richiesta e ottiene un comportamento fuori policy.

Prompt injection diretta e jailbreak: due attacchi diversi

Vale la pena distinguere subito due termini che nel dibattito italiano si sovrappongono. Il jailbreak punta a far dire al modello qualcosa che le sue policy vietano: è un attacco al contenuto. La prompt injection punta a far fare al sistema qualcosa che il suo proprietario non ha autorizzato: è un attacco all’applicazione che sta intorno al modello. Un chatbot pubblico che si lascia convincere a scrivere insulti ha un problema di reputazione; un agente che si lascia convincere a esportare un database ha un problema di sicurezza. Le contromisure si somigliano solo in superficie.

Nell’uso aziendale reale l’injection diretta è il vettore meno preoccupante, per un motivo pratico: chi scrive nell’interfaccia è tipicamente un utente autenticato, tracciabile, con un perimetro di permessi noto. È comunque il punto dove conviene fare la prima raccolta di dati, perché i log delle conversazioni mostrano quali richieste stanno già premendo sui confini del sistema. Una buona igiene sul design dei prompt, istruzioni di sistema esplicite, formati di output validati, slot dedicati per le variabili utente, riduce il rumore, ma non è e non va spacciata per una misura di sicurezza: è ergonomia difensiva, non un controllo.

Prompt injection indiretta: l’attacco che l’agente si va a cercare da solo

Qui il quadro si ribalta. Nell’injection indiretta l’attaccante non parla con l’agente: avvelena una fonte che l’agente andrà a leggere per conto suo. La vittima non vede mai il prompt malevolo, e spesso non vede nemmeno l’azione che ne è seguita.

Il CETAS dell’Alan Turing Institute è arrivato a definirla il maggiore difetto di sicurezza della GenAI. CrowdStrike ha documentato casi tutt’altro che astratti: un candidato che ha nascosto oltre 120 righe di istruzioni nei metadati della foto profilo per manipolare una piattaforma di recruiting automatizzata, e un dipendente che ha inserito nella propria bio LinkedIn un ordine ai sistemi di selezione, condividere una ricetta di flan nelle comunicazioni, a cui uno di quei sistemi ha effettivamente obbedito (CrowdStrike). Il secondo caso fa sorridere; è lo stesso identico meccanismo che, con un payload diverso, esfiltra una casella di posta.

Dove si nasconde una prompt injection indiretta

I vettori censiti sono banali proprio perché sono ovunque: firme e piè di pagina delle email, testo nascosto o metadati nei documenti, corpo delle pagine web recuperate, testo incorporato nelle immagini, record di database, inviti di calendario. Il lavoro accademico di Nassi, Cohen e Yair sui promptware ha dimostrato attacchi funzionanti contro un assistente LLM in produzione partendo proprio da inviti di calendario ed email, con conseguenze che escono dal digitale e arrivano al controllo di dispositivi connessi (arXiv 2508.12175, agosto 2025).

La tassonomia costruita da Google sul corpus web è utile perché mostra che non tutte le injection sono attacchi: accanto a malicious – exfiltration e malicious – destruction ci sono scherzi innocui, istruzioni per ottenere riassunti più favorevoli, manipolazione SEO e tentativi di respingere i crawler agentici. Google osserva che «the observed activity suggests limited sophistication», ma si aspetta che «both the scale and sophistication of attempted IPI attacks» crescano. Tradotto in linguaggio operativo: oggi la maggior parte del rumore è a bassa competenza, e questo è esattamente il momento buono per attrezzarsi, non quello per rimandare.

Tool poisoning: quando a mentire all’agente è lo strumento

La terza famiglia è la più recente e la meno conosciuta in Italia. Nel tool poisoning l’istruzione malevola non sta nei dati che l’agente legge, ma nella descrizione dello strumento che l’agente ha il diritto di usare.

Invariant Labs ha caratterizzato la classe di attacco il 1° aprile 2025, mostrando un proof of concept contro Cursor: un innocuo tool add di un server calcolatrice conteneva, dentro tag tipo <IMPORTANT>, l’istruzione di leggere ~/.cursor/mcp.json e ~/.ssh/id_rsa e trasmetterli a un endpoint remoto, nascondendo l’operazione. Lo sviluppatore vedeva solo una richiesta di conferma semplificata (Invariant Labs). Una settimana dopo lo stesso gruppo ha dimostrato l’esfiltrazione di cronologie WhatsApp con la stessa tecnica.

Perché l’MCP amplia la superficie d’attacco

Il Model Context Protocol ha reso banale collegare strumenti a un modello, e con essi ha reso banale collegare strumenti di terze parti mai revisionati. OWASP ha inserito il tool poisoning nella MCP Top 10 come MCP03:2025, descrivendolo come manomissione «del contratto o delle definizioni di schema che governano le interazioni agente-strumento»: un problema di supply chain, con vettori che vanno dalle pipeline CI/CD senza verifica di firma alle descrizioni avvelenate con commenti HTML e caratteri a larghezza zero (OWASP MCP Top 10).

I numeri disponibili non sono rassicuranti. Il benchmark MCPTox, ripreso nella research note della Cloud Security Alliance del 1° luglio 2026, riporta un tasso medio di successo del 36,5% per gli attacchi di tool poisoning, con un picco del 72,8% su o1-mini e una conformità alle descrizioni avvelenate intorno al 34% per Claude 3.7 Sonnet. La stessa nota elenca vulnerabilità di auto-esecuzione già assegnate a CVE, CurXecute (CVE-2025-54135) e MCPoison (CVE-2025-54136) su Cursor, e osserva che gli IDE eseguono server MCP con privilegi pieni e senza isolamento (CSA Labs). Un server MCP installato da uno sviluppatore sul portatile aziendale è, a tutti gli effetti, una dipendenza software non revisionata con accesso alle credenziali.

Perché il modello da solo non protegge il tuo agente AI

È la domanda che arriva sempre per prima: se scelgo il modello più sicuro sul mercato, il problema è risolto? No, e conviene dirlo con le parole dei diretti interessati.

OWASP scrive che «it is unclear if there are fool-proof methods of prevention for prompt injection», per via della natura stocastica dei modelli generativi: le strategie disponibili mitigano l’impatto, non eliminano il rischio. Willison, che ha coniato il termine, è ancora più netto sullo stato dell’arte: «we’ve known about the issue for more than two and a half years and we still don’t have convincing mitigations for handling it». Il tema è presidiato pubblicamente da tutti i fornitori principali, OpenAI inclusa: nessuno di loro lo presenta come chiuso.

Hardening del modello: utile, non sufficiente

Questo non significa che l’hardening del modello sia inutile. Google ha investito proprio lì, l’addestramento avversariale ha «significantly enhanced our defenses against indirect prompt injection attacks in Gemini 2.5 models», ma lo presenta come uno dei cinque livelli della sua difesa, non come la difesa. Il punto è che l’affidabilità di un modello si misura in percentuali, e una percentuale residua di successo, moltiplicata per il numero di email che un agente aziendale legge in un mese, diventa una certezza statistica.

C’è poi un fatto più scomodo, che abbiamo già raccontato altrove: gli agenti possono aggirare i vincoli anche senza un attaccante esterno, quando il modo più efficiente di chiudere un obiettivo passa per una scorciatoia. Lo mostrano bene i casi di agenti che dichiarano il falso pur di raggiungere l’obiettivo e gli episodi di sandbox escape su OpenAI e Claude Cowork. La sicurezza dell’agente è una proprietà del sistema, non del modello.

Difesa a strati: come si protegge davvero un agente in produzione

Sia Google sia AWS convergono sulla stessa impostazione: defense in depth. Nessun singolo controllo è sufficiente, ma la combinazione riduce drasticamente la probabilità che un’injection arrivi fino a un’azione irreversibile.

I controlli tecnici che spostano davvero l’ago

Google articola cinque livelli: model hardening; classificatori di contenuto malevolo che intercettano istruzioni sospette in email e file; sanitizzazione del markdown con blocco del rendering di immagini esterne (la contromisura alla classe di vulnerabilità EchoLeak) e redazione degli URL sospetti via Safe Browsing; un framework di conferma utente human-in-the-loop per le operazioni rischiose; e notifiche contestuali quando una difesa scatta (Google Security Blog). Il blocco delle immagini esterne merita attenzione: tagliare i canali di esfiltrazione è spesso più efficace che tentare di riconoscere l’istruzione malevola, perché un’injection che non ha modo di far uscire il dato è un’injection depotenziata.

AWS aggiunge il lato infrastrutturale: filtri di prompt attack nei Bedrock Guardrails, template che «structure prompts with designated slots for user variables», mappatura delle identità su ruoli IAM così che «the damage is still constrained by the IAM role», WAF davanti all’endpoint e logging completo delle invocazioni per l’analisi a posteriori (AWS Security Blog). Sono gli stessi principi che valgono per la protezione dei modelli AI nel cloud, applicati al caso in cui il modello può agire. Su come tradurre tutto questo in configurazioni concrete abbiamo una guida dedicata ai guardrail per agenti AI in azienda.

Il principio che vale più di ogni filtro: privilegio minimo

Se un agente ha accesso in sola lettura a tre cartelle, l’injection peggiore che subisce vale tre cartelle. La domanda da porsi in fase di design non è «quanto è bravo il modello a resistere», ma «qual è la cosa peggiore che questo agente può fare se ubbidisce a un estraneo?». Da lì si scende: permessi granulari, credenziali isolate per ambiente, conferma umana obbligatoria su cancellazioni, pagamenti e invii verso l’esterno, e allowlist esplicita dei server MCP autorizzati, con le loro configurazioni sottoposte a code review come qualunque altra dipendenza, come raccomanda la CSA.

Red teaming: le prompt injection si trovano solo attaccandosi da soli

OWASP mette i test avversariali e le simulazioni d’attacco fra le sette mitigazioni raccomandate, e non è un adempimento formale: è l’unico modo per sapere se i livelli che hai messo tengono. Google ha istituzionalizzato la pratica con l’automated red teaming, un team interno che attacca Gemini in modo realistico e continuativo; è quel lavoro, non un singolo intervento, ad aver alzato il tasso di protezione durante l’uso degli strumenti.

Per una PMI la versione praticabile è più modesta ma dello stesso tipo: una libreria di payload di injection provati contro i propri agenti, rieseguita a ogni cambio di prompt di sistema, di modello o di set di tool. Ogni aggiornamento del modello è un cambio di superficie d’attacco, non un miglioramento gratuito, e va trattato come un rilascio da testare. Gli incidenti Claude documentati da Anthropic sono una buona fonte di scenari da riprodurre in casa.

Sul fronte MCP la CSA suggerisce una sequenza pragmatica: aggiornare gli IDE, inventariare i server MCP effettivamente installati, rimuovere quelli fuori allowlist, poi introdurre lo scanning delle descrizioni dei tool e l’isolamento delle credenziali in container o VM. L’inventario è il passo che quasi nessuno ha fatto, ed è quello che di solito produce le sorprese peggiori.

Governance, policy e responsabilità: la parte che non è tecnica

Il dato di CrowdStrike che dovrebbe preoccupare di più un CTO non riguarda gli attacchi ma l’organizzazione: il 45% dei dipendenti usa strumenti AI senza autorizzazione IT, spesso raggiungibili dal web pubblico e talvolta collegati a caselle di posta aziendali (dato della stessa rilevazione CrowdStrike sull’indirect prompt injection già citata sopra, CrowdStrike Blog). Lo shadow AI vanifica qualunque guardrail, perché sposta il traffico fuori dal perimetro dove i guardrail esistono.

Servono quindi tre cose che nessun vendor può installare al posto tuo: una policy scritta su quali dati possono entrare in quali strumenti, un registro degli agenti attivi con il rispettivo perimetro di permessi, e un percorso di segnalazione per i comportamenti anomali. È il perimetro che affrontiamo nella nostra guida alla governance degli agenti AI fra policy e audit.

C’è infine il piano normativo. Un agente compromesso che diffonde dati personali è, prima ancora che un incidente di sicurezza, un data breach con obblighi di notifica; e per i sistemi che ricadono nelle classi a rischio dell’AI Act si aggiungono requisiti di robustezza, logging e sorveglianza umana. Abbiamo trattato separatamente il rapporto fra AI Act e agenti AI in azienda e il nodo di sicurezza e GDPR nell’adozione dell’AI. La sintesi operativa è semplice: la responsabilità di un’azione eseguita da un agente resta di chi lo ha messo in produzione, non del fornitore del modello.

Onboarding sicuro degli agenti AI: perché serve un partner, non solo un prodotto

Rileggendo l’elenco delle contromisure emerge una cosa: quasi nessuna si compra. Il privilegio minimo è una scelta di architettura. L’allowlist dei server MCP è una decisione di governance. La libreria di payload per il red teaming va scritta sui processi reali dell’azienda, perché un’injection efficace su un agente che gestisce ordini è diversa da una che colpisce un assistente documentale. E la policy sullo shadow AI funziona solo se le persone capiscono perché esiste, il che è un problema di formazione dei team prima che di tecnologia.

È la ragione per cui in MIMIR trattiamo l’onboarding degli agenti AI come un servizio e non come una consegna di software: mappatura dei permessi effettivi prima dell’attivazione, definizione dei punti in cui l’approvazione umana resta obbligatoria, test avversariali sui flussi reali, e affiancamento nel momento in cui l’agente passa dal pilota alla produzione, che è esattamente quando la superficie d’attacco si allarga. Un agente configurato bene e uno configurato in fretta usano lo stesso modello e hanno rischi incomparabili.

Se in azienda stai valutando o hai già in funzione agenti AI collegati a email, documenti o gestionali, vale la pena verificare quali permessi hanno davvero e cosa succederebbe se obbedissero a un’istruzione arrivata dall’esterno. Puoi parlarne con noi su mimir.bot: partiamo da una ricognizione del tuo caso concreto, senza presupporre che la soluzione sia per forza aggiungere un altro strumento.

Fonti:

• Google Security, «Prompt injections on the web», 23 aprile 2026
• OWASP GenAI Security Project — LLM01: Prompt Injection
• Simon Willison — MCP e prompt injection
• OpenAI — Prompt injections
• CETAS, Alan Turing Institute — Indirect prompt injection: generative AI’s greatest security flaw
• CrowdStrike — Indirect prompt injection attacks e rischi AI nascosti
• Nassi, Cohen, Yair — Promptware attacks, arXiv 2508.12175, agosto 2025
• Invariant Labs — MCP tool poisoning attacks
• OWASP MCP Top 10 — MCP03:2025 Tool Poisoning
• CSA Labs — Research note su MCP tool poisoning e auto-esecuzione, 1 luglio 2026
• Google Security Blog — Mitigating prompt injection attacks with a layered defense strategy
• AWS Security Blog — Safeguard your generative AI workloads from prompt injections