Iniezione indiretta di istruzioni: come impedire che un documento, un’e-mail o il web trasformino un assistente connesso in un canale di fuga o di azioni improprie

La minaccia: dati che tentano di comportarsi da ordini

Un’iniezione indiretta di istruzioni si verifica quando un assistente incorpora contenuti provenienti da una fonte che non controlla — per esempio un’e-mail, un PDF, una pagina web, un ticket o il risultato di uno strumento — e quel contenuto tenta di cambiarne il comportamento. Il testo ostile può chiedere di ignorare restrizioni, cercare segreti, inoltrare informazioni, cambiare il destinatario di un’azione o usare uno strumento diverso da quello necessario. Il vettore è indiretto perché chi attacca non deve scrivere nella casella di conversazione: è sufficiente fare in modo che il sistema legga la risorsa manipolata.

Non è la stessa cosa di un’allucinazione. Un’allucinazione è una risposta errata o non fondata; l’iniezione mira a far seguire al sistema un’istruzione che non avrebbe dovuto avere autorità. Non coincide neppure con una richiesta formulata male da un utente legittimo. La questione centrale è la provenienza e il privilegio: chi può fissare l’obiettivo dell’attività, autorizzare una capacità e determinare quali informazioni possono uscire dall’ambiente.

Il rischio aumenta quando l’assistente combina recupero documentale, navigazione, e-mail e strumenti con effetti esterni. Un assistente puramente informativo può dare una risposta deviata; uno connesso può anche inviare un messaggio, consultare dati oltre l’ambito previsto, modificare un record o trasmettere informazioni a una destinazione non autorizzata. La pubblicazione NIST include l’iniezione indiretta tra gli attacchi di iniezione e descrive scenari di dirottamento di agenti, fuga di dati e contenuti malevoli in risorse come documenti o sistemi di recupero.

La difesa non deve basarsi sul rilevamento di un elenco di frasi sospette. Un attaccante può riformulare, frammentare, nascondere o offuscare le istruzioni. Più importante ancora, persino un rilevamento perfetto di certi schemi non risolverebbe il problema di progettazione: nessun contenuto non affidabile dovrebbe poter acquisire l’autorità di cambiare l’obiettivo, ampliare i permessi, scegliere una destinazione esterna o modificare una politica di divulgazione.

Mappa delle frontiere: separate controllo, dati, capacità ed effetti

Prima di scegliere un modello o un filtro, tracciate l’intero percorso di un’attività. Distinguete le istruzioni di controllo definite dall’organizzazione, la richiesta esplicita dell’utente, i dati forniti da quest’ultimo, il contenuto ottenuto da fonti interne o esterne, le descrizioni degli strumenti, i segreti e le azioni che producono effetti. Queste categorie possono essere presenti nella stessa conversazione, ma non devono essere confuse nel decidere che cosa il sistema possa fare.

Le istruzioni di controllo comprendono la politica di sicurezza, lo scopo del flusso, i requisiti di autorizzazione e le restrizioni in uscita. La richiesta dell’utente può specificare un’attività entro tali limiti. Documenti, e-mail, pagine e risultati degli strumenti sono evidenze o contesto: possono influire su una risposta fattuale, ma non decidere che il sistema debba esportare dati, modificare permessi o contattare qualcuno. Una separazione concettuale esplicita aiuta progettazione, registri e test ad applicare regole diverse a ogni elemento.

È opportuno separare anche il piano dall’esecuzione. Il modello può proporre un’azione, ma un componente di policy indipendente deve verificare se lo strumento è consentito, quale identità verrà usata, quali argomenti sono validi, verso quale destinazione è rivolta l’operazione e se è necessaria una revisione umana. Trattare una chiamata a uno strumento come un suggerimento verificabile, anziché come un ordine eseguibile, riduce la dipendenza dalla corretta interpretazione della gerarchia da parte del modello in ogni caso.

Questa frontiera è particolarmente rilevante per i risultati degli strumenti. Una ricerca, un’API di ticketing o una casella e-mail possono restituire testo controllato da terzi. Se l’assistente reinserisce tale testo come se fosse un ordine di alto livello, il risultato dello strumento diventa una via di escalation. Il lavoro sulla gerarchia delle istruzioni analizza proprio l’assenza di privilegi tra istruzioni come causa degli attacchi di iniezione.

Inventario delle superfici e delle relazioni di fiducia

L’inventario deve includere ogni input che possa arrivare nel contesto durante un’attività, non soltanto la base documentale principale. Includete allegati, corpi e firme delle e-mail, inviti di calendario, commenti, ticket, trascrizioni, risultati di ricerca, pagine visitate, repository, basi vettoriali, memorie conversazionali e testo restituito dai connettori. Annotate inoltre se il contenuto proviene da un utente, un sistema interno, un terzo, una fonte pubblica o un’origine sconosciuta.

La provenienza non rende automaticamente affidabile una fonte interna nel fornire istruzioni. Un ticket interno può contenere testo inserito da un cliente; una wiki può essere modificata da molte persone; una memoria può aver conservato un’istruzione malevola proveniente da una sessione precedente. L’etichetta deve riflettere sia il sistema di provenienza sia il livello di controllo editoriale, il proprietario, la data di recupero e il metodo con cui il contenuto è stato incorporato nel contesto.

Rendete visibile il transito dei dati tra zone. Per esempio, un agente e-mail può leggere un messaggio esterno, usare un indice interno per contestualizzarlo e proporre una risposta attraverso un servizio di invio. In questo percorso vi sono almeno tre decisioni distinte: quale testo mostrare al modello, quali dati interni consultare e quali informazioni inviare all’esterno. Ogni decisione necessita di restrizioni proprie; il permesso non deve essere ereditato da una fase all’altra soltanto perché condividono una conversazione.

La documentazione Microsoft considera e-mail, documenti, pagine web e componenti aggiuntivi come vettori di iniezione indiretta e propone controlli del flusso informativo per distinguere contenuto e fiducia. È un orientamento utile, ma il suo adattamento concreto dipende dalle identità disponibili, dai connettori distribuiti e dalla sensibilità dei dati in ciascuna organizzazione.

Regola di architettura: i dati non concedono capacità

Una policy operativa può essere formulata in modo semplice: un frammento non affidabile può essere citato, riassunto, confrontato o usato come evidenza, ma non può ridefinire l’obiettivo autorizzato né attivare da solo una capacità. Questo impone che le decisioni sugli strumenti si basino su una combinazione dell’intento autenticato dell’utente, della policy del flusso e dei permessi dell’identità che esegue l’azione. Il contenuto recuperato può fornire parametri soltanto dopo una convalida indipendente.

Applicate il privilegio minimo per attività. Un assistente che riassume documenti non necessita di credenziali per inviare e-mail. Una bozza di risposta non necessita del permesso di inviarla. Uno strumento che consulta un record non dovrebbe riutilizzare una credenziale in grado di modificarlo. Ogni volta che la piattaforma lo consente, usate token di breve durata, con ambito limitato a un’operazione e rilasciati dopo il controllo della policy. La separazione delle credenziali riduce le conseguenze se il modello propone un’azione inappropriata.

Limitate anche l’esposizione dei dati. Recuperate solo i frammenti necessari, limitate la quantità di contesto ed eliminate i campi sensibili che non contribuiscono all’attività. Se una richiesta richiede dati interni e una risposta successiva è destinata all’esterno dell’organizzazione, introducete un cancello di uscita che valuti la classificazione dell’informazione, il dominio di destinazione, lo scopo dichiarato e l’autorizzazione applicabile. Non consentite a un documento di suggerire il dominio o la casella a cui inviare dati.

Gli elenchi di destinazioni autorizzate possono essere appropriati per integrazioni ad alto rischio, pur richiedendo manutenzione e non sostituendo la verifica del contenuto. Nei flussi variabili, una policy di destinazione può combinare relazioni organizzative verificate, regole di classificazione e conferma umana. L’obiettivo è che il destinatario derivi da una fonte di autorità — per esempio un registro clienti o una selezione esplicita dell’utente — e non da una frase inserita in un allegato.

Controlli per livello e limiti dei controlli solo apparenti

L’etichettatura della provenienza deve accompagnare il contenuto fino alla generazione e all’esecuzione. Non è sufficiente aggiungere un avviso testuale al contesto, perché tale avviso può andare perso nelle trasformazioni successive. Usate strutture dati che mantengano origine, fiducia, classificazione e relazione con l’attività. Al tempo stesso, delimitate quali campi di tali strutture il modello può leggere e quali campi sono usati esclusivamente dal motore di policy.

La convalida delle chiamate agli strumenti richiede regole semantiche e strutturali. Verificate che lo strumento sia consentito per l’attività, che i suoi argomenti rispettino uno schema, che gli identificatori siano risolti rispetto a registri autorizzati e che l’effetto richiesto corrisponda al piano approvato. Per operazioni di scrittura, convalidate le precondizioni e applicate l’idempotenza quando possibile. Per azioni irreversibili o di ampia portata, mostrate un’anteprima prima dell’esecuzione.

L’approvazione umana è efficace solo se la persona può decidere con informazioni sufficienti. L’interfaccia dovrebbe mostrare l’azione proposta, la destinazione finale risolta, i dati in uscita, la fonte dei parametri rilevanti, l’effetto previsto e la sua reversibilità. Un’approvazione che presenta soltanto un pulsante generico di conferma può trasferire il rischio alla persona senza darle una reale capacità di individuare la manipolazione.

Chiedere al modello di ignorare istruzioni nei documenti può fare parte di una difesa in profondità, ma non costituisce una frontiera di sicurezza. Non sono sufficienti nemmeno un unico prompt di sistema, il blocco di parole o la fiducia nel fatto che il RAG recuperi fonti reputate. OWASP avverte che RAG e fine-tuning non eliminano da soli il rischio di iniezione; le sue raccomandazioni includono separazione tra istruzioni e dati, privilegio minimo, convalida degli strumenti, supervisione e test. Questi controlli riducono il rischio, ma non consentono di promettere il rilevamento completo di contenuti ostili.

Progettate una batteria di test avversari, non solo test di qualità

I test devono dimostrare proprietà osservabili: che un documento non può ampliare l’ambito dei dati; che un’e-mail non può cambiare un destinatario; che una pagina non può avviare una chiamata a uno strumento non giustificata; e che un’istruzione nei risultati di un’API non può persistere come preferenza o memoria. Definite ogni caso con una richiesta legittima, un input avversario, le capacità disponibili, il comportamento atteso e gli eventi che devono rimanere registrati.

Coprire le varianti è più importante che ripetere letteralmente lo stesso attacco. Includete istruzioni dirette, frammentate, codificate, nascoste nei metadati quando il vostro estrattore li elabora, formulate come traduzioni o riassunti e distribuite tra più fonti. Testate anche i conflitti: un documento può chiedere un’azione mentre un altro la contraddice, oppure un risultato di ricerca può tentare di far dimenticare al modello lo scopo iniziale. Il criterio non è che il sistema classifichi ogni testo malevolo, ma che mantenga i divieti di capacità anche se interpreta il testo.

Misurate separatamente rilevamento, blocco e contenimento. Il rilevamento identifica contenuti sospetti; il blocco impedisce un’azione non autorizzata; il contenimento limita dati e privilegi se il rilevamento fallisce. Registrate i falsi blocchi che interrompono attività legittime, poiché una policy troppo ampia può spingere gli utenti a cercare canali alternativi. Rivedete i test a ogni modifica di modello, connettore, modello di orchestrazione, permesso o strumento.

Il dataset LLMail-Inject studia tentativi adattivi contro un assistente e-mail dotato di strumenti. Può servire da riferimento per impostare valutazioni dei flussi e-mail, ma non dimostra da solo la resistenza di un’altra architettura, di un altro modello o di un ambiente con permessi diversi. Integrate qualsiasi corpus esterno con scenari derivati dai vostri connettori, dati e operazioni reali.

Osservabilità e risposta agli incidenti

Un registro utile consente di ricostruire il flusso senza conservare più contenuto sensibile del necessario. Deve collegare la richiesta autenticata, la versione della policy, gli identificatori e le etichette dei frammenti recuperati, il piano proposto, gli strumenti candidati, gli argomenti normalizzati, le decisioni di autorizzazione, le approvazioni e il risultato. In base alla sensibilità, archiviate impronte, riferimenti controllati o copie cifrate con accesso ristretto invece di replicare liberamente documenti completi.

Definite segnali di allerta: deviazione tra l’obiettivo iniziale e un’azione proposta, richiesta di strumenti non disponibili per l’attività, cambio di destinatario, tentativo di accedere a campi non recuperati, catene di strumenti insolite e uscite verso nuove destinazioni. I segnali non sostituiscono la policy preventiva, ma aiutano a dare priorità alla revisione e a individuare percorsi non previsti. Il monitoraggio delle deviazioni del piano e delle catene di strumenti è coerente con l’approccio difensivo descritto da Microsoft.

Davanti a un incidente, contenete innanzitutto il flusso: disabilitate temporaneamente lo strumento o il connettore interessato, revocate token o sessioni quando opportuno e preservate i registri. Determinate poi l’ambito: quale contenuto è stato letto, quali strumenti sono stati proposti ed eseguiti, quali dati sono usciti, con quale identità e verso quali destinazioni. L’indagine deve distinguere una proposta bloccata da un’azione effettivamente completata.

Il ripristino comprende la correzione della regola che ha consentito il transito, la revisione dei privilegi e l’aggiunta di una regressione che riproduca il caso. Se si è verificata un’uscita di dati, attivate i processi di risposta e notifica applicabili alla classificazione e alla giurisdizione pertinenti. Non attribuite automaticamente una fuga all’iniezione indiretta: confermate la catena causale con le tracce, poiché errori di configurazione, permessi eccessivi o automazioni indipendenti possono produrre effetti simili.

Matrice decisionale per caso d’uso e criteri di distribuzione

La stessa policy generale assume forme diverse a seconda del caso d’uso. Un assistente documentale richiede una forte separazione tra evidenza e istruzioni, ma potrebbe non avere effetti esterni. Un agente e-mail aggiunge il rischio di destinatari e allegati. Un browser dotato di strumenti incorpora contenuti mutevoli provenienti da molteplici origini. Un’automazione interna può operare su sistemi critici anche quando le sue fonti sembrano interne. Adeguate i controlli all’impatto delle azioni, non solo alla probabilità di incontrare testo ostile.

Prima di aprire un flusso agli utenti, richiedete prove registrate che il contenuto non affidabile non alteri obiettivo, permessi, destinatari né strumenti consentiti. Verificate inoltre che l’identità di esecuzione disponga dei privilegi minimi e che le operazioni ad alto impatto abbiano un’anteprima o un cancello di approvazione. Se non potete dimostrare queste proprietà, limitate il flusso alla lettura, riducete i connettori o mantenete manuale l’azione.

Questa guida integra la guida al RAG con fonti e quella agli agenti con strumenti nell’indice di sicurezza. La prima aiuta a valutare l’evidenza che sostiene una risposta; la seconda tratta in modo ampio permessi e recupero. Qui la domanda specifica è un’altra: anche se l’assistente ha recuperato contenuti pertinenti e dispone di uno strumento consentito, quale meccanismo impedisce che quel contenuto diventi autorità per ordinare un’azione?

Non esiste una garanzia generale che un modello riconoscerà ogni iniezione indiretta. Per questo, una soglia ragionevole non è dichiarare l’invulnerabilità, bensì dimostrare difese a più livelli, limitare il danno se il rilevamento fallisce e mantenere test di regressione per i flussi effettivamente distribuiti.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.