Agent Data Injection: perché fermare la prompt injection non basta

Cosa dice il paper, senza trasformarlo in allarme

Il preprint “Agent Data Injection Attacks are Realistic Threats to AI Agents”, pubblicato su arXiv il 6 luglio 2026, descrive una categoria di indirect prompt injection chiamata Agent Data Injection, o ADI. Il problema osservato non è soltanto un contenuto esterno interpretato come ordine: è un contenuto non fidato interpretato come dato fidato dentro il contesto dell’agente.

Gli autori hanno studiato modelli e agenti reali, mostrando rischi per agenti che navigano sul web e agenti che lavorano sul codice. Hanno inoltre comunicato le vulnerabilità ai vendor prima della pubblicazione. Questi risultati dimostrano una classe di rischio e riguardano versioni e configurazioni testate: non sono una classifica tra prodotti e non provano che ogni vulnerabilità sia ancora presente o lo resterà.

La lezione operativa è più ampia del singolo prodotto. Se istruzioni, risultati dei tool, metadati e contenuti esterni finiscono nello stesso contesto senza confini applicabili dal sistema, il modello può attribuire a un dato origine, ruolo o autorità sbagliati.

Instruction injection e data injection non sono la stessa cosa

Entrambe rientrano nel problema più generale dell’indirect prompt injection: l’attaccante non modifica direttamente il prompt di sistema o quello dell’utente, ma controlla un contenuto che l’agente recupererà da una pagina, un documento, un’email, un issue tracker o un tool.

La differenza è ciò che il modello finisce per credere. Nell’instruction injection il contenuto ostile viene trattato come una nuova istruzione. Nell’Agent Data Injection viene trattato come dato affidabile: per esempio origine, autore, identificatore di una risorsa o esito di un’azione. L’agente può quindi continuare il compito richiesto dall’utente, ma svolgerlo usando riferimenti alterati.

Instruction injection

Dati esterni vengono interpretati come istruzioni e provano a cambiare obiettivo o comportamento dell’agente.

Agent Data Injection

Dati esterni vengono interpretati come dati fidati e alterano ciò che l’agente crede su origine, identità, target, struttura o risultato di un tool.

Impatto comune

In entrambi i casi l’agente può compiere un’azione diversa da quella realmente autorizzata. Cambia il confine di fiducia che è stato confuso.

Il rischio per i web agent

Un web agent vede nello stesso flusso pulsanti, etichette, identificatori tecnici e contenuti creati dagli utenti. Recensioni, commenti, nomi di elementi e testo della pagina non hanno tutti lo stesso livello di fiducia, anche quando arrivano dallo stesso sito.

Se il modello confonde il testo controllabile da un utente con l’identità tecnica di un elemento, può selezionare un target diverso da quello mostrato o approvato. Il paper dimostra questa classe di problema con azioni di click non desiderate. Per una difesa pratica, leggere e agire devono essere fasi separate.

1. Fai raccogliere e riassumere i contenuti in modalità read-only, senza capacità di acquisto, invio, conferma o modifica.
2. Prima di un’azione, risolvi nuovamente target e stato della pagina attraverso un componente deterministico e non dal solo riepilogo del modello.
3. Mostra all’utente azione, dominio, oggetto e conseguenza usando dati ottenuti dal livello di esecuzione fidato.
4. Richiedi una nuova approvazione se target, parametri o stato cambiano tra anteprima ed esecuzione.
5. Registra la provenienza dei dati che hanno determinato l’azione e il suo esito, senza conservare segreti o dati personali non necessari.

Il rischio per coding agent e strumenti MCP

Un coding agent legge repository, issue, pull request, documentazione, output dei test, registri di pacchetti e risposte di tool. Queste fonti si mescolano facilmente. Il fatto che un contenuto arrivi tramite GitHub, un terminale o un server MCP non lo rende automaticamente fidato: un commento resta contenuto di terzi e una risposta può includere campi con origini diverse.

Il paper descrive dimostrazioni su agenti di coding nelle quali dati esterni vengono scambiati per metadati o cronologia di tool affidabili, con possibili conseguenze sull’esecuzione di codice e sulla supply chain. Qui non servono i dettagli dei payload per capire il controllo: un issue non deve poter attribuirsi l’autorità di un maintainer e il testo di una pull request non deve poter sostituire il diff reale.

MCP amplia la superficie utile dell’agente, non annulla i confini di fiducia. La configurazione del server, l’identità del tool, lo schema e i singoli campi della risposta vanno considerati separatamente. Una trasformazione o un riassunto prodotto dal modello deve inoltre ereditare la provenienza dei dati di partenza, non diventare fidato soltanto perché è stato riscritto.

• Issue, commenti, descrizioni di pull request e file provenienti da fork: dati non fidati finché non vengono verificati.
• Diff, firma, branch di destinazione e identità dell’autore: verifiche da ottenere dalle API o da Git, non dal testo della discussione.
• Output di build e test: utile come evidenza, ma da collegare a commit, ambiente e comando realmente eseguito.
• Risposte MCP: classificare campi e origine; non attribuire fiducia all’intero blocco perché il trasporto è autorizzato.
• Installazioni, modifiche al lockfile, pubblicazioni, merge e deploy: azioni ad alto impatto da tenere dietro un gate separato.

Prima difesa: costruisci una mappa di fiducia

“Fidato” non significa vero, innocuo o esente da validazione. Significa che il sistema conosce l’origine del dato, ne protegge l’integrità e ha deciso per quali usi può essere considerato autorevole. La classificazione è specifica per campo e azione, non per schermata o connettore.

La mappa va definita prima del prompt. Se il modello decide da solo quali dati sono affidabili usando lo stesso contesto che può essere alterato, il controllo di sicurezza è già dentro il confine sbagliato.

Istruzioni autorizzate

Obiettivo dell’utente autenticato e policy del sistema. Definiscono cosa può essere proposto, non concedono automaticamente ogni permesso operativo.

Dati di controllo

Identità del tool, target normalizzato, permessi, commit, firme, stato dell’approvazione e altri campi prodotti o verificati da componenti deterministici.

Dati esterni non fidati

Testo di pagine, documenti, email, issue, commenti, nomi di file e contenuti ottenuti da utenti o servizi terzi.

Dati derivati

Riassunti, classificazioni e parametri estratti dal modello. Devono conservare provenienza e livello di fiducia delle fonti, soprattutto prima di un’azione.

Sette controlli che riducono il danno possibile

Nessun controllo singolo risolve ogni forma di injection. La strategia utile combina prevenzione, contenimento e possibilità di ricostruire ciò che è accaduto. I controlli critici devono vivere fuori dal modello, in componenti che applicano policy in modo deterministico.

1. Separazione dei dati: conserva canali, campi e label distinti per istruzioni autorizzate, metadati verificati e contenuti non fidati. Propaga le label quando i dati vengono trasformati.
2. Read-only come default: usa sessioni di analisi senza scrittura, esecuzione, rete libera o azioni esterne. Concedi capacità aggiuntive soltanto quando il piano è stato verificato.
3. Minimo privilegio: limita tool, directory, repository, endpoint e durata delle credenziali al singolo task. Evita account condivisi e wildcard.
4. Secret isolation: tieni token, chiavi e credenziali fuori da prompt, repository, output dei tool e log. Il livello di esecuzione può usare credenziali brevi e circoscritte senza rivelarle al modello.
5. Approval gate: per scritture, esecuzione, installazioni, merge, invii e deploy mostra l’azione esatta con target e parametri verificati. L’approvazione scade e non vale se qualcosa cambia.
6. Provenance: registra fonte, identità, timestamp, trasformazioni e livello di fiducia dei dati che entrano in una decisione. Un riassunto non deve perdere la storia della fonte.
7. Audit log: conserva tool chiamato, parametri redatti, policy applicata, approvazione, risultato e versione del contesto operativo. Proteggi il log da modifiche e limita accesso e conservazione.

Workflow prudente per un coding agent

Questa procedura non prova a riconoscere ogni possibile payload. Riduce invece le possibilità dell’agente durante la fase in cui legge dati esterni e crea punti di controllo prima delle azioni irreversibili o difficili da revisionare.

1. Acquisisci il task e verifica identità, repository e stato tramite il sistema di controllo, non dal testo di un issue.
2. Lascia che l’agente legga e proponga un piano senza permessi di scrittura o accesso ai segreti.
3. Classifica le fonti usate dal piano e verifica attraverso API o Git i dati che determinano identità, branch, commit e dipendenze.
4. Concedi scrittura soltanto sullo scope approvato e usa un ambiente isolato, senza credenziali di produzione.
5. Rivedi il diff reale e i cambi di dipendenze; non accettare come prova un riepilogo contenuto nella pull request.
6. Esegui test e build con rete e filesystem limitati. Mantieni pubblicazione e deploy in una fase separata.
7. Chiudi o revoca i permessi temporanei e conserva un audit log redatto che permetta di ricostruire decisioni e azioni.

[ ] Task, repository e branch verificati da una fonte fidata
[ ] Analisi iniziale in sola lettura
[ ] Issue, commenti, web e risposte esterne marcati come non fidati
[ ] Tool MCP e permessi ridotti al necessario
[ ] Secret esclusi dal contesto e dal workspace dell’agente
[ ] Piano e file previsti revisionati prima della scrittura
[ ] Diff reale confrontato con commit e branch attesi
[ ] Installazioni, merge, pubblicazioni e deploy dietro approvazione separata
[ ] Test eseguiti in ambiente isolato
[ ] Log di tool, approvazioni ed esiti disponibile e privo di segreti

Come verificare il sistema senza usare payload offensivi

Puoi testare l’architettura con casi benigni. Crea una fonte esterna di prova che dichiari informazioni incompatibili con i metadati verificati, senza includere comandi o sequenze di attacco. L’obiettivo è controllare quale fonte vince e se un’azione sensibile resta bloccata.

Per esempio, usa un issue sintetico che descrive a parole un autore o un branch diverso da quelli restituiti dall’API. Il test supera la prova se il sistema conserva entrambe le provenienze, usa i campi verificati per la decisione e chiede approvazione sull’azione esatta. Ripeti dopo cambi di modello, prompt, tool, schema MCP o policy.

• Il contenuto esterno non può cambiare identità, origine o autorizzazioni registrate dal sistema.
• I dati derivati mantengono il riferimento alla fonte originale e il relativo livello di fiducia.
• Una sessione read-only non può ottenere per concatenazione un tool di scrittura.
• L’approval gate mostra target e parametri verificati e fallisce chiuso se il log o la policy non sono disponibili.
• I log permettono di ricostruire l’azione senza esporre token, prompt completi o dati personali non necessari.

Limiti dello studio e fonti da leggere

Il paper è un preprint arXiv v1 di 19 pagine, non una conclusione definitiva su ogni agente. Le percentuali riportate dagli autori dipendono da benchmark, modelli, formati e difese valutate. Sono evidenza della classe di rischio, non una misura universale applicabile a qualunque prodotto.

Gli autori indicano che una forma rigorosa di data-flow tracking ha bloccato gli attacchi nel loro benchmark, ma segnalano anche la difficoltà di definire policy complete senza ridurre l’utilità. Per questo la guida combina provenienza con contenimento operativo: read-only, minimo privilegio, segreti isolati, gate esterni e log.

Le indicazioni OWASP citate sotto sono coerenti con questo approccio a più livelli: strumenti con privilegi minimi, approvazione umana per azioni ad alto impatto, separazione tra decisione ed esecuzione e audit trail. Vanno adattate al tuo sistema e verificate di nuovo quando cambiano agenti, integrazioni o policy.

• Paper originale su arXiv: Agent Data Injection Attacks are Realistic Threats to AI Agents ↗
• Versione HTML del paper con metodologia, valutazione e responsible disclosure ↗
• OWASP: AI Agent Security Cheat Sheet ↗
• OWASP: Secure Coding with AI Cheat Sheet ↗
• DottorLone: usare Codex Security senza scambiare uno scan per una garanzia →