Sintesi Tecnica: Il Contenimento rispetto alla Rilevazione per la Difesa dalla Prompt Injection

Problema

La prompt injection rappresenta una vulnerabilità critica nei sistemi di Large Language Model (LLM) agentici, in cui contenuti avversari incorporati nell'input dell'utente sovrascrivono i vincoli di sistema, portando all'esfiltrazione di dati, all'escalation dei privilegi o all'esecuzione non autorizzata di codice. Gli attuali sistemi in produzione, in particolare quelli che si integrano con datastore sensibili e sandbox di esecuzione del codice, si affidano pesantemente su difese basate sulla rilevazione (filtraggio di parole chiave, classificatori appresi, analisi della perplessità).

Gli autori sostengono che il paradigma della rilevazione soffra di un difetto fondamentale: tenta di risolvere un problema di classificazione semantica (distinguere istruzioni malevole da dati legittimi) che è intrinsecamente ambiguo nel linguaggio naturale. Questo approccio crea un compromesso inevitabile tra accuratezza e latenza. I classificatori ad alta accuratezza introducono ritardi di inferenza e richiedono un continuo riaddestramento, mentre anche i rilevatori altamente accurati (ad esempio, il 99%) falliscono perché l'attaccante ha solo bisogno di un singolo successo per compromettere il sistema. Inoltre, i meccanismi di rilevazione producono spesso falsi positivi, rifiutando query legittime degli utenti che contengono un fraseggio simile a quello delle istruzioni.

Metodologia: L'Architettura di Contenimento

Il documento propone un passaggio dalla rilevazione al contenimento. Invece di tentare di identificare e rifiutare l'input malevolo, il sistema rende il contenuto avversario strutturalmente inerte imponendo un confine criptografico tra istruzioni e dati. Ciò è ottenuto attraverso un'architettura di difesa composibile a quattro livelli:

1. Generazione di Token Criptografici Effimeri:
   All'avvio del container, viene generato un token casuale crittograficamente sicuro ($\tau$) con 256 bit di entropia. Questo token è codificato come una stringa base64 sicura per gli URL (43 caratteri). Fondamentalmente, $\tau$ non viene mai persistito su disco, nei log o nelle variabili d'ambiente e viene ruotato al riavvio del container, garantendo la forward secrecy.

2. Canonicalizzazione dell'Input:
   Prima dell'avvolgimento, l'input dell'utente subisce una canonicalizzazione per eliminare i vettori di bypass basati sulla codifica. Questo processo rimuove i caratteri di controllo Unicode (categorie Cc) e specifici separatori di riga/paragrafo (Zl/Zp, ad esempio U+2028, U+2029) che potrebbero essere interpretati diversamente dai tokenizer rispetto alla logica di validazione. Ciò assicura che l'input sia normalizzato prima dell'applicazione del confine.

3. Avvolgimento in Busta Autenticata dal Token:
   L'input canonicalizzato viene avvolto in una busta simile a un XML: <untrusted_input id="{token}">...</untrusted_input>.

   • Validazione Lato Server: Un controllo di sicurezza critico avviene prima dell'avvolgimento. Il sistema rifiuta qualsiasi input che contenga già il token $\tau$ o la struttura del tag della busta. Questo impedisce a un attaccante di chiudere prematuramente il tag della busta per iniettare istruzioni al di fuori del confine.
   • Garanzia Deterministica: Il confine è criptograficamente imprevedibile; un attaccante non può costruire un tag di chiusura valido senza conoscere $\tau$.

4. Grounding Comportamentale del Prompt:
   Il prompt di sistema istruisce esplicitamente l'LLM a trattare il contenuto all'interno dei tag <untranslated_input> strettamente come dati da elaborare, non come istruzioni eseguibili. Il prompt enfatizza che il linguaggio simile alle istruzioni trovato all'interno della busta deve essere trattato come testo letterale. Gli autori notano che è preferibile un fraseggio neutro rispetto a avvisi allarmanti per evitare rifiuti falsi di query legittime.

Contributi Principali

Il documento presenta quattro contributi primari:

1. Garanzia di Sicurezza Formale: Gli autori forniscono una prova formale (Teorema 1) dimostrando che, sotto un modello di attaccante black-box (senza accesso all'oracolo del token di runtime), la probabilità che un attaccante crei un escape del confine valido è trascurabile ($\le 2^{-256}$).
2. Architettura di Difesa Composibile: Un sistema a quattro livelli con interfacce formalmente specificate e isolamento dei modi di guasto, che opera allo strato di pre-elaborazione dell'input indipendentemente dal comportamento del modello.
3. Metodologia di Test Basata sulle Proprietà: Gli autori hanno utilizzato il framework Hypothesis per definire 15 invarianti di sicurezza verificabili meccanicamente. Questo approccio ha identificato con successo tre bug critici per la produzione (incluso un bug di non-idempotenza della canonicalizzazione e un problema di buffer overflow) che i test convenzionali basati su esempi avevano mancato.
4. Validazione Empirica: Una valutazione completa contro 547 pattern avversari tratti da quattro corpus di attacchi stabiliti (Garak, OWOW ASP LLM Top 10, HarmBench e un set multilingue personalizzato).

Risultati

La difesa è stata valutata in un sistema agente in produzione che serve circa 200 analisti con accesso a database, interpreti di codice e basi di conoscenza RAG.

• Tasso di Contenimento: Il sistema ha raggiunto un tasso di contenimento sintattico del 94,3%. In questi casi, l'input avversario è stato avvolto con successo e il modello lo ha trattato come dato.
• Fallimenti Residui: Il tasso di fallimento del 5,7% consisteva interamente in jailbreak semantici a livello di modello. In questi casi, l'input era sintatticamente contenuto nella busta, ma il modello ha comunque seguito le istruzioni iniettate (ad esempio, tramite reframing cognitivo o suffissi avversari). Gli autori classificano questi casi come ortogonali alla difesa dello strato di input.
• Falsi Positivi: La difesa ha prodotto lo 0% di falsi positivi. Poiché il sistema non rifiuta mai l'input in base al contenuto (lo avvolge soltanto), le query legittime contenenti un fraseggio simile alle istruzioni sono state elaborate correttamente.
• Latenza: L'overhead di runtime è stato misurato in <0,5 ms per richiesta, superando significativamente i classificatori appresi (180 ms) ed evitando il bloat dei token tipico delle difese "sandwich".
• Scoperta di Bug: Il testing basato sulle proprietà ha scoperto difetti critici, tra cui un problema di non-idempotenza della canonicalizzazione dove specifici caratteri Unicode potevano bypassare la validazione in passaggi ripetuti, e un errore di buffer di logging che scartava gli eventi più recenti (forensicamente rilevanti) sotto carico.

Significato e Rivendicazioni

Il documento sostiene che l'approccio di contenimento altera fondamentalmente l'obiettivo della sicurezza per gli LLM agentici. Passando da una classificazione semantica probabilistica a un'imposizione di confini sintattici deterministici, la difesa elimina il compromesso tra accuratezza e latenza inerente ai sistemi basati sulla rilevazione.

Gli autori sottolineano che, sebbene lo strato di contenimento fornisca una base criptograficamente solida che impedisce l'escape strutturale, esso non risolve il problema dei jailbreak a livello di modello. Il tasso di fallimento residuo del 5,7% rappresenta il limite della difesa dello strato di input; affrontare questo richiede salvaguardie complementari a livello di modello (training di sicurezza, modelli di guardrail). Tuttavia, lo strato di contenimento assicura che il confine di input sia inconfalsificabile, permettendo alle difese di livello superiore di operare su un substrato sicuro.

Il lavoro posiziona il testing basato sulle proprietà come uno standard essenziale per l'infrastruttura di sicurezza critica degli LLM, dimostrando la sua superiorità nel rivelare vulnerabilità di casi limite che il testing basato su esempi trascura. L'harness di valutazione e le specifiche delle proprietà sono rilasciati come open-source per facilitare la riproducibilità.