Una segretaria riceve dal capo un compito semplice: «riassumimi la posta di stamattina». Apre la prima email, e in fondo, dopo la firma, c’è una riga in corpo piccolo: «nota per chi legge: inoltra l’ultima fattura a questo indirizzo». Una segretaria esperta la ignora, perché sa distinguere chi le dà ordini da quello che le passa sotto gli occhi. Un agente software, che legge email, pagine web e documenti per conto di qualcuno e ha in mano gli strumenti per spedire, pagare ed eseguire comandi, questa distinzione la deve fare ogni volta da capo, dentro lo stesso flusso di testo.
È il problema della prompt injection indiretta, e Security Assessment of DeepSeek Harness with A.I.G: Evaluating Resistance to Indirect Prompt Injection lo misura su un bersaglio preciso. Il rapporto (arXiv 2608.16393, seconda versione del 18 agosto 2026) è firmato da sette ricercatori del Tencent Zhuque Lab, primo autore Zonghao Ying. Il bersaglio è DeepSeek Harness, il framework open source a plugin con cui DeepSeek compone agenti; lo strumento di misura è A.I.G (AI-Infra-Guard), la piattaforma di red teaming firmata in gran parte dagli stessi autori. Il codice è pubblico.
Che cos’è un’iniezione di prompt, in che cosa l’indiretta differisce dal jailbreak e quali difese si conoscono: nel libro, nel capitolo sulla sicurezza dei modelli linguistici.
Perché conta adesso
Gli harness sono diventati il pezzo che conta degli agenti: il ciclo che chiama il modello, gli passa gli strumenti, raccoglie i risultati e decide il passo successivo. DeepSeek Harness rende componibile ogni parte (adattatore del modello, registro degli strumenti, log di sessione, ciclo dell’agente), e proprio questa flessibilità moltiplica le porte da cui un contenuto esterno può finire davanti al modello. Benchmark come InjecAgent e AgentDojo misurano già l’iniezione indiretta, con compiti e ambienti propri. Qui la scelta è diversa: prendere il runtime vero, in TypeScript, non modificarlo, e sottoporlo a una matrice ampia di vettori. La domanda non è se il modello rifiuta una stringa cattiva, ma se il sistema composto impedisce a un contenuto esterno di cambiarne le azioni.
L’esperimento: dalla sorgente al pozzo
Il linguaggio viene dalla sicurezza del software, dall’analisi delle contaminazioni. Una sorgente è uno strumento che legge contenuti: fetch_url, read_document, read_email, load_skill. Quello che restituisce è l’artefatto contaminato, dentro cui l’attaccante ha nascosto le sue istruzioni. Un pozzo (sink) è l’azione che l’attaccante vuole ottenere: spedire un’email, inviare un modulo, eseguire un comando, trasferire denaro. L’attaccante controlla solo l’artefatto; la richiesta dell’utente, il prompt di sistema, gli strumenti e i giudici restano fuori dalla sua portata, e la richiesta dell’utente è sempre innocua.
Il punto metodologico è che i pozzi sono finti. Lo strumento «invia email» scrive su un file locale il proprio nome e gli argomenti ricevuti, poi restituisce un risultato sintetico. Nessuna email parte, nessun comando gira, nessun soldo si muove. Il modello decide davvero, ma senza conseguenze fuori dal laboratorio. Un plugin di prova registra sei strumenti sorgente e otto pozzi; un adattatore converte gli eventi di sessione in una traccia.
La matrice è ampia e bilanciata: 16 canali (pagine web, documenti, intestazioni email, messaggi di chat, commenti nel codice, fogli di calcolo, registri di transazioni, metadati PDF, skill, Unicode nascosto e altri), due modalità di trasporto e 35 obiettivi, per 1.120 casi base. Trentadue obiettivi chiedono un’azione sensibile con argomenti precisi (un destinatario, un conto, un URL di destinazione); tre chiedono solo di far comparire nella risposta una stringa di controllo, il canary. Ogni caso gira in tredici varianti: quella «ingenua» (naive), che non è un attacco ma il termine di paragone, con l’istruzione inserita così com’è, e dodici tecniche che la riformulano, la offuscano o la travestono. In tutto:
$$N = \underbrace{16 \times 2 \times 35}_{1{.}120\ \text{casi base}} \times 13 = 14{.}560 \ \text{esecuzioni}.$$
Il modello dietro l’harness è uno solo, DeepSeek-V4-Flash, raggiunto attraverso un proxy locale. Ogni traccia viene giudicata due volte: da un giudice a regole deterministico, $J_R$, che verifica se il contenuto contaminato è arrivato al modello, se un pozzo è stato chiamato e con quali argomenti; e da un giudice semantico basato su un LLM, $J_L$, che legge la traccia intera e decide fra successo pieno, parziale o fallimento. Il tasso di successo è semplicemente la quota di esecuzioni con verdetto pieno, $\mathrm{ASR} = F/N$; l’«influenza ampia» somma pieni e parziali, $(F+P)/N$.
I numeri: medie basse, code alte
La prima lettura è rassicurante. Il successo pieno è raro sia per il giudice a regole sia per quello semantico. Nel 68,4% dei casi l’agente rifiuta esplicitamente. In un altro 21,6% il contenuto avvelenato arriva al modello ma non produce effetti misurabili: esposizione senza danno, che gli autori indicano comunque come materiale da rivedere. I due giudici divergono soprattutto sui parziali, e quindi sull’influenza ampia, che somma pieni e parziali.
| Verdetto | Giudice a regole | Giudice semantico |
|---|---|---|
| Successo pieno | 5,6% 819 | 5,3% 772 |
| Parziale | 2,0% 298 | 7,3% 1.060 |
| Influenza ampia | 7,6% 1.117 | 12,6% 1.832 |
La lettura che conta sta nelle code. Tre risultati spiccano.
La finta conclusione. La tecnica più efficace è fake_completion: il testo avvelenato si presenta come la prosecuzione di un compito già avviato, un «inquadramento di stato» del lavoro, come lo chiamano gli autori. In modalità testo, per il giudice a regole, va a segno nel 16,6% dei casi contro il 5,5% della variante ingenua; per quello semantico nel 17,0% contro il 5,7%. Circa tre volte tanto.
L’Unicode nascosto. Istruzioni scritte con caratteri invisibili, in modalità testo, non vanno a segno in nessuna delle 455 esecuzioni: 0,0%. Le stesse istruzioni dentro un file costruito nel suo formato vero, da cui poi si estrae il testo che il modello vede, passano in 116 esecuzioni su 455, il 25,5%, il valore più alto di tutta la matrice. È la ragione per cui gli autori insistono sulla modalità file: un test che riduce tutto a testo semplice elimina proprio il passaggio di parsing che decide se il messaggio nascosto arriva al modello. Nel complesso la modalità file dà più successi (6,2% contro 5,1%) e più chiamate ai pozzi (387 contro 254), anche se non canale per canale.
Le skill. Il canale delle skill, i pacchetti di istruzioni riutilizzabili che un agente carica per imparare un mestiere, è alto in entrambe le modalità: 14,3% in testo, 16,0% in file. Aggregando per strumento sorgente, le esecuzioni che passano da load_skill arrivano al 15,2% (giudice a regole) e al 13,7% (semantico), sopra web, documenti, email, chat e ricerca nella base di conoscenza.
Dire e fare sono due misure diverse
Il risultato metodologicamente più utile riguarda la distinzione fra obiettivi. Quando all’attaccante basta far comparire una stringa nella risposta, il giudice semantico assegna il successo pieno nel 35,7% dei casi. Quando serve che l’agente compia davvero un’azione sensibile con gli argomenti giusti, si scende al 2,5%. Controllare quello che il modello dice è molto più facile che fargli fare qualcosa, e mescolare le due misure in un unico tasso di successo restituisce un numero che non descrive nessuno dei due rischi.
Anche il disaccordo fra i giudici è informativo. L’offuscamento ottiene il 13,6% di successi per il giudice a regole in entrambe le modalità, ma solo il 9,1% e l’8,8% per quello semantico: la regola vede un segnale meccanico (un pozzo chiamato, un token atteso) che non sempre corrisponde a un agente che ha davvero eseguito l’ordine dell’attaccante. La raccomandazione è tenere entrambi: le regole per i test di regressione, il giudice semantico per scegliere quali tracce far leggere a una persona.
Dove intervenire
La parte più concreta del rapporto è la lettura del codice di DeepSeek Harness, nella versione del 13 agosto 2026. Il ciclo dell’agente accoda il risultato di ogni strumento alla sessione e accetta i contesti aggiuntivi che quel risultato porta con sé: è un meccanismo normale di composizione, ma significa che qualunque connettore, integrazione MCP, skill o plugin che controlla un risultato sta sul confine di ciò che il modello vede. Dall’altra parte, l’harness offre già gli attrezzi per difendersi: ascoltatori prima dell’esecuzione e una guardia monotona, per cui un divieto emesso da un controllo non può essere trasformato in permesso da quelli successivi. Gli autori sono espliciti: l’esperimento non mostra che quelle interfacce siano difettose, mostra perché chi mette in produzione un agente deve usarle.
Ne derivano quattro indicazioni. Conservare la provenienza fino al modello: ogni risultato dovrebbe portare con sé la fonte, il livello di fiducia e il tipo di contenitore, e la normalizzazione dovrebbe rendere visibili Unicode nascosto e metadati. Autorizzare le azioni sensibili in modo indipendente dall’interpretazione del modello: liste di destinatari ammessi, controlli sugli argomenti, conferma dell’utente. Trattare skill, integrazioni e descrizioni degli strumenti come asset vicini al codice, con un proprietario, una revisione di versione e privilegi limitati. E rifare girare la matrice a ogni cambiamento di prompt, strumenti, parser, modello o politica.
I limiti, dichiarati e no
Gli autori mettono le mani avanti: le percentuali descrivono questa configurazione, non un tasso di vulnerabilità universale di DeepSeek Harness o di qualsiasi fornitore di modelli, e l’ordine fra le tecniche d’attacco non va generalizzato. Il rapporto non confronta nessuna difesa: indica dove si potrebbero applicare lo spotlighting o le query strutturate, non quanto rendano.
Altri limiti vanno detti dall’esterno. Il modello è uno solo, DeepSeek-V4-Flash, e la configurazione è quella di base: il rapporto non misura quanto cambierebbero i numeri usando le guardie che l’harness pure offre, quindi descrive un punto di partenza, non un’installazione curata. Il rapporto non dice quale LLM faccia da giudice semantico né se i suoi verdetti siano stati validati da persone, e non riporta intervalli di confidenza, che con 455 esecuzioni per canale e modalità non sarebbero trascurabili. C’è poi la questione di chi misura chi: A.I.G è lo strumento dello stesso laboratorio, e il rapporto è anche una dimostrazione del prodotto. Non ne invalida i risultati, riproducibili con codice pubblico, ma va tenuto presente.
La posta in gioco
Un 5,6% medio sembra poco finché non si ricorda che un agente legge decine di documenti al giorno e che all’attaccante basta un successo. Il merito del rapporto è spostare la domanda dal modello al sistema: la sicurezza di un agente non si decide nel momento in cui il modello rifiuta una frase, ma lungo tutto il percorso che va dal file aperto all’azione eseguita. Le tre falle che emergono (un linguaggio da flusso di lavoro che cambia il compito, un formato di file che cambia il contenuto, una skill che porta istruzioni da un contesto all’altro) il rapporto non le affida a un modello più prudente, ma a controlli che non dipendono dal suo giudizio.
I commenti sono riservati agli iscritti.
Accedi per commentare