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

1. Problemstellung

Große Sprachmodell-Agenten (LLM-Agenten) verarbeiten zunehmend sensible Benutzerdaten (z. B. historische Interaktionen, abgerufene Dokumente, Tool-Ausgaben). Bisherige Sicherheitsforschung konzentrierte sich stark auf Speicherlecks (Memory Leakage), bei denen Angreifer über spezielle Prompts gespeicherte Erinnerungen extrahieren (z. B. durch den Angriff MEXTRA).

Das Paper identifiziert jedoch eine wesentliche Lücke:

• Begrenzte Sichtweise: Aktuelle Angriffsformulierungen sind oft an spezifische Systeme oder Ausgabeschnittstellen gebunden.
• Übersehene Kanäle: Sensible Informationen werden nicht nur durch die finale Textantwort offengelegt, sondern können über jeden beobachtbaren Artefakt fließen, der von einem internen, privaten Zustand abhängt (z. B. strukturierte Ausgaben, Tool-Aufruf-Argumente, Tool-Rückgabewerte oder Zwischenzustände).
• Zentrale Frage: Unter welchen Bedingungen kann ein Angreifer eine interne Abhängigkeit von sensiblen Daten in ein für ihn beobachtbares Signal umwandeln, unabhängig davon, wo die Daten gespeichert sind?

2. Methodik: Das CIPL-Framework

Die Autoren stellen CIPL (Channel Inversion for Privacy Leakage) vor, ein zielunabhängiges Framework, das Privatsphären-Lecks als Kanal-Inversionsproblem formuliert.

A. Problemformulierung (Kanal-Inversion)

Das System wird als eine Pipeline aus fünf Stufen modelliert:

1. Sensibler Quellcode ($S$): Speicher, abgerufene Dokumente, Tool-Ergebnisse.
2. Selektion ($Sel$): Auswahl sensibler Inhalte ($z$) basierend auf der Eingabe.
3. Zusammenstellung ($Asm$): Einbettung von $z$ in den Kontext oder die Aktion ($x$).
4. Ausführung ($Exec$): Verarbeitung durch den Agenten zu einem Ergebnis ($y$).
5. Beobachtung ($Obs$): Das für den Angreifer sichtbare Artefakt ($o$).

Das Ziel des Angreifers ist es, die interne Abhängigkeit ($z \to y$) so zu manipulieren, dass $z$ durch den Beobachtungskanal ($o$) rekonstruierbar wird. Dies wird als Inversion des Kanals betrachtet.

B. Ziel-Signatur (Target Signature)

Um verschiedene Systeme vergleichbar zu machen, definiert CIPL eine gemeinsame Signatur $\tau = (S, Sel, Asm, Exec, Obs, Ext)$. Dies erlaubt es, Speicher-basierte Agenten, RAG-Systeme (Retrieval-Augmented Generation) und Tool-calling-Workflows unter einem einheitlichen mathematischen Modell zu analysieren.

C. Zielsprache für Angriffe (Attack Language)

Anstatt system-spezifische Prompts zu entwickeln, verwendet CIPL eine wiederverwendbare Angriffssprache, bestehend aus drei Komponenten:

1. Locator: Identifiziert und steuert den Agenten auf spezifische interne Objekte (z. B. „wähle das Dokument X" statt „wiederhole alles").
2. Aligner: Passt die geforderte Ausgabe an den gültigen Beobachtungskanal des Zielsystems an (z. B. Ausgabe als JSON-Argument, Tool-Rückgabe oder strukturierte Liste, nicht nur als Freitext).
3. Diversifizierungsrichtlinie: Verteilt das Angriffsbudget über mehrere Anfragen, um die Abdeckung der geleakten Einheiten zu maximieren und Überlappungen zu minimieren.

3. Wichtige Beiträge

1. Generalisierung des Leckage-Problems: Die Autoren zeigen, dass Memory-Extraktion nur ein Spezialfall eines allgemeineren Problems ist: der Inversion von internen Abhängigkeiten in beobachtbare Kanäle.
2. Zielunabhängiges Framework: CIPL ermöglicht den direkten Vergleich von Privatsphären-Risiken über heterogene Architekturen hinweg, ohne diese künstlich zu vereinheitlichen.
3. Neue Metriken: Unterscheidung zwischen interner Exposition (welche Daten wurden ausgewählt?) und externer Leckage (welche Daten wurden tatsächlich rekonstruiert?). Dies ist entscheidend, da nicht jede interne Nutzung zu einem vollständigen Leak führt.

4. Ergebnisse und Experimente

Die Autoren evaluierten CIPL an vier Zieltypen über drei Kategorien (Memory, RAG, Tools) und drei verschiedene LLM-Backbones (MiniMax-M2.5, qwen3.5-plus, DeepSeek).

• Memory-basierte Ziele: Zeigten das höchste Leckage-Risiko. Bei memory_rap erreichten alle Provider eine vollständige Extraktion (CER/AER = 1.0). Dies bestätigt, dass CIPL bekannte Memory-Angriffe korrekt rekapituliert.
• RAG-Ziele (Retrieval-Augmented): Zeigten ein Muster von „häufiger, aber unvollständiger Leckage". Oft wurden Teile der sensiblen Daten offengelegt (hoher AER), aber selten der gesamte Satz exakt kopiert (niedriger CER). Dies zeigt, dass RAG-Systeme auch ohne Memory-Module anfällig sind.
• Tool-basierte Ziele: Die Leckage hing stark vom Beobachtungskanal ab.
  • Return_Echo (Rückgabe des Tools) war oft anfälliger als Args_Exfil (Argumente des Tool-Aufrufs).
  • Die Ergebnisse variierten stark zwischen den Providern (z. B. war DeepSeek anfälliger als MiniMax oder Qwen), was zeigt, dass das Modell selbst ein Sicherheitsfaktor ist.
• Einflussfaktoren:
  • Prompt-Stärke: Ohne explizite Extraktionsanweisungen (Weak-Prompt-Controls) brach die Leckage fast vollständig zusammen, was beweist, dass die Angriffe aktiv induziert werden.
  • Tiefe der Suche (Retrieval Depth): Eine Erhöhung der Anzahl abgerufener Dokumente führte nicht linear zu mehr Leckage. Bei manchen Modellen führte dies zu Instabilität und Fehlern, was die Leckage sogar reduzierte.

5. Bedeutung und Schlussfolgerung

Das Paper liefert einen Paradigmenwechsel für die Sicherheitsbewertung von LLM-Agenten:

• Von Speicher zu Kanälen: Die Sicherheitsanalyse darf sich nicht nur auf den Schutz von Speichermodulen konzentrieren. Stattdessen muss der gesamte Pfad betrachtet werden, über den sensible Daten in beobachtbare Kanäle (Text, JSON, Tool-Logs, Argumente) fließen.
• Ganzheitliche Red-Teaming-Strategie: Agenten sollten nicht nur auf Aufgabenkorrektheit, sondern auch auf die Kanäle ihrer Informationsfreigabe getestet werden.
• Architektur-Abhängigkeit: Das Risiko ist nicht statisch; es hängt von der Kombination aus Systemdesign (welche Kanäle existieren?), dem LLM-Provider (wie stark filtert das Modell?) und der Stabilität des Pipelines ab.

Fazit: CIPL etabliert einen standardisierten, wiederverwendbaren Ansatz, um zu verstehen, wie interne private Abhängigkeiten in externe Lecks umgewandelt werden können. Es fordert auf, Privatsphären-Risiken als Designproblem der Beobachtungskanäle und nicht nur als Speicherproblem zu betrachten.