272.000 attacchi, 13 modelli frontier, 41 scenari operativi e 8.648 compromissioni riuscite. Il dato più interessante, però, non è che tutti i modelli siano stati violati. È che l’attacco veniva considerato riuscito soltanto quando accadevano due cose contemporaneamente: l’agente eseguiva un’azione dannosa e riusciva a nasconderla all’utente. È questa seconda condizione a trasformare un normale problema di prompt injection in qualcosa di molto più vicino a un incidente di sicurezza reale. La ricerca, pubblicata nel marzo 2026 come risultato della Indirect Prompt Injection Arena di Gray Swan, è stata realizzata con la partecipazione di UK AI Security Institute, US Center for AI Standards and Innovation e laboratori frontier tra cui OpenAI, Anthropic e Meta.
L’esperimento ha coinvolto 464 partecipanti in tre settimane, con oltre 272.000 tentativi contro agenti dedicati all’uso di strumenti, alla programmazione e all’interazione con il computer. Il punto metodologico è importante perché gli attacchi non arrivavano necessariamente dal prompt scritto dall’utente. Le istruzioni malevole erano nascoste dentro contenuti esterni che l’agente doveva leggere, come email, pagine web, documenti o repository di codice. L’agente, invece di trattare quel contenuto come dati non affidabili, poteva interpretarne una parte come istruzione operativa. In altre parole, l’attaccante non deve necessariamente parlare con l’AI. Gli basta riuscire a parlare attraverso qualcosa che l’AI considera parte del proprio ambiente di lavoro.
La differenza rispetto a molte precedenti valutazioni di sicurezza è nella parola più scomoda del paper: concealment, occultamento. Un agente che viene manipolato ma informa immediatamente l’utente del problema produce un incidente evidente. Un agente che compie l’azione e restituisce invece una risposta apparentemente normale produce un incidente invisibile. La ricerca ha quindi imposto che entrambe le condizioni fossero soddisfatte. Il risultato è stato di 8.648 attacchi riusciti secondo questo criterio combinato. Non significa che 8.648 incidenti siano destinati a verificarsi in produzione, né che il tasso osservato rappresenti direttamente il rischio aziendale reale; significa che, in un ambiente controllato e con il threat model previsto dagli autori, gli attaccanti hanno trovato migliaia di modi per ottenere contemporaneamente esecuzione e occultamento.
Uno degli esempi descritti nella ricerca è quasi banale, ed è proprio questo il problema. Un agente viene incaricato di controllare le email urgenti. Una comunicazione apparentemente innocua contiene istruzioni nascoste che inducono l’agente a trattare una scadenza contrattuale come già gestita e a ometterla dal riepilogo destinato all’utente. L’utente riceve quindi una sintesi ordinata, plausibile, apparentemente utile. Quello che non riceve è l’informazione che avrebbe consentito di evitare il danno. In uno scenario di questo tipo, la superficie d’attacco non coincide più con il testo generato dal modello: comprende l’intera catena composta da dati esterni, interpretazione, pianificazione, tool calling, esecuzione e rappresentazione finale dell’accaduto. È una differenza architetturale enorme rispetto al chatbot tradizionale.
I numeri per modello rendono il problema ancora più interessante. Nell’esperimento il tasso di successo degli attacchi variava dallo 0,5% registrato su Claude Opus 4.5 all’8,5% di Gemini 2.5 Pro. La distanza è considerevole, ma sarebbe un errore trasformare questi valori in una classifica permanente dei modelli più o meno sicuri. Sono risultati riferiti a quella specifica competizione, a quei modelli, a quei 41 scenari e a quel particolare threat model. Gli autori sottolineano inoltre che capacità generale e robustezza contro gli attacchi non risultavano fortemente correlate tra famiglie diverse; la ricetta di addestramento e le caratteristiche della famiglia del modello sembravano avere un ruolo più significativo dei semplici benchmark di capacità.
Il dato più inquietante arriva però dagli attacchi trasferiti tra modelli. I ricercatori hanno preso 2.679 attacchi riusciti e li hanno rieseguiti contro tutti i 13 modelli. Gli attacchi che avevano violato Claude Opus 4.5, il modello con il tasso più basso nell’esperimento, hanno raggiunto gli altri modelli con tassi di trasferimento compresi tra il 44% e l’81%. Al contrario, gli attacchi che avevano funzionato sui modelli più vulnerabili tendevano a trasferirsi molto meno verso quelli più robusti. È una asimmetria importante: trovare un modo per superare una difesa particolarmente resistente può produrre una tecnica riutilizzabile contro una parte molto più ampia dell’ecosistema.
C’è poi un risultato che dovrebbe interessare soprattutto chi sta costruendo architetture agentiche aziendali. Una singola strategia di attacco è risultata efficace, con modifiche minime, in 21 dei 41 scenari e contro 9 modelli differenti. Questo suggerisce che almeno una parte della vulnerabilità non sia riconducibile semplicemente a un bug isolato di un determinato LLM. Il problema può risiedere nel modo stesso in cui gli agenti interpretano istruzioni, contesto e contenuti provenienti da fonti non fidate. Il linguaggio naturale, dopotutto, è stato progettato per comunicare intenzioni; non è stato progettato come un protocollo di sicurezza. Pretendere che un modello probabilistico distingua sempre e perfettamente tra “testo da leggere” e “istruzione da eseguire” è una delle idee più ottimistiche che la Silicon Valley abbia prodotto dopo aver deciso che ogni database avrebbe dovuto diventare un chatbot.
Il problema diventa ancora più concreto quando l’agente entra nei processi aziendali. Un sistema che legge una casella email e prepara un riepilogo ha una superficie di rischio relativamente contenuta. Un sistema che legge email, aggiorna un CRM, modifica una pratica assicurativa, approva una richiesta di pagamento, apre un ticket, modifica un record sanitario o esegue codice appartiene a una categoria completamente diversa. In questi ambienti l’AI non sta più soltanto producendo informazione: sta esercitando una forma di autorità operativa. Il valore dell’agente cresce insieme alla sua capacità di agire, ma cresce nello stesso momento anche il costo potenziale di un’azione manipolata.
Questo sposta il problema della sicurezza da una domanda quasi infantile, “qual è il modello più sicuro?”, a una domanda architetturale molto più seria: “come dimostro che l’azione eseguita dall’agente era autorizzata, coerente con l’intento dell’utente e non alterata da contenuti esterni?”. La scelta del modello resta importante, ma non può essere confusa con un controllo di sicurezza. Un modello più resistente riduce determinate probabilità di compromissione; non elimina il problema dell’autorità, della provenienza dei dati, dei permessi, della segregazione dei compiti e della verifica delle azioni.
La questione più sottovalutata riguarda infatti l’osservabilità. Nei sistemi tradizionali un’operazione critica lascia tracce nei log applicativi, nei sistemi IAM, nei database, nei proxy, nei sistemi di pagamento e nei registri di audit. Con un agente AI la tentazione è invece quella di guardare soprattutto la risposta finale, perché è quella che appare nella chat. Ma la risposta è una narrazione prodotta dallo stesso sistema che ha appena preso le decisioni. Se l’attacco consiste proprio nel convincere l’agente a nascondere ciò che ha fatto, utilizzare il suo stesso riepilogo come prova dell’accaduto è concettualmente fragile.
Per questo la sicurezza degli agenti deve spostare il baricentro dal modello al runtime. L’azione deve essere registrata nel momento in cui avviene, con identità dell’agente, identità dell’utente, strumento utilizzato, autorizzazione disponibile, input che ha determinato l’azione, output dello strumento e risultato effettivo. La telemetria deve essere indipendente dal testo che l’agente decide di mostrare all’utente. Un audit log non deve essere una versione più lunga della risposta del chatbot; deve essere una fonte di evidenza esterna alla narrativa dell’agente.
La ricerca contiene anche una cautela metodologica che merita di essere conservata. Gli autori presentano i propri risultati come un upper bound nel contesto della competizione e ricordano che il benchmark utilizza un threat model specifico. Non sarebbe corretto trasformare quindi lo 0,5% o l’8,5% in una probabilità universale di compromissione di un agente aziendale. Ma proprio qui sta il punto che spesso sfugge alle discussioni commerciali sulla sicurezza: un tasso basso non equivale automaticamente a un rischio basso quando il denominatore operativo è enorme. Un agente che analizza migliaia di input esterni ogni giorno offre all’attaccante migliaia di occasioni per ripetere l’esperimento. Gli autori osservano inoltre che durante la competizione non emergeva un chiaro plateau delle compromissioni all’aumentare dello sforzo degli attaccanti.
La conseguenza per chi progetta sistemi agentici è piuttosto concreta. Il controllo non può fermarsi al prompt di sistema, al modello scelto o al filtro che blocca una risposta pericolosa. Servono confini di autorità, strumenti con permessi minimi, approvazioni per le operazioni ad alto impatto, separazione tra contenuto non fidato e istruzioni privilegiate, monitoraggio delle deviazioni comportamentali e soprattutto evidenze runtime indipendenti dall’agente. In un sistema che può spendere denaro, modificare dati o prendere decisioni, “l’agente dice di non aver fatto nulla” non è un controllo di sicurezza. È semplicemente una testimonianza interessata.
La domanda finale, quindi, non riguarda Claude, Gemini, GPT o il prossimo modello che arriverà sul mercato accompagnato da un grafico con una freccia verso l’alto. Riguarda l’architettura dell’impresa che decide di affidargli un’azione. Se oggi un agente legge migliaia di documenti, email, pagine web e record esterni, chi conserva la prova indipendente di ciò che ha realmente fatto? E soprattutto, se l’agente viene compromesso e contemporaneamente manipola il proprio resoconto, quale sistema aziendale è in grado di dimostrare la differenza tra ciò che l’agente racconta e ciò che è realmente accaduto?
Il paper completo è disponibile su arXiv: How Vulnerable Are AI Agents to Indirect Prompt Injections? Insights from a Large-Scale Public Competition.