Riepilogo Tecnico: Difendere dalla Prompt Injection con DataFilter

1. Problematica

Il documento affronta la critica vulnerabilità di sicurezza della prompt injection negli agenti basati su Large Language Models (LLM). Poiché gli LLM vengono sempre più impiegati per automatizzare compiti (ad es., navigazione web, chiamata di strumenti) e interagire con dati esterni non attendibili (documenti, email, output di strumenti), gli attaccanti possono iniettare istruzioni malevole in questi dati. Queste iniezioni sovrascrivono l'originale prompt affidabile dell'utente, reindirizzando l'agente a eseguire azioni non intenzionali e potenzialmente dannose, come la fuga di dati o l'esecuzione di malware.

Le difese esistenti soffrono di trade-off significativi:

• Difese a livello di sistema: Richiedono una non banale riprogettazione del sistema e spesso causano una sostanziale perdita di utilità poiché limitano il controllo del flusso dei dati.
• Difese a livello di modello (Fine-tuning): Richiedono l'accesso ai pesi del modello, rendendole inapplicabili ai modelli proprietari black-box.
• Difese basate sulla rilevazione (Detection): Spesso comportano elevati tassi di falsi positivi, portando alla degradazione dell'utilità rifiutando input benigni.
• Difese basate sul prompt: Generalmente offrono una sicurezza debole, con tassi di successo dell'attacco (ASR) che spesso superano il 40%.

Gli autori identificano la necessità di una difesa che sia model-agnostic (funziona su qualsiasi backend, inclusi quelli proprietari), preservante l'utilità e altamente sicura senza richiedere la riprogettazione del sistema.

2. Metodologia: DataFilter

Gli autori propongono DataFilter, un meccanismo di difesa test-time, model-agnostic. A differenza dei sistemi di rilevazione che rifiutano interi input, DataFilter agisce come un filtro che si posiziona tra la fonte dei dati non attendibili e il backend LLM.

Meccanismo Core

DataFilter riceve due input:

1. Istruzione Affidabile ($u$): Il prompt originale dell'utente.
2. Dato Non Attendibile ($x$): Il dato esterno che potrebbe contenere iniezioni.

Il compito del filtro è produrre una versione sanificata del dato ($x_{clean}$) che rimuova le istruzioni malevole preservando al contempo il contenuto benigno rilevante per l'istruzione affidabile. Questo viene formulato come un problema di generazione sequenza-a-sequenza condizionale.

Processo di Addestramento (Supervised Fine-Tuning)

Il modello del filtro (basato su Llama-3.1-8B-Instruct) è addestrato tramite Supervised Fine-Tuning (SFT) su un dataset personalizzato costruito a partire dal dataset di instruction-tuning Alpaca. La strategia di addestramento prevede quattro obiettivi di progettazione chiave per garantire la robustezza:

1. Preservazione del Benigno: Il modello è addestrato su campioni non iniettati per apprendere che, se il dato è benigno, deve essere restituito invariato.
2. Prevenzione delle Allucinazioni: Per impedire al modello di "completare" il testo dopo aver eliminato un'iniezione (un comportamento comune degli LLM), i dati di addestramento includono campioni in cui il dato benigno è troncato. Il modello apprende a restituire il dato troncato esattamente così com'è, senza generare nuovi token.
3. Prevenzione della Ripetizione Infinita: Un token speciale di fine sequenza (<|end_of_data|>) viene introdotto e addestrato per garantire che il filtro interrompa la generazione immediatamente dopo il dato pulito, evitando loop infiniti.
4. Generalizzazione Posizionale: Le iniezioni sono simulate in posizioni casuali (inizio, centro, fine) all'interno del dato per garantire che il filtro possa identificare e rimuovere le iniezioni indipendentemente dalla loro posizione.

L'obiettivo di addestramento minimizza la log-likelihood negativa di generare il dato pulito reale dato il paio prompt e dato iniettato:
$$L(\theta) = -\log p_\theta(x_{clean} | \langle u, x \rangle)$$

Gestione dei Dati Strutturati

Per le applicazioni agentiche in cui i dati sono strutturati (ad es., JSON), DataFilter analizza la struttura, filtra ricorsivamente il contenuto testuale di chiavi e valori, e ricostruisce l'oggetto. Ciò evita la generazione di JSON sintatticamente non validi.

3. Contributi Chiave

• Una Nuova Architettura di Difesa: DataFilter è la prima difesa model-agnostic che combina la sicurezza degli approcci a livello di sistema con la facilità di implementazione degli approcci a livello di modello, senza richiedere i pesi del modello backend.
• Logica di Filtraggio Sofisticata: Condizionando il filtro sull'istruzione affidabile dell'utente, il sistema può distinguere tra frasi imperative che sono iniezioni malevole e quelle che sono contesto benigno (ad es., liste "TODO" nelle email), una distinzione che i metodi precedenti faticavano a fare.
• Valutazione Esaustiva: Il documento valuta la difesa attraverso molteplici benchmark (SEP, InjecAgent, AgentDojo, AlpacaEval2) e contro diversi vettori di attacco (Straightforward, Ignore, Completion, Multi-Turn e Context attacks).

4. Risultati Sperimentali

Gli autori hanno valutato DataFilter rispetto a baseline tra cui PromptGuard, DataSentinel, Sandwich prompting, Spotlighting, Tool Filter e il lavoro concorrente PromptArmor.

Prestazioni di Sicurezza (Attack Success Rate - ASR)

• AgentDojo: DataFilter ha ridotto l'ASR a una media dello 0,4% (massimo 1,2%) attraverso vari tipi di attacco, superando PromptArmor (media 0,7%) e superando significativamente le difese basate sulla rilevazione e sul prompt (che spesso presentavano un ASR > 20%).
• InjecAgent: DataFilter ha ottenuto un ASR del 2,0% (attacco Base) e dello 0,0% (attacco Enhanced) su gpt-4o, e del 2,1% e 1,2% su Llama-3.1-8B-Instruct.
• SEP (Instruction Following): DataFilter ha mantenuto un basso ASR in tutti i sei tipi di attacco sia per gpt-4o che per Llama-3.1-8B-Instruct. In particolare, è stata una delle poche difese efficaci contro il Context attack, che imita istruzioni legittime.
• Attacchi Adattivi: Anche sotto attacchi adattivi progettati dall'uomo e forti attacchi adattivi basati su LLM (utilizzando algoritmi genetici), DataFilter ha mantenuto l'ASR più basso tra tutte le difese testate (83% vs 93% per PromptArmor nello scenario peggiore basato su LLM), sebbene gli autori notino che nessuna difesa è attualmente immune agli attacchi adattivi più sofisticati.

Prestazioni di Utilità

• AgentDojo: DataFilter ha preservato il 79,4% dell'utilità benigna (solo un calo di circa il 2% rispetto al modello non difeso), mentre le difese basate sulla rilevazione come DataSentinel hanno subito una grave perdita di utilità (36,6%) a causa dei falsi positivi.
• AlpacaEval2: DataFilter ha mantenuto punteggi di utilità comparabili alla baseline non difesa (54,1% per gpt-4o), dimostrando che il processo di filtraggio non degrada la qualità delle risposte per compiti benigni.

Trade-off

Come illustrato nelle figure del documento, DataFilter raggiunge un trade-off Sicurezza-Utilità superiore, avvicinandosi più della qualsiasi metodologia precedente all' "ideale di difesa" (zero ASR con zero calo di utilità).

5. Significato e Rivendicazioni

Il documento afferma che DataFilter offre una difesa pratica e plug-and-play per proteggere gli LLM commerciali black-box contro la prompt injection. La sua importanza risiede in:

1. Accessibilità: Non richiede l'accesso ai pesi del modello, rendendolo implementabile per sviluppatori terzi che utilizzano API proprietarie.
2. Efficacia: Mitiga con successo una vasta gamma di attacchi di iniezione, inclusi quelli contestualmente rilevanti e difficili da rilevare.
3. Preservazione dell'Utilità: Evita il problema dell' "over-refusal" comune nei sistemi basati sulla rilevazione, garantendo che gli agenti rimangano funzionali per i compiti legittimi.

Gli autori riconoscono che, sebbene DataFilter sia robusto contro gli attuali vettori di attacco, potrebbe ancora essere vulnerabile agli attacchi adattivi più sofisticati, un limite condiviso da tutte le difese esistenti. Tuttavia, posizionano DataFilter come una soluzione forte e immediata per il breve-medio termine per mettere in sicurezza gli agenti LLM di livello di produzione.