💬 NLP

Ghost Tool Calls: Issue-Time Privacy for Speculative Agent Tools

Dieses Paper identifiziert „Ghost Tool Calls“ als eine Datenschutzanfälligkeit, bei der spekulative Werkzeugaufrufe die Benutzerabsicht gegenüber externen Beobachtern preisgeben, bevor ein Agent sich für einen Zweig entscheidet, und schlägt „Speculative Tool Privacy Contracts“ als eine Laufzeitabstraktion vor, die dieses Risiko mildert, indem sie zum Zeitpunkt der Erstellung Richtlinien erzwingt, um Argumente und Ziele vor dem Dispatch zu ändern oder zu unterdrücken.

Ursprüngliche Autoren: Bardia Mohammadi, Lars Klein, Akhil Arora, Laurent Bindschaedler

Veröffentlicht 2026-06-02

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Bardia Mohammadi, Lars Klein, Akhil Arora, Laurent Bindschaedler

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie stellen einen sehr effizienten, aber etwas übereifrigen persönlichen Assistenten ein, der Ihnen bei einem kniffligen Problem helfen soll. Sagen wir, Sie fragen: „Was ist die Strafe, wenn ich meinen Mietvertrag vorzeitig kündige?“

Ein normaler Assistent würde denken: „Okay, ich muss das Mietrecht recherchieren“, danach suchen und Ihnen dann die Antwort geben.

Aber ein spekulativer Assistent (die Art von Assistent, über die dieses Paper spricht) versucht, super schnell zu sein. Er denkt: „Ich weiß, was der Nutzer als Nächstes brauchen könnte! Vielleicht sucht er nach Wohnungen. Vielleicht macht er sich Sorgen um Geld, also werde ich die Kreditzinsen prüfen. Und für alle Fälle werde ich auch die Räumungsgesetze nachschlagen.“

Er sendet all diese Anfragen gleichzeitig ab, während er noch dabei ist zu entscheiden, was eigentlich die richtige Antwort ist.

Das Problem: „Ghost Calls“ (Geisteraufrufe)

Hier ist der Haken: Der Assistent entscheidet schließlich: „Eigentlich brauchte ich nur die Suche nach dem Mietrecht.“ Er verwendet dieses Ergebnis, um Sie zu antworten. Aber die anderen Anfragen – die Wohnungssuche und die Prüfung der Kreditzinsen – wurden bereits ins Internet gesendet, bevor der Assistent sie abbrechen konnte.

Das Paper nennt diese abgebrochenen Anfragen „Ghost Tool Calls“ (Geister-Werkzeugaufrufe).

Obwohl der Assistent das Ergebnis nie verwendet hat, haben die Websites (die „Provider“) die Anfragen bereits erhalten. Sie haben sie protokolliert. Sie haben gesehen, dass Sie nach Wohnungen und Krediten gesucht haben. Der Assistent kann diese Geister nicht „zurückrufen“. Der Schaden entsteht in dem Moment, in dem die Anfrage das Gehirn des Assistenten verlässt, nicht erst, wenn der Assistent entscheidet, das Ergebnis zu verwenden.

Das Missverständnis

Aktuelle Sicherheitsregeln sind wie ein Türsteher in einem Club, der Ihren Ausweis erst prüft, nachdem Sie bereits das Gebäude betreten haben. Er fragt: „Hatten Sie die Erlaubnis einzutreten?“, aber er verhindert nicht, dass Sie durch die Tür gehen und einen Fußabdruck auf dem Teppich hinterlassen, noch bevor Sie überhaupt zugelassen wurden.

Das Paper argumentiert, dass wir für den Datenschutz die Anfrage prüfen müssen, bevor sie das Gebäude verlässt (zum Zeitpunkt der Erstellung/„Issue-Time“). Sobald ein Ghost Call das Internet erreicht, ist es zu spät, um ihn aufzuräumen.

Die Lösung: „Privacy Contracts“ (Datenschutzverträge)

Die Autoren schlagen ein neues System vor, das „Speculative Tool Privacy Contracts“ genannt wird. Denken Sie an eine strikte „Pre-Flight-Checkliste“ für jede einzelne Anfrage, die der Assistent senden möchte.

Bevor der Assistent eine Anfrage an die Außenwelt sendet, prüft ein „Monitor“ (der Sicherheitswächter) die Anfrage gegen einen Vertrag. Der Vertrag enthält einige Regeln:

Rewrite (Umschreiben): Wenn die Anfrage sagt: „Suche nach meiner spezifischen Wohnung“, ändert der Wächter sie in „Suche nach generischen Wohnungen“, bevor sie versendet wird. Die Website erhält zwar eine Anfrage, aber sie weiß nichts über Ihre spezifische Situation.
Shadow (Schatten): Wenn die Anfrage zu sensibel ist (wie das Prüfen von Kreditzinsen), sendet der Wächter sie gar nicht erst an die echte Website. Stattdessen verwendet der Wächter eine sichere, lokale „Dummy“-Version, um eine grobe Antwort zu erhalten. Die echte Website sieht die Anfrage nie.
Wait (Defer/Aufschieben): Wenn der Assistent sich noch nicht sicher ist, ob er die Anfrage benötigt (geringe Konfidenz), hält der Wächter die Anfrage zurück und wartet, bis der Assistent sich zu 100 % sicher ist. Wenn der Assistent seine Meinung ändert, wird die Anfrage nie gesendet.
Block (Blockieren): Wenn die Anfrage verboten ist, wird sie sofort gestoppt.

Was sie herausgefunden haben

Die Forscher haben dieses System mit verschiedenen „Wächtern“ und verschiedenen Arten von Assistenten getestet. Hier ist, was sie entdeckten:

Das Aufräumen im Nachhinein funktioniert nicht: Wenn man versucht, das Protokoll zu löschen, nachdem die Anfrage gesendet wurde, ist es zu spät. Die Website hat es bereits gesehen.
Nur „Read Only“ (Nur Lesen) zu sagen, reicht nicht aus: Selbst wenn der Assistent nur Daten liest (nichts verändert), reicht bereits der Akt des Fragens aus, um Ihre Geheimnisse preiszugeben.
Die „Rewrite“- und „Shadow“-Wächter funktionieren am besten: Indem sie die Wörter vor dem Versenden ändern oder eine lokale Fake-Version verwenden, konnten sie erfolgreich verhindern, dass die Websites Ihre Geheimnisse erfahren.
Geschwindigkeit vs. Datenschutz: Das System kann trotzdem schnell sein. Die „Wächter“ haben die Abläufe nicht wesentlich verlangsamt, und sie konnten erfolgreich verhindern, dass die „Geister-Informationen“ durchsickern.

Das Fazit

Wenn KI-Agenten versuchen, schnell zu sein, indem sie erraten, was Sie als Nächstes benötigen, leaken sie versehentlich Ihre Geheimnisse ins Internet, noch bevor sie überhaupt wissen, ob sie recht hatten. Um dies zu beheben, können wir nicht einfach später das Chaos beseitigen. Wir müssen einen Filter auf die Anfragen setzen, bevor sie das Haus verlassen, indem wir die sensiblen Teile ändern oder verbergen, sodass die Außenwelt die „Geister“ niemals sieht.

Technisches Resümee: Ghost Tool Calls: Issue-Time Privacy für spekulative Agenten-Tools

1. Problemstellung

Werkzeug-erweiterte Sprachagenten setzen zunehmend auf spekulative Ausführung (speculative execution), um die Latenz zu reduzieren. In diesem Paradigma prognostiziert eine Agenten-Runtime wahrscheinliche zukünftige Werkzeugaufrufe und versendet diese parallel, während der Planer noch entscheidet, welchen Zweig der Ausführung er final festlegen (commit) soll. Während dies die Performance verbessert, führt es zu einem neuartigen Datenschutzversagen, das die Autoren als Ghost Tool Calls bezeichnen.

Ein Ghost Tool Call ist ein verworfener spekulativer Aufruf, der an einen externen Beobachter (z. B. einen Suchanbieter, einen API-Endpunkt oder einen Netzwerkmonitor) versendet wurde, aber nie in den finalen, festgeschriebenen Plan des Agenten übernommen wurde. Da diese Aufrufe getätigt werden, bevor der Agent sich auf einen spezifischen Workflow festlegt, leaken sie inferierte Nutzerintentionen (Themen, Entitäten und potenzielle Folgeschritte) an externe Dienste.

Das Kernproblem ist zeitlicher Natur: Sobald ein externer Beobachter einen spekulativen Aufruf erhält, werden die Informationen in den Protokollen, Caches oder Netzwerkspuren des Anbieters gespeichert. Standardmäßige Datenschutzmechanismen greifen hier nicht, weil:

Cleanup zum Zeitpunkt des Commits (commit-time cleanup) unwirksam ist; der Beobachter hält die Daten bereits.
Read-only-Beschränkungen (z. B. die Erlaubnis, nur für Read-only-Tools zu spekulieren) die Leckage von Intentionen über Argumente oder Ziel-Endpunkte nicht verhindern.
Zugriffskontroll-Allow-Lists den Aufruf zulassen, wenn das Werkzeug autorisiert ist, ungeachtet dessen, ob der Zweig später verworfen wird.

Die Autoren argumentieren, dass Datenschutz für spekulative Agenten eine Issue-Time-Policy erfordert – eine Entscheidung zum Zeitpunkt der Ausgabe, die getroffen werden muss, bevor der Aufruf die vertrauenswürdige Runtime-Grenze überschreitet, statt einer Entscheidung zum Zeitpunkt des Commits.

2. Methodik und Framework

Das Trace-Modell

Die Autoren formalisieren die Datenschutzlücke mittels eines Trace-Modells, das zwei Sequenzen vergleicht:

Issued Trace ( $S$ ): Das geordnete Protokoll aller versendeten Tool-Events, einschließlich spekulativer Events.
Committed Trace ( $C$ ): Die geordnete Teilsequenz der Events, die der Agent letztlich tatsächlich verwendet.
Ghost Calls: Events in $S \setminus C$ .
Marginale Exposition ( $\Delta_i$ ): Die Differenz zwischen dem, was ein Beobachter $i$ im spekulativen Trace ( $O_i(S)$ ) sieht, gegenüber dem kontrafaktischen, nur aus Commits bestehenden Trace ( $O_i(C)$ ). Dies repräsentiert die zusätzlichen Informationen, die allein durch die Spekulation preisgegeben werden.

Das Modell identifiziert drei Offenlegungskanäle:

Argumente: Die wörtliche Nutzlast (z. B. Suchanfragen).
Destination: Der aufgerufene Endpunkt oder die aufgerufene Sammlung (z. B. eine HR-Urlaubs-API vs. eine allgemeine Suche).
Metadaten: Timing, Reihenfolge, Anzahl der Retries und Cache-Zustände.

Speculative Tool Privacy Contracts

Um den Datenschutz an der Issue-Time-Grenze zu gewährleisten, schlägt das Paper Speculative Tool Privacy Contracts vor. Dies ist eine Runtime-Abstraktion, die „Beobachtung vor dem Commit“ als einen primären Effekt behandelt, der sich von Zustandsänderungen unterscheidet.

Kernkomponenten:

Labels: Jedes spekulative Event wird mit dem Ausführungsmodus, der Effektklasse, der Beobachterklasse, der Argument-Sensitivität, der Destinations-Sensitivität und der Zweig-Konfidenz gelabelt.
Der Monitor: Eine vertrauenswürdige Komponente, die zwischen dem Planer und den externen I/O-Pfaden sitzt. Er evaluiert jedes spekulative Event vor dem Versand.
Entscheidungsfunktion: Der Monitor bildet Events auf eine von fünf Aktionen ab:
1. ALLOW: Unverändert versenden.
2. REWRITE: Transformation sensibler Argumente in generische Äquivalente vor dem Versand.
3. SHADOW: Ausführung eines vertrauenswürdigen lokalen Substituts anstelle des externen Aufrufs; das Ergebnis wird verwendet, falls der Zweig befördert wird, aber der externe Beobachter sieht niemals die ursprüngliche Anfrage.
4. DEFER: Warteschlangen des Events zur Re-Evaluierung, aber nur falls der Zweig in den festgeschriebenen Plan übernommen wird.
5. BLOCK: Das Event vollständig verwerfen.

Soundness-Invariante: Unter der Annahme vollständiger Mediation (keine Rohdatenlecks vor dem Monitor) und korrekter Labeling verhindert der Monitor, dass ein verbotenes Feld in die marginale Exposition ( $\Delta_i$ ) eines Beobachters gelangt, unabhängig davon, ob das Event später committet oder verworfen wird.

3. Zentrale Beiträge

Ghost Tool Call Konzept: Die Formalisierung von verworfenen spekulativen Aufrufen als distinkte Datenschutzbedrohung, die zwischen Issue-Time-Offenlegung und Commit-Time-Zustandsänderung unterscheidet.
Speculative Tool Privacy Contracts: Eine Runtime-Abstraktion mit konkreten Labels, einer Fünf-Aktions-Pipeline und einer Soundness-Invariante, die die Beobachtung vor dem Commit als eigenständigen Effekt behandelt.
Empirische Evaluierung: Eine umfassende Evaluierung von 12 Policies anhand von drei generierten Korpora (30-Aufgaben statisch, 150-Aufgaben gepaart und 66-Aufgaben AgentDojo) sowie einer Real-Provider-Studie (Brave Search/DuckDuckGo). Die Evaluierung nutzt mehrere Adversary-Modelle (LLMs, Keyword-Matching, TF-IDF), um die Wiederherstellung versteckter sensibler Labels zu messen.

4. Ergebnisse

Die Evaluierung vergleicht Policies basierend auf der Adversarial Recovery (die Wahrscheinlichkeit, mit der ein Angreifer ein sensibles Label aus der Projektion des Beobachters korrekt inferiert) und dem Aufgabenerfolg.

Bestätigung der Leckage: Spekulative Traces erhöhen die Leckage signifikant. In einem Benchmark mit statischem Plan stieg die Recovery-Rate von 0,44 (No-Speculation) auf 0,97 (Naive Spekulation).
Ineffektivität von Post-Hoc-Kontrollen: Policies, die nach dem Versand agieren oder auf Read-Only-Beschränkungen beruhen, konnten die Leckage nicht reduzieren:
- Late-Scrub, ACL und SIA (Speculative Interaction Agents): Diese Policies lassen die marginale Exposition intakt. SIA, welches die Spekulation auf Read-Only-Tools beschränkt, performt ähnlich schlecht wie der Naive-Baseline, da auch Read-Only-Aufrufe die Intention über Argumente und Destinationen offenbaren.
- Pre-Scrub: Die freitextliche Redaktion von Argumenten vor dem Versand ist unzureichend, wenn strukturierte Felder oder Destinationen unberührt bleiben.
Effektivität von Issue-Time-Transformationen: Nur Policies, die die Projektion vor dem Versand transformieren, reduzierten die Leckage:
- Rewrite: Das Paraphrasieren sensibler Argumente in generische Äquivalente senkte die Recovery auf nahezu das Boden-Niveau (z. B. 0,04 in Real-Planner-Szenarien).
- Shadow: Das Routing von Aufrufen an lokale Substitute reduzierte die Recovery in mehreren Benchmarks auf 0,00.
- Gate: Das Aufschieben von Low-Confidence-Aufrufen bis zur Beförderung des Zweigs reduzierte die Leckage, allerdings mit einem Trade-off bei der Utility, wenn der Schwellenwert zu streng ist.
Residueller Signalanteil: Die primären Träger der Leckage sind strukturierte Argumentfelder und Destination-URLs. Das Maskieren von Tool-Namen oder die Verwendung von Freitext-Redaktion allein stoppt die Leckage nicht, wenn die Destination oder die strukturierten Argumente das Thema verraten.
Utility vs. Privacy: Der Aufgabenerfolg blieb bei den meisten Policies hoch (0,77–0,83). Shadow und Rewrite erreichten eine Near-Zero-Leckage bei vernachlässigbarem Einfluss auf den Aufgabenerfolg, während Post-Hoc-Filter keinen Datenschutzvorteil boten.
Latenz: Der Mechanismus zur Durchsetzung der Contracts wurde nicht zum Latenz-Engpass. In Multi-Tool-Async-Workloads behielten die datenschutzfreundlichen Policies (Rewrite, Gate) Latenzvorteile ähnlich wie die Naive-Baseline bei.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass Spekulation eine Issue-Time-Privacy-Lücke erzeugt, die nicht durch traditionelle Autorisierung oder Commit-Time-Cleanup gelöst werden kann. Die Bedeutung der Arbeit liegt in:

Verschiebung der Datenschutzgrenze: Die Entscheidung über den Datenschutz wird vom Zeitpunkt des „Commits“ zum Zeitpunkt des „Issuens“ verschoben. Die Autoren argumentieren, dass der Schaden bereits entstanden ist, sobald ein Beobachter einen spekulativen Aufruf hält; daher muss die Runtime entscheiden, was gesendet wird, bevor es gesendet wird.
Neudefinition von „sicherer“ Spekulation: Das Paper zeigt, dass die Beschränkung der Spekulation auf „Read-Only“-Tools (ein gängiges Sicherheitsmuster) für den Datenschutz unzurereichend ist, da auch Read-Only-Aufrufe die Intention durch Argumente und Destinationen preisgeben. Wahrer Datenschutz erfordert die Transformation oder Unterdrückung der beobachtbaren Projektion.
Praktische Abstraktion: Die vorgeschlagenen Contracts bieten ein konkretes, implementierbares Framework (Rewrite, Shadow, Defer), das es Runtime-Systemen ermöglicht, die Latenzvorteile der Spekulation mit den Datenschutzanforderungen in Einklang zu bringen, ohne die Task-Utility zu opfern.

Die Autoren kommen zu dem Schluss, dass Spekulation zwar attraktiv für die Performance ist, aber Issue-Time-Policies erfordert, die die Argument- oder Destination-Projektion des spekulativen Aufrufs aktiv verändern oder unterdrücken, um die Preisgabe der inferierten Nutzerintention zu verhindern.