arXiv:2605.22786: LCGuard schützt geteilten KV-Cache zwischen Agenten in Multi-Agenten-Systemen vor Datenlecks

Das am 22. Mai 2026 veröffentlichte arXiv-Preprint LCGuard stellt das erste formale Framework zum Schutz des geteilten KV-Caches in Multi-Agenten-KI-Systemen vor. Das Papier ist das Ergebnis einer Zusammenarbeit zwischen IBM Research und MIT unter der Leitung von Sadie Asif. Die Autoren dokumentieren eine Schwachstelle, die in den letzten Monaten in produktiven Enterprise-Agenten-RAG-Systemen aufgetaucht ist, und schlagen eine konkrete Lösung vor, die ohne Unterbrechung der bestehenden Infrastruktur anwendbar ist.

Was ist ein geteilter KV-Cache und warum wird er verwendet?

Im klassischen KI-Workflow generiert jeder API-Aufruf einen neuen KV-Cache für den Prompt — Inferenz ist damit eine zustandslose atomare Einheit ohne aufrufübergreifenden Zustand. In Enterprise-Multi-Agenten-Systemen wird dieses Modell teuer. Wenn fünf Agenten unabhängig voneinander dasselbe vertrauliche PDF verarbeiten, baut jeder den identischen KV-Cache von Grund auf neu auf und verbraucht dabei 5× mehr GPU-Speicher und 5× mehr Rechenleistung.

Die Optimierung, die Anbieter zunehmend implementieren, ist ein geteilter KV-Cache. Das PDF wird einmal verarbeitet, der generierte KV-Cache belegt etwa 200 MB GPU-Speicher, und alle Agenten erhalten einen Pointer auf diesen Cache. Die Inferenz jedes Agenten startet aus einem vorausgefüllten Zustand und ergänzt nur das eigene spezifische Prompt-Suffix. Die Kosteneinsparung beträgt den Faktor 3–5, wie die Autoren berichten — der Unterschied zwischen einem tragfähigen und einem unwirtschaftlichen Deployment bei hohem Volumen.

Wie funktioniert das Datenleck?

Der KV-Cache ist kein Klartext — er besteht aus Embedding-Vektoren, die semantische Informationen aus dem Originaldokument enkodieren. Diese Vektoren sind jedoch nicht irreversibel transformiert. Der Attention-Mechanismus kann aus ihnen erhebliche Informationen extrahieren — durch eine Strategie, die die Autoren Attention-Probing nennen.

Ein konkreter Angriff: Agent B hat legitimen Zugang zum geteilten KV-Cache (etwa weil er ein verwandtes Dokument verarbeitet). Agent B kann spezifische Prompts erstellen, die über die Attention-Layer 5–15 auf bestimmte KV-Cache-Regionen abzielen und so einzelne sensible Entitäten aus dem Original-PDF rekonstruieren — Kundennamen, Vertragsnummern, Geldbeträge. Die Autoren zeigen, dass die Rekonstruktion nicht perfekt ist, aber einen Recall von 60–80 Prozent für Named Entities erreicht.

Der Angriffsvektor ist bedeutsam, weil Enterprise-Nutzer typischerweise darauf vertrauen, dass „ein Agent nur Zugang zu seinem eigenen Prompt hat”. Die Realität ist, dass ein Agent Zugang zum KV-Cache des gesamten geteilten Dokuments hat — was in keiner produktiven API-Dokumentation dokumentiert war.

Wie schließt LCGuard diesen Kanal?

LCGuard fügt zwei Verteidigungslinien hinzu.

Erste Linie — kryptografische Isolation: Jeder KV-Cache wird mit einem Schlüssel verschlüsselt, der von der Security-Domain-Herkunft des Dokuments abhängt. Ein Agent, der nicht zu dieser Domain gehört, kann den Cache-Hint sehen (ob er existiert und wie groß er ist), kann ihn aber nicht nutzen — die Entschlüsselung erfolgt nur, wenn der Agent das entsprechende Domain-Credential vorlegt. Ein PDF aus der Domain „finance/confidential” hat damit einen KV-Cache, den Marketing-Agenten nicht entschlüsseln können, auch wenn er physisch denselben GPU-Speicher belegt.

Zweite Linie — Laufzeit-Attention-Probe-Detektor: Das Backend überwacht Attention-Muster in Echtzeit und erkennt verdächtige Muster. Ein typischer Probe verwendet eine pseudo-zufällige Prompt-Struktur, die die Attention-Variation auf den Ziel-KV-Slots maximiert. LCGuard erkennt dieses Muster mit über 95 Prozent Präzision (die Autoren dokumentieren eine niedrige False-Positive-Rate bei 50.000 legitimen Anfragen).

Implementierungsaufwand und Kompatibilität

LCGuard erfordert eine Modifikation der Attention-Layer im Inference-Engine (vLLM, TGI, SGLang). Die Autoren haben eine Referenzimplementierung für vLLM veröffentlicht. Der Throughput-Overhead beträgt 8–12 Prozent im Worst-Case-Szenario (vollständig verschlüsselter Cache) oder 3–5 Prozent im typischen Szenario (Mischung aus verschlüsselten und unkomprimierten Cache-Regionen). Dies ist ein akzeptabler Aufwand für Enterprise-Tenants, die Compliance-Anforderungen erfüllen müssen.

Das Papier schließt mit einer Empfehlung: LCGuard sollte zum Standard für Enterprise-Deployments werden, die geteilten KV-Cache über Security-Domain-Grenzen hinweg verwenden. Ohne diesen Schutz verletzen Organisationen unwissentlich ihre eigenen Datenklassifizierungsrichtlinien.