Tool Poisoning: wenn die Tools eines Agenten sich gegen ihn wenden
Wie manipulierte Tool-Beschreibungen und präparierte Tool-Ausgaben autonome Agenten zu schädlichen Aktionen lenken — und die Validierungs-, Isolations- und Herkunftskontrollen dagegen.
Definition
Tool Poisoning ist ein Angriff, der die Tools eines KI-Agenten kompromittiert — oder deren Ausgaben — sodass der Agent schädliche Entscheidungen trifft. Dazu zählen manipulierte Tool-Beschreibungen, bösartige oder gekaperte APIs und präparierte Antworten, die den Agenten zu unsicheren Aktionen lenken.
Ein Agent vertraut seinen Tools per Design — das ist der Sinn, ihm Tools zu geben. Tool Poisoning macht aus diesem Vertrauen eine Waffe. Statt anzugreifen, was der Agent liest, greift der Angreifer an, was der Agent benutzt.
Zwei Flächen: Beschreibungen und Ausgaben
Tool Poisoning hat zwei Einstiegspunkte.
Tool-Beschreibungen. Ein Agent wählt oft anhand einer Beschreibung, welches Tool er aufruft. Ist diese Beschreibung angreiferkontrolliert oder manipuliert — ein häufiges Risiko bei Drittanbieter-MCP-Servern — kann der Angreifer die Tool-Auswahl in die Irre führen oder Anweisungen in den Metadaten verstecken, die der Agent beim Planen liest.
Tool-Ausgaben. Was ein Tool zurückgibt, wird zum Kontext, auf dem der Agent handelt. Eine kompromittierte API oder eine legitime, die angreiferbeeinflusste Daten liefert, kann eine Injection über einen Kanal zustellen, dem der Agent zu vertrauen gebaut ist.
Die beiden Flächen und ihre Kontrollen nebeneinander:
| Angriffsfläche | Wie sie missbraucht wird | Typische Quelle | Primäre Kontrolle |
|---|---|---|---|
| Tool-Beschreibung | Führt die Tool-Auswahl in die Irre oder versteckt Anweisungen in Metadaten | Drittanbieter-MCP-Server, Tool-Registries | Definitionen pinnen, versionieren, signieren; Änderungen prüfen |
| Tool-Ausgabe | Gibt präparierte Daten zurück, die wie eine Injection wirken | Kompromittierte oder beeinflusste APIs | Validieren und Typprüfen; als nicht vertrauenswürdige Daten behandeln |
Warum ist Tool Poisoning gefährlich?
Die ganze Architektur nimmt an, dass Tools zuverlässig sind. Auf Nutzereingaben getrimmte Abwehr beobachtet die Tool-Ebene nicht, sodass eine vergiftete Ausgabe oft ungeprüft ankommt — und weil der Agent ihr vertraut, fließt sie direkt Richtung Aktion. Kombiniert mit Excessive Agency kann eine einzige vergiftete Antwort eine irreversible Operation auslösen.
Wirksame Abwehr
- Tool-Ausgaben als nicht vertrauenswürdige Daten behandeln, nie als Anweisungen. Validieren, typprüfen und begrenzen Sie, was zurückkommt.
- Tool-Beschreibungen pinnen und prüfen. Lassen Sie Drittanbieter-Server nicht still ändern, was ein Tool zu tun vorgibt; versionieren und signieren Sie Definitionen, wo möglich.
- Ausführung isolieren. Führen Sie Tools in Sandboxes aus, damit ein bösartiges Tool nicht über seinen Geltungsbereich hinausreicht.
- Least Privilege. Ein vergiftetes Zusammenfassungs-Tool darf nicht zahlen oder löschen — grenzen Sie jedes Tool eng ein.
- Traces überwachen. Achten Sie auf Ausgaben, die plötzlich Befehlssprache enthalten oder ungewöhnliche Folgeaufrufe auslösen; Observability ist Ihre Erkennung.
Das Prinzip
Vertrauen in Tools sollte begrenzt sein, nicht vorausgesetzt. Geben Sie jedem Tool den geringsten nötigen Zugriff, verifizieren Sie, was es zurückgibt, und halten Sie bei allem Irreversiblen einen Menschen in der Schleife — dieselbe Defense in Depth, die die OWASP Top 10 für agentische Anwendungen vorschreiben. Begriffe stehen im Glossar.
Häufige Fragen
Wie unterscheidet sich Tool Poisoning von Prompt Injection?
Prompt Injection pflanzt Anweisungen in Inhalte, die der Agent liest — eine Webseite, ein Dokument; Tool Poisoning greift die Tool-Ebene selbst an, also die Beschreibung, die dem Agenten sagt, was ein Tool tut, oder die Ausgabe, die es zurückgibt. Die Unterscheidung zählt, weil beide über verschiedene Kanäle eintreffen und verschiedene Abwehr brauchen. Eine Injection reist in Daten, die der Agent geholt hat; Tool Poisoning reist über einen Kanal, dem der Agent zu vertrauen gebaut ist, und genau das macht es wirksam. Eine vergiftete Tool-Ausgabe ist faktisch eine Injection durch die Hintertür: Abwehr, die auf das Prüfen von Nutzereingaben getrimmt ist, sieht nie, was eine API zurückgibt. In der Praxis überlappen und verketten sich die Angriffe — ein vergiftetes Tool kann eine Injection tragen, und eine Injection kann den Agenten auf ein bösartiges Tool lenken —, also behandeln Sie Tool-Beschreibungen und Tool-Ausgaben als nicht vertrauenswürdig, nicht nur den Nutzer-Prompt.
Was ist eine vergiftete Tool-Beschreibung?
Ein Agent entscheidet teils anhand der Beschreibung, welches Tool er aufruft — der natürlichsprachlichen Metadaten, die sagen, was das Tool tut und wann man es nutzt. Eine vergiftete Beschreibung ist eine, die ein Angreifer kontrolliert oder manipuliert hat, und sie wirkt auf zwei Weisen. Sie kann die Tool-Auswahl in die Irre führen und den Agenten dazu bringen, das falsche oder ein gefährliches Tool für eine harmlose Aufgabe aufzurufen. Oder sie kann Anweisungen in die Metadaten selbst einschleusen, sodass schon das Lesen des Katalogs verfügbarer Tools Befehle in die Planung des Agenten injiziert. Das ist ein besonderes Risiko bei Drittanbieter-MCP-Servern, wo die Tool-Definitionen von außerhalb Ihrer Vertrauensgrenze stammen und sich zwischen Aufrufen still ändern können. Die Abwehr: Definitionen auf bekannte Versionen pinnen, Änderungen vor der Übernahme prüfen und Definitionen signieren, wo die Plattform es erlaubt, damit sich eine Beschreibung nicht unter Ihnen verändert.
Wie verteidige ich mich?
Behandeln Sie alles, was die Tool-Ebene produziert, als nicht vertrauenswürdig — genauso wie aus dem offenen Web geholte Inhalte. Validieren und typprüfen Sie Tool-Ausgaben und begrenzen Sie sie auf erwartete Formen, statt rohe Antworten direkt in den Kontext des Agenten zurückzuspeisen. Pinnen und prüfen Sie Tool-Beschreibungen, damit ein Drittanbieter-Server nicht still ändert, was ein Tool zu tun vorgibt, und versionieren oder signieren Sie Definitionen, wo möglich. Isolieren Sie die Tool-Ausführung in Sandboxes, damit ein bösartiges Tool nicht über seinen Geltungsbereich hinausreicht. Wenden Sie Least Privilege an, sodass selbst ein vollständig vergiftetes Tool keine folgenreiche Aktion auslösen kann — ein Zusammenfasser darf nicht zahlen oder löschen. Überwachen Sie schließlich Traces auf Ausgaben, die plötzlich Befehlssprache enthalten oder ungewöhnliche Folgeaufrufe auslösen. Keine einzelne Kontrolle genügt; es geht um geschichtete Eindämmung, damit ein vergiftetes Tool nichts Irreversibles erreicht.
Sind Drittanbieter-MCP-Tools sicher?
Sie sind nutzbar, aber nicht standardmäßig sicher — behandeln Sie jeden externen MCP-Server als nicht vertrauenswürdige Infrastruktur, nicht als vertrauenswürdige Erweiterung Ihres Agenten. Das Risiko: Sowohl die Tool-Beschreibungen als auch die Tool-Ausgaben stammen außerhalb Ihrer Kontrolle, sodass ein Server eine harmlose Beschreibung zeigen, Ihre Prüfung bestehen und später präparierte Daten zurückgeben oder seine Definition zwischen Aufrufen ändern kann. Das heißt nicht, sie zu meiden; das Ökosystem ist zu nützlich. Es heißt, sie in die Kontrollen zu hüllen, die Sie jeder nicht vertrauenswürdigen Abhängigkeit geben würden: konkrete Versionen pinnen, die angeforderten Scopes jedes Tools prüfen, es mit Least Privilege ausführen und seine Ausgaben validieren. Halten Sie bei allem Irreversiblen einen menschlichen Freigabeschritt zwischen Tool und Aktion. Die Bequemlichkeit eines Drittanbieter-Tools ist nie unbeschränkten Produktionszugriff wert.