Sintesi Tecnica: Nascondersi tra i numeri in virgola mobile (Hiding in Plain Floats)

Definizione del Problema

Le attuali difese contro l'iniezione di prompt indiretta e l'iniezione di contenuti nei processi (pipeline) di Large Language Models (LLM) si basano su un presupposto centrale: che i segnali malevoli siano visibili come testo all'interno delle viste dei dati ispezionate (configurazione grezza o report ricostruiti). Le difese come Prompt Guard, Llama Guard, i gate regex degli schemi e lo spotlighting operano scansionando le stringhe alla ricerca di istruzioni imperative o pattern di attacco noti.

Questo documento identifica un caso di fallimento in cui tale presupposto viene meno. Gli autori dimostrano che nelle pipeline che espongono canali ausiliari numerici ricostruiti (ad es. parametri di generazione procedurale, array di embedding o uniformi di shader) a un LLM, i payload malevoli possono essere trasportati come parametri strutturati in virgola mobile (float). Quando vengono ricostruiti, questi payload possono apparire come frammenti di telemetria (ad es. dump esadecimali) piuttosto che come prosa contigua. Di conseguenza, gli strati di ispezione basati solo sul testo non riescono a rilevare il segnale malevolo perché il segnale non è visibile come testo finché non è già entrato nel contesto del modello, oppure non è mai visibile come testo nelle viste ispezionate.

Metodologia

Modello di Minaccia

Lo studio si concentra su una pipeline in cui un asset strutturato inviato dall'utente (ad es. una configurazione di generazione procedurale) viene ricostruito da un parser fidato in un report leggibile dall'uomo, che viene poi riassunto o analizzato da un LLM.

• Attaccante: Controlla gli array numerici e i campi dell'asset a monte, ma non controlla il codice di ricostruzione, i prompt di sistema o i pesi del modello.
• Difensore: Può ispezionare la configurazione grezza a monte, il report ricostruito, o entrambi, utilizzando gate regex, classificatori standard o modelli specializzati.
• Obiettivo: Determinare se l'ispezione basata solo sul testo può rilevare attacchi in cui il payload è nascosto in array di float e ricostruito come dati non testuali.

Carrier Steganografici

Gli autori introducono due carrier innovativi e un carrier di ablazione per testare i confini della rilevazione:

1. T2 (Steganografia dei Coefficienti Spettrali): Codifica i caratteri del payload nelle cifre decimali basse di valori float che rappresentano coefficienti armonici. La configurazione grezza non contiene testo, ma la ricostruzione decodifica questi float riportandoli in prosa contigua all'interno di una "Nota di Analisi Spettrale".
2. T3 (Carrier di Array Float derivato da IFS): Utilizza un Sistema di Funzioni Iterate (IFS) per guidare una mappa di contrazione con i byte del payload. La risultante traiettoria $(x, y)$ è memorizzata come due array coordinati di float.
   • Contromisure: Per ridurre la separabilità di primo ordine dai dati armonici uniformi, gli autori applicano:
     • Whitening (Bianchezza): XOR dei byte del payload con un flusso pseudocasuale per rimuovere il bias della frequenza dei caratteri.
     • Bounded Jitter (Jitter Limitato): Aggiunta di rumore deterministico ($\epsilon \sim U[-0.04, 0.04]$) alle coordinate.
     • Deterministic Shuffle (Permutazione Deterministica): Permutazione dell'array per rompere i segnali di autocorrelazione sequenziale.
   • Ricostruzione: Il payload viene decodificato e renderizzato come un hex dump in stile xxd (16 byte per riga) con una barra laterale ASCII. Questo formato non contiene prosa contigua, solo stringhe esadecimali frammentate.
3. T1b-abl (Ablazione): Memorizza il payload come prosa pura nella configurazione grezza, ma lo ricostruisce come un hex dump (identico alla ricostruzione di T3). Questo isola l'effetto della frammentazione del livello di ricostruzione.

Configurazione Sperimentale

• Modelli: Tre LLM commerciali (OpenAI GPT-5.4, Google Gemini 3.1 Flash-Lite, Anthropic Claude Sonnet 4.6).
• Difese: Quattro configurazioni: Nessuna, Boundary Prompt (indurimento del prompt di sistema), Schema Gate (regex sul report ricostruito) e un Ensemble di Classificatori a Doppio Strato (Prompt Guard 2 + TF-IDF fine-tuned sul testo del payload dello studio).
• Scala: 14.400 prove attaccate e 4.800 prove pulite su tre modelli.
• Metriche:
  • Leakage ASR: Presenza di stringhe target nell'output (leakage di informazioni).
  • Strong ASR: Successo strutturalmente conforme (ad es. marker nei primi 150 caratteri, riproduzione del template iniettato).
  • Tasso di Rilevazione: Frazione di attacchi segnalati dalle difese.

Risultati Chiave

Risultato Principale: Il Fallimento dell'Ispezione Solo Testo

Il carrier T3 ha ottenuto un Leakage ASR del 94,3% contro la più forte difesa centrata sul testo valutata (Ensemble di Prompt Guard 2 + TF-IDF).

• Confronto: Lo stesso testo del payload in forma semplice (T0) era stato bloccato (0% ASR) dalla stessa difesa.
• Meccanismo: Il carrier T3 rimuove i segnali testuali al livello grezzo (float) e li frammenta al livello di ricostruzione (hex dump). Nessuna delle viste testuali ispezionate contiene prove testuali dell'attacco.
• Replicazione: Un rilevatore roberta-base fine-tuned ha replicato questo pattern, catturando tutti i carrier con prosa visibile (T0, T2) ma mancando completamente T3 (0% rilevazione). La fiducia massima del classificatore sui campioni T3 era 0,225, ben al di sotto della soglia di 0,5.

Analisi di Ablazione (Decomposizione 2x2)

Un'ablazione 2x2 ha isolato i meccanismi necessari per l'evasione:

• T0 (Prosa/Prosa): Catturato a entrambi i livelli.
• T2 (Stego/Prosa): Eluso all'ispezione del livello raw ma catturato alla ricostruzione (prosa visibile).
• T1b-abl (Prosa/Hex): Eluso all'ispezione del livello di ricostruzione (prosa) ma catturato all'ispezione del livello raw.
• T3 (Stego/Hex): Eluso da entrambi i livelli.
  Ciò conferma che sia la steganografia del livello dati che la frammentazione del livello di ricostruzione sono necessarie per sconfiggere l'ispezione testuale a doppio strato.

Prestazioni Specifiche del Modello

• GPT-5.4: ASR più alto (68,5% complessivo, 97,0% per T3 sotto il classificatore).
• Claude Sonnet 4.6: ASR più basso (50,8% complessivo) principalmente a causa dei rifiuti, sebbene T3 abbia comunque raggiunto un ASR del 92,3% sotto la difesa del classificatore.
• Strong ASR: Anche con la difesa del classificatore, T3 ha ottenuto un successo strutturalmente conforme significativo (ad es. 81,6% per l'iniezione di metadati fabbricati), dimostrando che i sistemi a valle possono agire sui marker riprodotti anche se il modello "rifiuta" l'imperativo.

Confini di Rilevazione

• Zero-Shot Prompt Guard 2: Ha rilevato lo 0% dei payload, inclusi i testi in prosa (T0). Gli autori interpretano questo come un mismatch di ambito fuori distribuzione (i modelli guard mirano a override imperativi, mentre i payload sono metadati dichiarativi), non come un fallimento architettonico generale.
• Patch Consapevole del Formato: Un semplice detector di linee xxd aggiunto allo schema gate ha ridotto l'ASR di T3 allo 0%. Tuttavia, gli autori notano che si tratta di una firma specifica della presentazione, non di una difesa generale contro la classe di carrier.

Significato e Rivendicazioni

Il documento non sostiene di aver presentato un exploit indetectabile o una vulnerabilità universale in tutte le pipeline di input strutturato. Invece, stabilisce un confine di fallimento riproducibile per l'ispezione basata solo sul testo in specifiche architetture di pipeline.

1. Limiti delle Difese Centrate sul Testo: Il contributo primario è dimostrare che quando una pipeline ammette un carrier in cui il segnale malevolo non è visibile come testo finché (o se) non entra nel contesto del modello, le guardrail basate solo sul testo (Prompt Guard, Llama Guard, regex) sono insufficienti.
2. Carrier vs Contenuto: Lo studio dimostra che è il carrier a determinare la rilevabilità, non il contenuto del payload. Lo stesso payload viene bloccato quando visibile come prosa, ma ha successo quando nascosto in float e frammentato come hex.
3. Rischio dei Metadati Dichiarativi: L'attacco ha successo perché i payload sono inquadrati come metadati dichiarativi (ad es. "token di configurazione di audit") piuttosto che come istruzioni imperative. Ciò elude le difese addestrate a rifiutare gli override imperativi, sfruttando un mismatch nelle distribuzioni dell'addestramento alla sicurezza.
4. Ambito Modesto: Gli autori dichiarano esplicitamente che il contributo non è un exploit indetectabile. L'attuale implementazione di T3 è rilevabile tramite validazione semantica (controllo di validi attrattori IFS) o detector specifici del formato hex-dump. La significatività risiede nell'identificare le condizioni specifiche (ricostruzione affidabile di canali numerici ausiliari) in cui le assunzioni di sicurezza basate sul testo falliscono.