Bei der Prüfung von Agenten-Tools reicht mir der Code allein nicht mehr. Namen, Beschreibungen, Parameterschemata und Beispiele beeinflussen, welches Tool ein KI-Agent auswählt und wie er es aufruft. Damit wird natürliche Sprache Teil der Sicherheitsoberfläche.

Das Tool ist sauber. Die Beschreibung nicht.

Der Preprint “When the Manual Lies”, arXiv:2605.24069v1 vom 22. Mai 2026, untersucht manipulierte Tool-Metadaten. Die Autoren nennen den Angriff Tool Description Poisoning: Schädliche Anweisungen stecken in der Beschreibung, während der ausführbare Tool-Code unverändert sein kann.

Das Paper testet 32 Sandbox-Fälle aus sechs Risikokategorien mit acht Sprachmodellen. Es untersucht damit einen klar abgegrenzten Angriffsvektor, keine realen Produktionsvorfälle und keine kompromittierten Tool-Binaries. Gerade diese Begrenzung macht den Befund brauchbar: Schon die Beschreibung kann die Planungs- und Entscheidungsschicht beeinflussen.

MCP macht das Problem sichtbarer

Das Model Context Protocol in der stabilen Spezifikation vom 28. Juli 2026 beschreibt Tools unter anderem durch Name, menschenlesbare Beschreibung und Eingabeschema. Clients können diese Tools auffinden und Modelle können sie auswählen. Die Metadaten sind dadurch Planungsinput.

Ein manipulierter Hinweis könnte den Agenten etwa zu einer zusätzlichen URL oder zu einem anderen Parameter lenken. Die aktuelle MCP-Spezifikation behandelt Verhaltensannotationen ohne vertrauenswürdigen Server ausdrücklich als nicht vertrauenswürdig. Sie fordert außerdem Eingabevalidierung und Zugriffskontrollen und sieht Nutzerzustimmung zu Toolaufrufen vor. Zugleich weist sie darauf hin, dass das Protokoll diese Prinzipien nicht selbst erzwingen kann.

Was die Firewall-Falle wirklich zeigt

Im Benchmark waren die getesteten einfachen Prompt-Guardrails häufig unwirksam und teilweise kontraproduktiv. Die Autoren bezeichnen dieses beobachtete Muster als Firewall Fallacy. Das ist kein Beweis, dass jede Prompt-Verteidigung wirkungslos ist. Es zeigt, dass eine Warnung im selben generativen Kanal keine belastbare Ersatzkontrolle darstellt.

Ein Toolaufruf braucht deshalb eine technische Entscheidung: Darf diese Rolle das Tool in diesem Kontext, mit diesen Parametern und für dieses Ziel benutzen? Diese Prüfung gehört an die Ausführungsgrenze.

Was ich für den Betrieb daraus ableite

Über die Mindestanforderungen der Spezifikation hinaus behandle ich Toolbeschreibungen wie code-nahe Artefakte. Das bedeutet Review, dokumentierte Herkunft und Versionierung. Eine Änderung am Beschreibungstext kann das Verhalten verändern, auch wenn kein Code-Diff am Tool vorliegt.

Die Policy bleibt außerhalb des Modells und beantwortet sechs konkrete Fragen:

Diese Kontrollen begrenzen den Handlungsraum bewusst. Flexibilität bleibt innerhalb einer freigegebenen Aufgabe erhalten; Tooltexte können keine neuen Rechte erzeugen.

Die praktische Lehre ist enger als der große Alarm: Tool-Metadaten beeinflussen Planung und gehören deshalb in Review, Freigabe und Änderungsnachweis. Wer nur den Tool-Code prüft, übersieht einen Teil des ausführbaren Kontexts.

Quellen

Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.

lyttek.org · gregor@lyttek.org