Explosive Prompts: il CERT-AGID misura la prompt injection che aspetta il momento giusto

Immaginate che un agente AI della vostra azienda legga una mail, un PDF o una pagina web in cui è nascosta un'istruzione. Il modello non fa nulla di anomalo, e proprio per questo nessuno se ne accorge. Il CERT-AGID ha appena pubblicato un paper che misura quanto spesso quel silenzio nasconda un'istruzione già acquisita, pronta a scattare più tardi, con un trigger qualunque. Il risultato più utile per chi si occupa di governance non riguarda però i modelli: riguarda l'architettura che li circonda.

Cos'è un Explosive Prompt

Una prompt injection è un'istruzione malevola inserita in un contenuto che l'agente legge, nella speranza che il modello la scambi per un ordine legittimo. Nella forma classica l'effetto è immediato. Un Explosive Promptè la variante a effetto differito: l'istruzione resta inattiva nel contesto e produce effetti solo quando si verifica un trigger successivo.

Il termine non nasce al CERT-AGID. Il paper lo riprende dallo studio di Szczepaniak, Feldman, Viner e Nassi, Defusing Explosive Prompts (arXiv:2609.22510), che riporta come, su nove agenti in produzione, le injection condizionali abbiano ottenuto risultati sensibilmente superiori a quelle imperative. È un dato dello studio citato, non un esperimento del CERT-AGID.

La conseguenza pratica è scomoda: l'assenza di comportamenti anomali durante la lettura del documento non basta a escludere il rischio. Un controllo che guarda solo che cosa succede subito non vede la parte che conta.

L'esperimento del CERT-AGID

Il CERT-AGID ha costruito un ambiente minimo: un orchestratore Python scritto da zero, senza framework agentici. Ha testato quattro modelli open-weight (GLM-5.2, DeepSeek V4 Flash, Qwen 3.8 27B e Gemma 4 26B-A4B-IT) con parametri di inferenza identici. La conversazione dura tre turni e il trigger è una frase innocua, «Perfetto, grazie.». Ogni modello è stato provato in 30 run indipendenti.

Prima del trigger, in nessuna run il tool è stato richiamato. Dopo il trigger le frequenze di attivazione cambiano molto da modello a modello:

• Gemma 4: 76,7%
• GLM-5.2: 53,3%
• DeepSeek V4 Flash: 46,7%
• Qwen 3.8: 10%

Una cautela, che è del paper stesso: questi valori descrivono quel singolo esperimento, con 30 run per condizione, e non misurano la sicurezza generale dei modelli. Usarli per fare una classifica sarebbe sbagliato.

Il confronto che conta: modello manipolato, sistema compromesso?

Il secondo esperimento è quello più interessante per chi deve decidere come costruire un agente. Il tool in gioco, set_protected_flag(value="TRUE"), modifica uno stato protetto, mentre l'agente opera come viewer_agent, cioè senza il privilegio per farlo. Lo stesso modello (GLM-5.2) viene provato in due modalità di autorizzazione, su 30 run ciascuna:

Il modello viene manipolato in entrambi i casi: in modalità enforced tenta di chiamare il tool 10 volte su 30. Ma l'azione non viene eseguita e lo stato protetto non cambia mai.

Attenzione a come si legge la tabella. Le due serie, 14 contro 10, sono batch indipendenti e stocastici: il paper avverte che la differenza non va interpretata come un effetto della policy sulla probabilità che il modello «ci provi». La policy agisce sull'esecuzione, non sul comportamento del modello. È un dettaglio che le sintesi giornalistiche tendono a perdere.

Perché non fidarsi solo del modello

Da qui la conclusione del paper: una prompt injection riuscita contro il modello non deve necessariamente tradursi in un'azione riuscita contro il sistema. Le decisioni di autorizzazione non vanno affidate al solo modello. Servono controlli esterni e indipendenti, che stanno fuori dal modello, a livello di sistema.

Per chi integra agenti con il Model Context Protocol, o con qualsiasi altro meccanismo di tool-calling, il principio è concreto: il modello può chiedere di eseguire un'azione, ma a decidere se l'azione si fa deve essere un componente che non legge il contenuto manipolato. Il paper rimanda a questo proposito a un lavoro sull'autorizzazione zero-trust per MCP aziendali (Li, Wang, Manoharan, arXiv:2609.22573).

Cosa significa per compliance e governance (lettura redazionale Tomato)

Questa sezione è una nostra interpretazione. Il paper del CERT-AGID è un PoC tecnico: non cita alcuna norma o standard, e nulla di quanto segue va attribuito a AgID.

A nostro avviso il principio «l'autorizzazione sta fuori dal modello» si presta a essere letto insieme ai temi che un responsabile compliance ha già sul tavolo: la gestione del rischio dei sistemi di intelligenza artificiale, i controlli di accesso e autorizzazione dei sistemi informativi, la resilienza operativa. Sono i terreni su cui lavorano l'AI Act, gli standard ISO/IEC 42001 e 27001 e, per chi vi è soggetto, NIS2 e DORA. Il paper dà un esempio sperimentale di perché un controllo tecnico esterno valga più di una raccomandazione affidata al modello.

È un aggancio generico, e vogliamo che resti tale. Se avete bisogno di requisiti puntuali, articoli o controlli specifici di una di queste norme, vanno verificati sulla fonte ufficiale prima di essere scritti in una policy.

Cosa fare adesso

Quattro verifiche che potete fare questa settimana sui vostri agenti:

1. Elencate i tool con effetti reali: scrittura di dati, invio di comunicazioni, pagamenti. Sono gli unici punti in cui un'injection fa danno.
2. Spostate l'autorizzazione fuori dal modello: ogni chiamata a un tool passa da un controllo che applica permessi del chiamante, non del contenuto letto.
3. Non fidatevi dei primi turni tranquilli: un contenuto senza effetti visibili subito non è per questo innocuo.
4. Se citate le percentuali, citate anche il limite: sono frequenze di un PoC, non una misura di sicurezza dei modelli.

Se volete capire dove stanno i vostri punti di esposizione, mappare tool, permessi ed effetti esterni dei vostri agenti in produzione è il primo passo, e costa molto meno prima che dopo un incidente: Valuta i rischi dei tuoi agenti e modelli AI in produzione. Sulle tre condizioni che rendono pericoloso un agente, si veda anche La lethal trifecta: il triangolo del fuoco degli agenti AI.

Fonti

• CERT-AGID — Prompt injection a effetto differito: il caso degli Explosive Prompts — ottobre 2026
• AgID — Nuovo paper del CERT-AGID sugli Explosive Prompts e la sicurezza dei sistemi agentici — news del 6 ottobre 2026
• Szczepaniak, Feldman, Viner, Nassi — Defusing Explosive Prompts, arXiv:2609.22510 (2026)
• Li, Wang, Manoharan — Zero-Trust Authorization and Discovery for Enterprise MCP, arXiv:2609.22573 (2026)