CIPL: A Target-Independent Framework for Channel-Inversion Privacy Leakage in Agents

1. Il Problema: La Privacità oltre la Memoria

Le attuali ricerche sulla privacy nei sistemi di Agenti basati su Large Language Model (LLM) si concentrano prevalentemente sulla fuga di dati dalla memoria (memory leakage). Studi precedenti, come MEXTRA, hanno dimostrato che gli attaccanti possono estrarre record privati recuperati dalla memoria dell'agente tramite prompt ingannevoli.

Tuttavia, questo approccio è limitato perché:

• Considera la memoria come l'unico vettore di rischio.
• Le formulazioni degli attacchi sono spesso legate a sistemi specifici e a superfici di output particolari.
• Ignora il fatto che le informazioni sensibili possono fluire attraverso altre fasi del pipeline dell'agente (es. documenti recuperati in RAG, argomenti di chiamate a strumenti, risultati intermedi) ed essere esposte attraverso canali osservabili diversi dalla risposta testuale finale.

Il paper pone l'ipotesi che il rischio di privacy non derivi solo da dove sono archiviati i dati, ma da come la dipendenza interna dell'agente da tali dati sensibili può essere "invertita" per generare un segnale osservabile dall'esterno.

2. Metodologia: Il Framework CIPL

Gli autori introducono CIPL (Channel Inversion for Privacy Leakage), un framework indipendente dal target che formalizza la fuga di dati come un problema di inversione di canale.

A. Formulazione del Problema

Il sistema agente è modellato come una pipeline a cinque stadi:

1. Sorgente Sensibile ($S$): Memoria, documenti recuperati, output di strumenti.
2. Selezione ($Sel$): Quale contenuto sensibile viene selezionato per il contesto corrente.
3. Assemblaggio ($Asm$): Integrazione del contenuto nel contesto o nell'azione.
4. Esecuzione ($Exec$): Elaborazione da parte del modello/agente.
5. Osservazione ($Obs$): L'artefatto visibile all'attaccante (testo libero, output strutturato, argomenti di tool, ecc.).

L'obiettivo dell'attaccante è invertire la dipendenza interna (il fatto che il sistema abbia usato $S$) in un segnale esterno recuperabile ($o$).

B. Firma del Target (Target Signature)

CIPL rappresenta qualsiasi sistema agente tramite una firma comune:
$$\tau = (S, Sel, Asm, Exec, Obs, Ext)$$
Dove $Ext$ è la mappa di estrazione specifica dal canale osservabile alle unità di fuga. Questo permette di confrontare sistemi eterogenei (agenti con memoria, RAG, tool-calling) sotto un'unica lente metodologica.

C. Linguaggio di Attacco Indipendente dal Target

Invece di prompt specifici, CIPL utilizza un linguaggio di attacco riutilizzabile composto da tre componenti:

1. Locator (Localizzatore): Identifica e indirizza l'attacco verso il contenuto interno sensibile specifico (es. un record di memoria o un documento recuperato) piuttosto che l'intero contesto.
2. Aligner (Allineatore): Mappa il contenuto sensibile su un canale di output valido per quel target specifico (es. richiedere che i dati appaiano in un campo strutturato o come argomento di una chiamata a uno strumento, non solo nella risposta finale).
3. Diversification Policy (Politica di Diversificazione): Gestisce il budget di attacco distribuendo le query per massimizzare la copertura delle unità sensibili e ridurre le sovrapposizioni.

3. Contributi Chiave

1. Formalizzazione Generale: La fuga di memoria è riclassificata come un caso particolare di un meccanismo più ampio di fuga attraverso canali di osservazione.
2. Framework Unificato (CIPL): Un metodo indipendente dal target che standardizza l'analisi della privacy attraverso una firma comune e un linguaggio di attacco riutilizzabile.
3. Validazione Sperimentale: Implementazione di CIPL su quattro target diversi (agenti basati su memoria, sistemi RAG, e flussi di lavoro con strumenti) per dimostrare la trasversalità del metodo.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su tre provider di modelli (MiniMax-M2.5, qwen3.5-plus, DeepSeek) utilizzando quattro target:

• Memory-based: memory_ehr (agenti medici) e memory_rap (agenti web).
• RAG: rag_toy (recupero documenti).
• Tool-calling: tool_mock (fuga tramite argomenti di tool o echo dei risultati).

Principali scoperte:

• Memoria come Superficie Critica: Gli agenti basati su memoria rimangono le superfici più vulnerabili, con tassi di estrazione completa (CER) e parziale (AER) spesso vicini al 100% (es. memory_rap su tutti i provider).
• Fuga Non-Memoria: Anche i canali non legati alla memoria sono vulnerabili, ma con pattern diversi:
  • RAG: Mostra una fuga "frequente ma incompleta" (alto AER, basso CER). Il modello espone prove sensibili senza necessariamente copiarle integralmente.
  • Tool-calling: La fuga dipende fortemente dal canale di osservazione. L'echo dei risultati degli strumenti (return_echo) è spesso più facile da invertire rispetto agli argomenti della chiamata (args_exfil), specialmente su modelli meno saturi.
• Dipendenza dal Provider: La robustezza varia significativamente tra i modelli. DeepSeek ha mostrato una fuga quasi saturo su tutti i canali, mentre altri provider hanno mostrato maggiori variazioni.
• Trade-off Esposizione-Stabilità: Aumentare la profondità di recupero (più dati sensibili nel contesto) non aumenta linearmente la fuga. In alcuni casi (es. MiniMax su RAG), un contesto troppo ricco destabilizza la pipeline, riducendo la fuga ma aumentando gli errori di esecuzione.

5. Significato e Implicazioni

Il paper propone un cambio di paradigma fondamentale nella valutazione della sicurezza degli agenti LLM:

1. Dall'Archiviazione ai Canali: La valutazione della privacy non deve limitarsi a "è la memoria sicura?", ma deve chiedersi "come i dati sensibili vengono instradati verso canali osservabili?".
2. Superfici di Attacco Multiple: Le superfici di attacco includono non solo la risposta finale, ma anche gli output strutturati, gli argomenti delle chiamate agli strumenti, i log intermedi e gli echo dei tool.
3. Metodologia di Valutazione: È necessario adottare metriche che distinguano tra esposizione interna (quanti dati sono stati usati) e fuga esterna (quanti dati sono stati recuperabili). Metriche come CER (Complete Extraction Rate) e AER (Any Extracted Rate) sono essenziali per catturare sfumature come la fuga parziale.
4. Red Teaming Orientato ai Canali: I test di sicurezza (red-teaming) per gli agenti devono essere organizzati attorno ai canali di osservazione, non solo alla correttezza del compito finale.

In conclusione, CIPL dimostra che il rischio di privacy è intrinseco al design del flusso di informazioni dell'agente. Qualsiasi utilizzo interno di dati sensibili crea il potenziale per un'inversione di canale, rendendo necessari controlli di sicurezza che coprano l'intero pipeline di osservazione e non solo i componenti di archiviazione.