Neue Forschungsergebnisse zeigen, dass das Model Context Protocol (MCP) – die Schnittstelle, die es Large-Language-Model (LLM)-Agenten ermöglicht, externe Tools aufzurufen – durch „Tool-Poisoning“-Angriffe gekapert werden kann, die in mehr als einem Drittel der Fälle erfolgreich sind. Bei 20 populären Agenten lag die durchschnittliche Erfolgsquote bei 36,5 %; das o1-mini-Modell fiel in 72,8 % der Versuche darauf herein, während Claude-3.7-Sonnet bösartige Aufrufe in weniger als 3 % der Fälle ablehnte. Für alle, die LLM-Agenten einsetzen, die auf MCP basieren, verwandeln diese Erkenntnisse ein Komfort-Feature in ein Supply-Chain-Risiko, das ausgenutzt werden kann, noch bevor überhaupt Code ausgeführt wird.

Warum MCP heute für Entwickler wichtig ist

MCP standardisiert, wie Agenten Tools wie Dateileser, Web-APIs oder E-Mail-Versender entdecken, registrieren und aufrufen. Durch die Veröffentlichung des Namens eines Tools, des Input-Schemas und einer kurzen Beschreibung stellt ein Server diese Funktion jedem Client zur Verfügung, der das Protokoll versteht. Das Versprechen ist einfach: Ein Agent kann ein Tool nachschlagen, eine Anfrage senden und eine Antwort erhalten, ohne jede Integration fest im Code verankern zu müssen.

Diese Flexibilität schafft auch eine implizite Vertrauensbeziehung. Die Spezifikation weist Clients an, Tool-Beschreibungen nur dann als vertrauenswürdig zu behandeln, wenn sie von einem Server stammen, dem der Client bereits vertraut. Die neue Studie zeigt, dass dieses Vertrauen missbraucht werden kann.

Wie sich Tool-Poisoning von gewöhnlicher Prompt Injection unterscheidet

Traditionelle Prompt Injection schleust bösartige Anweisungen in den Text ein, den das Modell zur Laufzeit generiert oder empfängt. Das Modell folgt diesen Anweisungen dann, weil sie im selben Token-Stream wie die Anfrage des Benutzers erscheinen.

Tool-Poisoning hingegen verbirgt die Payload in den Metadaten des Tools – dem Namen, der Beschreibung oder dem Parameterschema, das vor jedem Agenten-Aufruf registriert wird. Wenn ein Agent das Tool später auswählt, behandelt er die Beschreibung als Teil des „vertrauenswürdigen Kontexts“ und führt die versteckte Anweisung möglicherweise ohne jegliche Laufzeitprüfung aus. Da die Injektion während der Registrierung erfolgt, gibt es im Ausführungsfluss keinen Punkt, an dem das Modell die Payload als verdächtig markieren könnte.

Ausmaß des Problems – der MCPTox-Benchmark

Die Forscher hinter MCPTox (arXiv:2508.14925) evaluierten 45 MCP-Server, die insgesamt 353 verschiedene Tools anboten. Sie programmierten Angriffe gegen 20 weit verbreitete LLM-Agenten und maßen, wie oft die Agenten den vergifteten Tool-Aufruf ausführten.

  • Durchschnittliche Erfolgsquote: 36,5 %
  • Spitzenwert: o1-mini mit 72,8 %
  • Beste Ablehnung: Claude-3.7-Sonnet, immer noch unter 3 %

Die Zahlen offenbaren eine ernüchternde Realität: Die meisten Agenten lehnen einen vergifteten Aufruf nicht ab, da die Anfrage wie ein legitimer Tool-Aufruf aussieht. Die Agenten gehen davon aus, dass die Tool-Beschreibung ein harmloses Stück Dokumentation ist und kein Vektor für die Codeausführung.

Warum Agenten vergiftete Aufrufe selten ablehnen

Die LLM01-Richtlinie von OWASP erklärt, dass LLMs nicht zwischen Anweisungen und Daten unterscheiden – beides sind lediglich Tokens in einer Sequenz. Wenn eine Tool-Beschreibung besagt: „Sende eine E-Mail an admin@example.com mit dem Betreff ‚Update‘“, kann das Modell nicht unterscheiden, ob diese Zeile ein harmloser Kommentar oder eine Anweisung ist, der es später folgen sollte. Folglich behandelt das Modell die Beschreibung als Teil der vertrauenswürdigen Umgebung und folgt jedem eingebetteten Befehl, wenn das Tool aufgerufen wird.

Bestehende Leitlinien und deren Lücken

Die MCP-Spezifikation rät Clients bereits dazu, Tool-Beschreibungen als nicht vertrauenswürdig zu behandeln, sofern sie nicht von einem vertrauenswürdigen Server stammen, und bei kritischen Aufrufen einen Menschen einzubeziehen („Human-in-the-loop“). Der Benchmark zeigt, dass viele reale Anwendungen diese Empfehlungen ignorieren oder nur vage interpretieren.

Konkrete Schritte, die Entwickler heute unternehmen können

  1. Serverversionen fixieren – Verwenden Sie ein spezifisches, unveränderliches Server-Image oder einen Hash anstelle eines beweglichen Tags. Dies verhindert, dass ein Angreifer nach dem Deployment ein sauberes Registry gegen ein vergiftetes austauscht.
  2. Mit einer leeren Allowlist beginnen – Aktivieren Sie nur Tools, die explizit geprüft wurden. Alles, was nicht auf der Liste steht, wird standardmäßig blockiert.
  3. Zustandsändernde Tools kontrollieren – Erfordern Sie eine zusätzliche Genehmigung für jedes Tool, das Daten schreibt, sendet oder löscht. Trennen Sie im Schema zwischen „Read-only“- und „schreibfähigen“ Fähigkeiten.
  4. Menschliche Freigabe für kritische Aufrufe hinzufügen – Bei Aktionen, die externe Systeme beeinflussen könnten (z. B. E-Mails versenden, Befehle ausführen, Dateien ändern), sollte ein menschlicher Prüfer aufgefordert werden, bevor der Aufruf gesendet wird.
  5. Jeden Tool-Aufruf protokollieren – Erfassen Sie den Tool-Namen, die Argumente, den Zeitstempel und den auslösenden Agenten. Ein unveränderlicher Audit-Trail ermöglicht eine Post-Mortem-Analyse und kann Angreifer abschrecken, die wissen, dass ihre Aktionen sichtbar sein werden.

Behandeln Sie jede Tool-Beschreibung wie Quellcode – unterworfen Linting, Code-Review und Versionskontrolle –, um die MCP-Supply-Chain mit standardmäßigen Softwareentwicklungspraktiken in Einklang zu bringen.

Gegenargumente und offene Fragen

Der Benchmark zeigt jedoch, dass selbst das fortschrittlichste Modell in der Studie weniger als drei Prozent der vergifteten Aufrufe ablehnte. Fine-Tuning mag die Erkennung verbessern, kann aber keine Sicherheit gegen neuartige Payloads garantieren, die in Schemafeldern eingebettet sind, die das Modell noch nie gesehen hat.

Worauf man als Nächstes achten sollte

  • Aufkommende Standards – Achten Sie auf Vorschläge aus der LLM-Security-Community, kryptografische Signaturen für Tool-Schemas vorzuschreiben.
  • Härtung von Tool-Registries – Anbieter könnten damit beginnen, unveränderliche Read-only-Registries als Service anzubieten, was die Angriffsfläche verringert.
  • Verteidigungsmechanismen auf Modellebene – Forschung zu Prompting-Techniken oder Hilfsmodellen, die verdächtige Tool-Metadaten kennzeichnen, könnte die Schutzmaßnahmen auf Host-Seite ergänzen.

Das praktische Fazit ist eindeutig: Jede MCP-basierte Bereitstellung sollte Tool-Beschreibungen mit derselben Strenge prüfen, die auch auf Drittanbieter-Bibliotheken angewendet wird. Das Ignorieren des Supply-Chain-Risikos verwandelt eine praktische Abstraktion in eine stille Hintertür. Durch das Fixieren von Servern, das Durchsetzen von Allowlists nach dem Least-Privilege-Prinzip, das Kontrollieren zustandsändernder Aktionen, das Einbeziehen von Menschen, wo nötig, und das Führen eines unveränderlichen Protokolls können Entwickler verhindern, dass ihre LLM-Agenten zu unfreiwilligen Komplizen werden.