prompt injections.de
Glossar

Tool Poisoning

Tool Poisoning bezeichnet eine indirekte Prompt Injection, bei der die manipulierende Anweisung nicht im Ergebnis eines Werkzeugs steht, sondern in dessen Beschreibung, Parameter-Schema oder sonstigen Metadaten. Ein Agent kann sie daher bereits verarbeiten, wenn er verfügbare Werkzeuge entdeckt und ihre Definitionen in seinen Kontext lädt, ohne das präparierte Werkzeug jemals aufzurufen.1

Einordnung

Der Begriff beschreibt einen Angriff auf die Werkzeug- und Integrationsschicht eines Agenten. Er unterscheidet sich von der üblichen indirekten Prompt Injection, bei der ein Modell erst beim Lesen einer Webseite, Datei oder Tool-Antwort auf fremde Instruktionen trifft: Hier wird die Entscheidungsebene vor der Ausführung beeinflusst. Das ist besonders relevant für MCP-ähnliche Umgebungen, weil Tool-Definitionen Namen, Beschreibungen und JSON-Schemata enthalten und Server ihre verfügbaren Tools per Listenoperation bereitstellen.2 Tool Poisoning ist weder eine Schwäche eines einzelnen Tools noch bloß eine fehlerhafte Beschreibung. Maßgeblich ist, dass nicht vertrauenswürdige Metadaten als handlungsleitende Anweisung in den Modellkontext gelangen und dadurch die Nutzung anderer, möglicherweise privilegierter Werkzeuge beeinflussen können.

Die Angriffswirkung liegt damit an der Schnittstelle von Vertrauensgrenze, Tool-Auswahl und Berechtigung. Ein unauffällig benanntes, selbst kaum berechtigtes Werkzeug kann versuchen, den Agenten zu einer Aktion über ein separates, legitimes Werkzeug zu bewegen. Forschung grenzt diesen Vor-Ausführungs-Vektor ausdrücklich von Injections in Tool-Ergebnissen ab.1 Der Ausdruck „vergiftet“ meint dabei nicht, dass der Server technisch kompromittiert sein muss: Schon eine vom Betreiber bereitgestellte, bösartige Metadatendefinition genügt.

Dokumentiertes Beispiel

Die Studie MCPTox evaluierte Tool Poisoning anhand von 45 realen MCP-Servern, 353 authentischen Tools und 1.312 konstruierten Testfällen. Sie beschreibt Szenarien, in denen eine manipulierte Tool-Beschreibung die spätere Verwendung eines anderen vorhandenen Werkzeugs beeinflusst; das vergiftete Tool selbst muss dafür nicht ausgeführt werden.1 Bereits die MCP-Sicherheitsaudit-Studie von Radosevich und Halloran zeigte Risiken wie unerwünschte Codeausführung, Fernzugriff und Zugangsdatendiebstahl in MCP-gestützten Workflows.3 Beide Arbeiten sind Sicherheitsforschung, keine Belege für einen einzelnen breit bestätigten Produktvorfall.

Bedeutung für die Abwehr

Abwehr beginnt bei der Herkunft: Tool-Definitionen, insbesondere Beschreibungen und Annotationen, sind als untrusted input zu behandeln, sofern der Server nicht verifiziert vertrauenswürdig ist. Die aktuelle MCP-Spezifikation verlangt diese Bewertung für Tool-Annotationen ausdrücklich und empfiehlt klare Anzeigen der angebotenen Tools sowie menschliche Kontrolle über Aufrufe.2 Praktisch folgen daraus eine servergebundene Allowlist, nachvollziehbare Freigaben, Protokollierung und eine erneute Prüfung, wenn sich Tool-Listen ändern. Die Spezifikation erlaubt Änderungen der Tool-Liste und sieht dafür Benachrichtigungen vor; eine einmalige Prüfung bei der Installation reicht deshalb nicht als alleinige Kontrolle.2 Zusätzliche Schadensbegrenzung schaffen Least Privilege, Bestätigung sensibler Tool-Aufrufe und eine von der Modellentscheidung getrennte Autorisierung. So bleibt eine manipulierte Beschreibung ein erkennbarer Vertrauensbruch statt eines stillen Befehls.

Quellen

  1. Wang et al., „MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers“, 19. August 2025, https://arxiv.org/html/2508.14925v1. ↩
  2. Model Context Protocol Contributors, „Tools“, 28. Juli 2026, https://modelcontextprotocol.io/specification/2026-07-28/server/tools. ↩
  3. Brandon Radosevich und John Halloran, „MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits“, 11. April 2025, https://arxiv.org/abs/2504.03767. ↩

Im Zusammenhang