Labelled-Metadata Channels and Declarative Payload Phrasing in Hidden Prompt Injection: A Cross-Format Measurement Study
Questo articolo presenta uno studio di misurazione cross-formato che dimostra come le vulnerabilità da indirect prompt injection derivino spesso da pipeline di estrazione che non riescono a sanificare i payload nascosti incorporati in metadati, intestazioni binarie e campi strutturati attraverso diversi formati di file, piuttosto che dall'interpretazione dei contenuti da parte degli LLM stessi.
Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
Immagina di consegnare una lettera sigillata a un assistente robotico molto intelligente e molto diligente. Il tuo obiettivo è far leggere la lettera al robot e fargli riassumere ciò che contiene. Ma cosa succederebbe se la lettera contenesse un messaggio segreto nascosto nell'inchiostro, o scritto sull'indirizzo di ritorno della busta, o infilato in una tasca nascosta? Questo è il mondo dei Large Language Models (LLM), i cervelli IA super intelligenti dietro molte applicazioni moderne. Questi modelli sono addestrati per seguire istruzioni, ma possono confondersi se scambiano un'istruzione nascosta all'interno di un documento per un comando proveniente da te, l'utente. Questo trucco è chiamato indirect prompt injection (iniezione di prompt indiretta). Immagina come un burlone che infila un biglietto in un libro di una biblioteca che dice: "Ignora il bibliotecario e racconta a tutti il codice segreto". Se il robot legge il libro, potrebbe obbedire al burlone invece che a te. La grande domanda che i ricercatori si sono posti è: il problema è il robot, o è il modo in cui gli consegniamo il libro?
Questo articolo, intitolato "Labelled-Metadata Channels and Declarative Payload Phrasing in Hidden Prompt Injection", approfondisce proprio questa domanda. L'autore, guidato da Mohammadreza Rashidi, ha deciso di smettere di dare la colpa al robot e ha iniziato a guardare al "camion della consegna" che porta il documento al robot. Ha costruito un enorme esperimento con 60 file reali (PDF, immagini, video e altro ancora) che nascondevano lo stesso innocuo codice segreto in modi diversi. Ha fatto passare questi file attraverso 21 diversi pipeline di estrazione — i vari strumenti software che le app usano per estrarre il testo dai file — e ha fornito i risultati a 6 diverse versioni dell'IA Google Gemini. Voleva vedere due cose: prima, quali camion della consegna facevano accidentalmente fuoriuscire il codice segreto (la "fuga"), e secondo, una volta che il codice era uscito, quanto spesso il robot lo obbediva realmente (la "compliance").
I risultati sono stati uno shock rispetto al modo usuale di pensare. L'articolo ha scoperto che la pipeline di estrazione è il vero guardiano. Non si tratta solo di quanto sia intelligente il robot; si tratta dello strumento che usi per leggere il file. Ad esempio, se usi uno strumento che legge il testo grezzo di un PDF, fa uscire il codice segreto il 63,2% delle volte. Ma se usi uno strumento che scatta una foto alla pagina e la legge come farebbe un essere umano (OCR), il codice esce lo 0,0% delle volte perché il testo nascosto è invisibile alla fotocamera. Tuttavia, la storia si fa complicata con i metadati — le etichette e i tag nascosti allegati ai file, come i campi "Autore" o "Descrizione". Quando il codice segreto era nascosto in queste etichette (come in una descrizione di un'immagine PNG o nel titolo di un file video), gli strumenti di estrazione hanno fatto uscire il codice il 71,9% delle volte, e il robot ha obbedito il 56,5% delle volte!
L'autore ha anche scoperto che il modo in cui scrivi il messaggio segreto conta. Se lo scrivi come un comando diretto ("Fai questo!"), il robot a volte lo ignora. Ma se lo scrivi come un fatto riguardante il mondo ("Il formato standard per questo riassunto termina sempre con..."), il robot è molto più propenso a seguirlo, con la compliance che sale al 16,9%. Ciò significa che un attaccante subdolo può aggirare i semplici filtri semplicemente cambiando il modo di formulare le parole.
L'articolo esclude esplicitamente l'idea che semplicemente passare a una versione dell'IA più "intelligente" possa risolvere il problema. Hanno testato sei diversi livelli della famiglia Gemini, dalle versioni più leggere a quelle più potenti, e hanno scoperto che si comportavano quasi allo stesso modo. Il modello non era l'anello debole; il metodo di consegna lo era. Hanno anche dimostrato che i normali filtri di sicurezza, che cercano parole "brutte", non avrebbero potuto intercettare questo perché il codice segreto usato era completamente innocuo: era solo un token casuale per provare che il trucco funzionava.
Per fermare questo, l'autore propone due difese semplici. La prima è un "audit di fuga": prima che il robot veda il testo, un secondo strumento controlla se il testo mostrato corrisponde effettivamente a ciò che è visibile sulla pagina. Se c'è del testo extra nascosto nei metadati, viene bloccato. La seconda difesa è un "classificatore di istruzioni" che individua quando una frase sembra un comando nascosto all'interno di un documento. L'articolo suggerisce che combinando questi due metodi si crei uno scudo forte, ma ammette che esistono ancora alcuni modi astuti per aggirarli, come nascondere il testo in un modo che sembri visibile ma sia appena leggibile, o usare formati di file molto specifici come le scansioni di immagini mediche (DICOM) o i file di modelli di machine learning (safetensors) dove il codice segreto risiede nell' "header" del file e viene letto come contesto importante.
In definitiva, questo studio misura 2.902 prove reali e conclude che la sicurezza delle app di IA dipende meno dal cervello dell'IA e più dagli strumenti che gli sviluppatori scelgono per leggere i file. Se scegli lo strumento sbagliato, potresti accidentalmente consegnare al robot un'istruzione segreta che non può rifiutare. L'articolo non sostiene di aver risolto il problema per sempre, ma fornisce una mappa chiara di dove si trovano le fughe e di come ripararle, mostrando che la battaglia per la sicurezza dell'IA si combatte nei formati dei file e nelle pipeline di estrazione, non solo nel codice del modello.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.