Technisches Resümee: Denken Sie zweimal nach, bevor Sie handeln

Problemstellung

Die Integration externer Werkzeuge hat die Fähigkeiten von Large Language Model (LLM) Agenten erheblich erweitert, führt jedoch auch neue Angriffsflächen ein, die über traditionelle Prompt-Injektionen hinausgehen. Diese Arbeit identifiziert und formalisiert Cross-Tool-Description-Poisoning (Kreuz-Werkzeug-Beschreibungs-Vergiftung), einen ausgeklügelten Angriffsvektor, bei dem Angreifer die Metadaten (Beschreibungen) von nicht-kritischen oder schwach regulierten Werkzeugen manipulieren, um die Planungs-Trajektorie eines Agenten zu steuern.

Im Gegensatz zu früheren „Tool-Preference“-Angriffen, die einen Agenten dazu bringen, ein bestimmtes vergiftetes Werkzeug zu wählen, ermöglicht Cross-Tool-Description-Poisoning einem Angreifer, bösartige Aktionen unter Verwendung anderer Werkzeuge zu induzieren – selbst wenn das vergiftete Werkzeug selbst nie ausgewählt wird. Beispielsweise kann das Vergiften der Beschreibung eines harmlosen „Account Backup“-Werkzeugs dazu führen, dass der Planer einen bösartigen „Email Sender“-Schritt (z. B. das Senden von Kontodaten an einen Angreifer) in die Trajektorie einer legitimen „Banküberweisung“-Aufgabe einfügt. Die zentrale Herausforderung besteht darin, dass vergiftete Beschreibungen im Planungskontext über mehrere Schritte hinweg bestehen bleiben und so eine kontinuierliche Beeinflussung nachfolgender Werkzeugwahlen ermöglichen.

Bestehende Abwehrmethoden wie statische Werkzeugfilterung, wiederholtes Prompting oder systemseitige Einschränkungen (z. B. Drift, Progent) erwiesen sich als unwirksam gegen diese spezifische Bedrohung. Diese Methoden berücksichtigen entweder nicht den Aufgabenkontext, verlassen sich auf interne Modellzustände (die über APIs oft nicht zugänglich sind) oder können nicht zwischen der legitimen Nutzung von Werkzeugen und einer durch vergiftete Metadaten beeinflussten Nutzung unterscheiden.

Methodik: Tool-Guard

Um diese Einschränkungen zu adressieren, schlagen die Autoren Tool-Guard vor, ein neuartiges systemseitiges Verteidigungssystem, das auf dem Konzept der isolierten Planung basiert. Die Kernphilosophie besteht darin, das Sicherheitsprinzip der Isolation auf die agentische Planung anzuwenden und die Verbindung zwischen vergifteten Beschreibungen und dem beabsichtigten Ziel der Beeinflussung zu unterbrechen, ohne die Werkzeuge dauerhaft zu deaktivieren.

Kernmechanismus

Tool-Guard arbeitet durch eine dynamische, iterative Schleife, die drei Hauptphasen umfasst:

1. Dynamische Partitionierung des Werkzeugsatzes:
   Das System führt eine dynamische Partitionierung des verfügbaren Werkzeugsatzes $K$ in zwei disjunkte Listen durch:

   • Influenced List ($K_{inf}$): Enthält Werkzeuge, die Verdacht der Beeinflussung durch vergiftete Beschreibungen unterliegen (anfänglich leer).
   • Others List ($K_{others}$): Enthält die verbleibenden Werkzeuge.
     Werkzeuge werden nicht als bösartig vorausgesetzt; vielmehr werden sie in $K_{inf}$ verschoben, wenn ihr Aufruf als nicht mit der Benutzerabsicht übereinstimmend oder schlecht im Kontext begründet erscheint.

2. Isolierte Planung:
   Anstatt den Planer mit dem vollständigen Werkzeugsatz abzufragen, fragt Tool-Guard den Planer zweimal unter strikter Isolation ab:

   • Einmal nur mit den Beschreibungen in $K_{inf}$.
   • Einmal nur mit den Beschreibungen in $K_{others}$.
     Dies verhindert, dass eine vergiftete Beschreibung in einer Teilmenge die Auswahl oder Parametrisierung von Werkzeugen in der anderen Teilmenge steuert. Das System wählt dann eine Kandidatenaktion aus den beiden resultierenden Plänen aus. Wenn beide Teilmengen gültige Aktionen liefern, wird ein Tie-Breaker angewendet; wenn keine von beiden dies tut, wird die Trajektorie terminiert.

3. Validierung vor der Ausführung und Listenaktualisierung:
   Vor der Ausführung eines ausgewählten Werkzeugaufrufs führt Tool-Guard zwei semantische Prüfungen mittels eines LLM-basierten Validators durch:

   • Alignment Check (Abgleich der Übereinstimmung): Überprüft, ob die Aktion konsistent mit der Absicht des Benutzers und dem validierten Fortschritt ist.
   • Suspicion Check (Verdachtsprüfung): Überprüft, ob die Argumente in der Benutzeranfrage oder in vorherigen Werkzeugausgaben begründet sind, und markiert sensible Entitäten (z. B. Empfängeradressen), denen eine klare Herkunft fehlt.

   Falls die Validierung fehlschlägt, wird das Werkzeug in die Influenced List verschoben und der Planer wird getriggert, die Planung unter der aktualisierten Partition neu zu starten (replan). Dieser iterative Prozess isoliert schrittweise schädliche Beeinflussungspfade, während die Nützlichkeit legitimer Werkzeuge erhalten bleibt.

Erweiterung auf MCP

Die Methodik lässt sich auf das Model Context Protocol (MCP) erweitern, indem dieselbe Isolationslogik auf der Serverebene angewendet wird, wobei Server in beeinflusste und nicht-beeinflusste Gruppen unterteilt werden, um eine Cross-Server-Vergiftung zu verhindern.

Wichtige Beiträge

1. Charakterisierung von Cross-Tool-Description-Poisoning: Die Arbeit zeigt, dass Angreifer bösartige Schritte in sicherheitskritische Werkzeugaufrufe injizieren können, indem sie unkritische Werkzeugbeschreibungen vergiften, selbst wenn das vergiftete Werkzeug nie aufgerufen wird. Es wird aufgezeigt, dass bestehende Abwehrmethoden eine hohe Attack Success Rate (ASR) gegenüber dieser kontinuierlichen Beeinflussung aufweisen.
2. Tool-Guard Verteidigung: Die Autoren schlagen eine Verteidigung vor, die den Werkzeugsatz dynamisch partitioniert und eine isolierte Planung einsetzt. Durch die Validierung von Aktionen vor der Ausführung und die Isolierung verdächtiger Werkzeuge unterbindet sie bösartige Cross-Tool-Steuerpfade, während die volle Verfügbarkeit der Werkzeuge erhalten bleibt.
3. Umfassende Evaluierung: Umfangreiche Experimente auf den Benchmarks AgentDojo und ASB (Agent Security Bench) zeigen, dass Tool-Guard die ASR auf vernachlässigbare Werte reduziert, während eine hohe Aufgaben-Utilität bewahrt wird. Die Arbeit quantifiziert zudem Effizienz und Robustheit gegenüber adaptiven Angriffsvarianten.

Experimentelle Ergebnisse

Die Autoren evaluierten Tool-Guard gegen fünf bestehende Verteidigungsmechanismen (System Prompt, Tool Filtering, Repeat Prompt, Drift, Progent) über mehrere LLMs (GPT-4o, GPT-4o-mini, Gemini-2.5, Claude-3.5) auf zwei Benchmarks.

• Attack Success Rate (ASR): Tool-Guard reduzierte die ASR auf vernachlässigbare Werte (z. B. von ~43% auf ~2% oder 0% auf AgentDojo, und von ~72-96% auf 0% auf ASB für die meisten Modelle). Im Gegensatz dazu scheiterten bestehende Abwehrmethoden oft daran, die ASR signifikant zu senken (z. B. zeigten Drift und Progent ASRs von 24,7% bzw. 19,6% auf AgentDojo).
• Erhalt der Utilität: Tool-Guard behielt eine hohe Aufgaben-Utilität sowohl unter benignen als auch unter Angriffsbedingungen bei. Im Gegensatz zu „Over-kill“-Verteidigungen, die Werkzeuge wahllos blockieren, bewahrte Tool-Guard die Fähigkeit zur Aufgabenbewältigung, wobei die Utilitätswerte vergleichbar mit oder besser als die der Baselines unter Angriff waren.
• Effizienz:
  • Token-Overhead: Tool-Guard verursachte eine etwa 1,5-fache Steigerung des Token-Verbrauchs im Vergleich zur No-Defense-Baseline, was signifikant niedriger ist als bei anderen systemseitigen Verteidigungen wie Drift oder Progent.
  • Latenz: Die Methode führte einen Laufzeit-Overhead von etwa dem 3,7-fachen im Vergleich zur Baseline ein (höher als die 1,2-fache von Progent, aber niedriger als die 7,3-fache von Drift), was auf den Replanning-Mechanismus zurückzuführen ist.
• Robustheit:
  • Stabilität: Die Verteidigung blieb über mehrere Durchläufe mit geringen Standardabweichungen stabil.
  • Adaptive Angriffe: Tool-Guard blieb robust gegenüber semantisch-adaptiven Angriffen (die versuchen, Checks durch fingierte Rechtfertigungen zu umgehen) und optimierungsbasierten Angriffen (PAIR, TAP). Während optimierungsbasierte Angriffe die ASR leicht erhöhten, blieb diese sehr niedrig (z. B. 2,06% unter PAIR), was den inhärenten Trade-off verdeutlicht, vor dem Angreifer stehen: Man muss explizit genug sein, um die Planung zu beeinflussen, aber subtil genug, um die Validierung zu umgehen.
  • Stresstests: Selbst wenn kritische, hochfrequente Werkzeuge vergiftet wurden, hielt Tool-Guard die ASR auf einem niedrigen einstelligen Niveau.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass Werkzeugbeschreibungen eine kritische, bisher wenig erforschte Angriffsfläche für LLM-Agenten darstellen. Die Bedeutung dieser Arbeit liegt in:

1. Identifizierung eines neuen Angriffsvektors: Die Formalisierung von Cross-Tool-Description-Poisoning, das traditionelle Abwehrmethoden umgeht, indem es die persistente Natur von Werkzeug-Metadaten im Planungskontext ausnutzt.
2. Aufzeigen der Grenzen bestehender Abwehr: Der Nachweis, dass aktuelle State-of-the-Art-Verteidigungen gegen kontinuierliche Cross-Tool-Beeinflussung unzureichend sind.
3. Vorschlag einer systemseitigen Lösung: Einführung von Tool-Guard, das diese Angriffe effektiv mildert, indem es Einfluss isoliert, anstatt sich nur auf Ausführungszeit-Sicherheitsmaßnahmen oder statische Scans zu verlassen.
4. Balance zwischen Sicherheit und Utilität: Der Beweis, dass effektive Verteidigung nicht die Aufgabe der Agent-Utilität erfordert; Tool-Guard erreicht robuste Sicherheit mit minimalem Token-Overhead und ohne „Over-kill“-Verhalten.

Die Autoren kommen zu dem Schluss, dass effektive Abwehrmethoden für werkzeuggestützte LLM-Agenten explizit die Cross-Tool-Beeinflussung durch Mechanismen wie isolierte Planung adressieren müssen, anstatt sich allein auf Prompt-Injection-Verteidigungen oder statische Werkzeugfilterung zu verlassen.