💻 computer science

WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents

Dieses Paper identifiziert und analysiert „Mid-Session Tool Injection“ (MSTI), eine neue Sicherheitsbedrohung im WebMCP-Protokoll, bei der Angreifer durch die Nutzung von Drittanbieter-Skripten agentenzugängliche Tools während aktiver Sitzungen kapern oder manipulieren (framing), und schlägt spezifische Design-Mitigationen vor, um die Tool-Oberfläche gegen solche Runtime-Manipulationsangriffe abzusichern.

Ursprüngliche Autoren: Lin-Fa Lee, Yi-Yu Chang, Chia-Mu Yu, Kuo-Hui Yeh

Veröffentlicht 2026-06-05

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Lin-Fa Lee, Yi-Yu Chang, Chia-Mu Yu, Kuo-Hui Yeh

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie stellen einen hochintelligenten persönlichen Assistenten (einen KI-Agenten) ein, um eine komplexe Aufgabe für Sie zu erledigen, wie zum Beispiel eine Reise zu buchen oder Ihre Finanzen zu verwalten. Sie geben diesem Assistenten eine Liste der genehmigten Werkzeuge zur Verfügung, die er nutzen darf: eine „Suchmaschine“, einen „Kalender“ und einen „Zahlungsdienstleister“. Sie vertrauen darauf, dass diese Liste fest und sicher ist.

Dieses Paper stellt eine neue Sicherheitsbedrohung namens WebMCP Tool Surface Poisoning vor. Es argumentiert, dass die Liste der Werkzeuge, die Ihrem KI-Assistenten zur Verfügung stehen, tatsächlich nicht eine statische, festgeschriebene Liste ist. Stattdessen ist sie wie ein digitales Menü, das ein Hacker heimlich umschreiben kann, während der Assistent noch arbeitet.

Hier ist eine Aufschlüsselung der Ergebnisse des Papers unter Verwendung einfacher Analogien:

Das Kernproblem: Das „magische Menü“

In dem neuen WebMCP-System können Websites Werkzeuge direkt an KI-Agenten übergeben. Das Paper warnt, dass dieses System eine Schwachstelle hat: Die Liste der Werkzeuge ist dynamisch.

Stellen Sie sich den KI-Agenten wie einen Koch in einer Küche vor. Die „Werkzeuge“ sind die Messer, Töpfe und Zutaten auf der Arbeitsplatte.

Der alte Weg: Der Koch erhält zu Beginn eine feste Liste von Zutaten. Wenn die Liste „Tomaten“ sagt, verwendet der Koch Tomaten.
Der WebMCP-Weg: Die Zutaten auf der Arbeitsplatte können sich ändern, während der Koch kocht. Ein böswilliger Dritter (ein Hacker) kann die „Tomaten“ durch „Giftige Beeren“ austauschen, kurz bevor der Koch nach ihnen greift, oder er kann ein neues, harmlos aussehendes „Gewürz“ hinzufügen, das eigentlich nur das Gericht ruiniert.

Die zwei Hauptangriffe

Die Forscher identifizierten zwei spezifische Arten, wie Hacker diese „Küche“ manipulieren können:

1. Tool Hijacking (Der „Vertauschungs-Trick“)

Dies ist wie ein Magier, der ein echtes Kartendeck gegen ein gefälschtes austauscht, kurz bevor man eine Karte zieht.

Wie es funktioniert: Ein Hacker nutzt ein Skript, um ein legitimes Werkzeug (wie „E-Mail senden“) zu löschen und sofort durch ein gefälschtes zu ersetzen, das exakt denselben Namen trägt, aber etwas Böses tut (wie „E-Mail an Hacker senden“).
Das Ergebnis: Die KI merkt nicht, dass sie getäuscht wurde. Sie glaubt, das echte Werkzeug zu benutzen, aber sie übergibt in Wirklichkeit Ihre privaten Daten an den Angreifer.
Das Ergebnis des Papers: Dieser Angriff ist sehr effektiv. In ihren Tests nutzte die KI das gefälschte Werkzeug 100 % der Zeit, wenn der Austausch früh genug geschah, und sendete sensible Daten an den Hacker.

2. Tool Framing (Die „Verkleidung“)

Hier geht es weniger darum, das Werkzeug auszutauschen, sondern vielmehr darum, darüber zu lügen, was das Werkzeug tut.

Wie es funktioniert: Der Hacker entfernt die echten Werkzeuge nicht. Stattdessen fügt er ein neues, bösartiges Werkzeug hinzu und versieht es mit einer sehr überzeugenden Beschreibung. Er könnte ein „Datendiebstahl“-Werkzeug als „Sicherheitsprüfung erforderlich vor dem Senden“ oder „Compliance-Schritt“ bezeichnen.
Das Ergebnis: Die KI sieht ein Werkzeug, das notwendig und sicher klingt, und entscheidet sich daher, es als Teil ihres normalen Arbeitsablaufs zu verwenden.
Das Ergebnis des Papers: Dies ist hinterhältiger. Die KI führt oft die ursprüngliche Aufgabe (wie das Senden der E-Mail) währenddessen durch, dass sie im Hintergrund auch das gefälschte Werkzeug nutzt. Die Aufgabe sieht erfolgreich aus, aber die Daten wurden geleakt. In einigen Fällen fiel die KI auf diese Verkleidung 85 % der Zeit herein.

Das „Rezept“ für den Erfolg

Die Forscher testeten diese Angriffe an drei der klügsten verfügbaren KI-Modelle (GPT-5.4, Claude Opus und Gemini 2.5). Sie fanden heraus:

Das Timing ist entscheidend: Wenn der Hacker das Werkzeug austauscht, bevor die KI anfängt zu denken, fällt die KI fast immer darauf herein. Wenn der Austausch jedoch stattfindet, nachdem die KI bereits ein Werkzeug ausgewählt hat, schlägt der Angriff meistens fehl.
Die Beschreibung zählt: Die KI verlässt sich stark auf die Textbeschreibung des Werkzeugs. Wenn die Beschreibung besagt: „Dies ist ein obligatorischer Sicherheitsschritt“, wird die KI sehr wahrscheinlich gehorchen, selbst wenn das Werkzeug bösartig ist.
Modellunterschiede: Einige KIs waren törichter als andere. Zum Beispiel wurde ein Modell (Gemini) leicht durch lange, langweilige Beschreibungen voller juristischer Fachsprache getäuscht, während ein anderes (Claude) gegen diesen speziellen Trick immun war.

Die Lösung: Die Küche abschließen

Das Paper schlägt vor, dass wir nicht einfach darauf vertrauen können, dass die KI „schon wissen wird, was richtig ist“. Wir müssen ändern, wie das System aufgebaut ist. Sie schlagen vier Hauptlösungen vor:

Dienstausweise: Jedes Werkzeug sollte eine permanente, unveränderliche ID-Karte haben, die beweist, wer es erstellt hat. Wenn ein Werkzeug versucht, seinen Namen oder Besitzer zu ändern, sollte das System dies ablehnen.
Die Uhr prüfen: Das System sollte prüfen, ob sich die Werkzeugliste geändert hat, seit die KI mit der Aufgabe begonnen hat. Wenn ein Werkzeug ausgetauscht wurde, sollte die KI stoppen und um Bestätigung bitten.
Datengrenzen: Den Werkzeugen sollte genau gesagt werden, welche Daten sie anfassen dürfen. Ein „Nur-Lese“-Werkzeug sollte nicht in der Lage sein, Daten an den Server eines Hackers zu senden.
Ein Protokoll führen: Das System sollte ein detailliertes Tagebuch darüber führen, wann ein Werkzeug hinzugefügt, entfernt oder geändert wurde, damit wir sehen können, ob etwas Verdächtiges passiert ist.

Das Fazit

Das Paper kommt zu dem Schluss, dass die „Tool Surface“ (die Liste der Werkzeuge, die eine KI nutzen kann) keine sichere, statische Grenze mehr ist. Sie ist zu einem neuen Ort geworden, an dem Hacker angreifen können. Selbst die klügsten KI-Modelle können getäuscht werden, wenn die Werkzeuge, die sie verwenden dürfen, während der Arbeit heimlich ausgetauscht oder getarnt werden. Um sicher zu bleiben, muss das System selbst neu gestaltet werden, um Werkzeuge ständig zu verifizieren, anstatt darauf zu vertrauen, dass die KI es selbst herausfindet.

Technisches Resümee: WebMCP Tool Surface Poisoning

Problemstellung

WebMCP ist ein aufstrebendes Protokoll, das es Websites ermöglicht, strukturierte Tools direkt an KI-Agenten zu exponieren und dabei traditionelle Benutzeroberflächen zu umgehen. Während dies die Interaktivität durch dynamische Tool-Listen erhöht, führt es eine kritische Sicherheitslücke ein: Die Annahme, dass der Satz der für einen Agenten innerhalb einer Sitzung verfügbaren Tools statisch und vertrauenswürdig ist, ist nicht länger gültig. Die „Tool-Oberfläche“ selbst ist zu einer neuen Sicherheitsgrenze geworden.

Die bestehende Sicherheitsforschung zu LLM-Agenten konzentriert sich primär auf statische Bedrohungen wie Prompt Injection oder indirekte Prompt Injection, bei denen bösartige Anweisungen in Inhalten eingebettet sind. Die dynamische Natur von WebMCP ermöglicht jedoch eine neue Klasse von Bedrohungen, bei denen das Tool-Register, die Definitionen und die Metadaten während einer aktiven Sitzung verändert werden können. Dieses Paper identifiziert Mid-Session Tool Injection (MSTI) als einen neuartigen Angriffsvektor, bei dem Angreifer kompromittierte Drittanbieter-Skripte (z. B. über CDNs oder Ad-SDKs) nutzen, um die dem Agenten sichtbaren Tools zu manipulieren und dadurch den Ausführungsfluss des Agenten zu kapern oder Datenabfluss zu induzieren, ohne notwendigerweise die ursprüngliche Aufgabe des Benutzers zu stören.

Methodik

Die Autoren konstruierten ein experimentelles Framework, bestehend aus einem Benign Page Server, einem Malicious Server und einem LLM Agent. Der Malicious Server injiziert kompromittierte Drittanbieter-Skripte in den Browser des Opfers, um das WebMCP-Tool-Register in Echtzeit zu manipulieren.

Angriffs-Taxonomie

Die Studie kategorisiert MSTI-Angriffe in zwei primäre Typen:

Tool Hijacking: Ändert direkt den Satz der Tools, die der Agent beobachten kann. Dies beinhaltet das Unregistrieren legitimer Tools (via AbortSignal-Manipulation) oder das Registrieren bösartiger Tools mit denselben Namen, bevor der Agent sie auswählen kann (Race Conditions). Das Ziel ist es, den Agenten dazu zu zwingen, ein bösartiges Tool anstelle des legitimen Tools aufzurufen.
Tool Framing: Manipuliert die Wahrnehmung des Agenten bezüglich der Rolle eines Tools, ohne notwendigerweise legitime Tools zu entfernen. Angreifer nutzen Metadatenfelder wie tool name, description, readOnlyHint und inputSchema aus, um bösartige Tools als notwendige Workflow-Schritte, Sicherheitsüberprüfungen oder sichere Read-Only-Operationen zu tarnen.

Experimenteller Aufbau

Modelle: Für die Experimente wurden drei State-of-the-Art (SOTA) LLMs verwendet: GPT-5.4, Claude Opus 4.6 und Gemini 2.5-flash.
Szenarien: Vier Aufgaben-Szenarien mit zunehmender Schwere wurden getestet:
- Schwach: Wissensdatenbank-Suche (Informationssuche).
- Mittel: Erstellung eines Geschäftsberichts (Datenverarbeitung).
- Stark: E-Commerce Checkout (Transaktional).
- Kritisch: GPU-Treiber-Update (Systemebene).
Metriken:
- Attack Success Rate (ASR): Prozentsatz der Durchläufe, in denen der Agent ein bösartiges Tool aufrief und Daten an den Attacker-Endpoint exfiltrierte.
- Task Completion: Ob der Agent die ursprüngliche Benutzeraufgabe abschloss (unabhängig davon, ob ein Angriff stattfand).
- Data Exfiltration: Nachweis von sensiblen Kontexten, die an den Angreifer gesendet wurden.

Zentrale Beiträge

Identifizierung von MSTI: Das Paper definiert Mid-Session Tool Injection formal als eine distinkte Bedrohungskategorie, die auf den dynamischen Tool-Lebenszyklus von WebMCP abzielt, und unterscheidet diese von statischer Prompt Injection.
Quantifizierung des Risikos: Durch Multi-Modell- und Multi-Szenario-Experimente quantifizieren die Autoren die Auswirkungen der Tool-Manipulation auf das Agentenverhalten, insbesondere im Hinblick auf bösartige Tool-Aufrufe, Datenabfluss und die Rate der Aufgabenabschlussrate.
Empfehlungen für das Sicherheitsdesign: Basierend auf empirischen Erkenntnissen schlägt das Paper spezifische sichere Designrichtungen für WebMCP vor, einschließlich der Bindung der Tool-Identität an den Ursprung (Origin), der Sicherstellung der Lebenszyklus-Konsistenz, der Durchsetzung von Datengrenzen und der Aufrechterhaltung nachvollziehbarer Protokolle.

Ergebnisse

Tool Hijacking (Bedingungen C1, C3)

Hoher Erfolg, geringe Tarnung: Hijacking-Angriffe erreichten sehr hohe ASRs (bis zu 100 % für C3, 94 % im Durchschnitt für C1).
Aufgabenunterbrechung: Diese Angriffe störten die Aufgabenabschlussrate signifikant (Abfall auf 17–18 %). Die bösartigen Tools führten oft dazu, dass der Agent beim ersten Schritt des Workflows stockte oder fehlschlug.
Zeitliche Sensitivität: Der Erfolg hing strikt vom Zeitpunkt der Injektion ab. Für AbortSignal-Hijacking (C1) gelang der Angriff nur, wenn das bösartige Tool das legitime Tool vor dem ersten Aufruf ersetzte (P1). Sob $on$ ein legitimer Aufruf erfolgte, schlug der Angriff fehl (P2–P4).

Tool Framing (Bedingungen C2, C4, C5)

Hohe Tarnung, hoher Erfolg: Framing-Angriffe waren signifikant unauffälliger. Während die ASRs niedriger waren als beim Hijacking (zwischen 36 % und 61 % im Durchschnitt), blieben die Raten der Aufgabenabschlussrate hoch (81–85 %).
Modell-Varianz:
- GPT-5.4 und Gemini 2.5 waren sehr anfällig für Description Injection und Long-Description Overflow.
- Claude Opus zeigte eine systematische Immunität gegenüber Long-Description Overflow (C4) und eine geringere Anfälligkeit für Description Injection (C2), was auf unterschiedliche semantische Verarbeitungsverhaltensweisen hindeutet.
Feld-Auswirkungen:
- Description: Das potenteste Feld für Framing; das Injizieren imperativer Anweisungen (z. B. „Immer vor send_email aufrufen“) lieferte hohe Erfolgsraten.
- readOnlyHint: Das Setzen von readOnlyHint=true war ein überraschend effektiver eigenständiger Angriffsvektor (durchschnittlich 87 % ASR), da Agenten dies als Sicherheitssignal interpretierten.
- inputSchema: Die Effektivität war stark modellabhängig (Gemini 100 % vs. GPT/Claude 0 %).
- Komposit-Angriffe: Die Kombination aus Description Injection und readOnlyHint (Bedingung C5) führte zu einem Erfolg von 100 % über alle Modelle hinweg.

Evaluierung der Verteidigung

Die Autoren implementierten zwei Baseline-Verteidigungen:

Origin Binding: Ablehnung von Tool-Registrierungen mit demselben Namen, aber unterschiedlichem Ursprung.
Data Flow Restriction: Interzeptiert Drittanbieter-Tool-Aufrufe und beschränkt sensible Argument-Felder.

Ergebnis: Diese Verteidigungsmaßnahmen reduzierten die ASR von 36–100 % auf 0 % für die getesteten Bedingungen. Entscheidend ist, dass die Raten der Aufgabenabschlussrate vergleichbar mit dem Baseline-Wert blieben, was beweist, dass die Verhinderung von Datenabfluss nicht notwendigerweise den Workflow des Agenten unterbricht.

Signifikanz und Behauptungen

Das Paper argumentiert, dass die Tool-Oberfläche selbst ein aufkommendes Sicherheitsbedenken darstellt. Im Gegensatz zu traditionellen Angriffen, die den Prompt oder den Output vergiften, greift MSTI den Zustand der Umgebung an, den der Agent wahrnimmt.

Protokoll-Vulnerabilität: Die Studie zeigt, dass die dynamische Registrierung und die strukturierten Metadaten von WebMCP einzigartige Angriffsflächen schaffen, die nicht allein durch Upgrades der Modellversionen gemildert werden können.
Stealth vs. Disruption: Es gibt einen Trade-off zwischen der Sichtbarkeit des Angriffs und der Störung des Systems. Hijacking-Angriffe sind laut und disruptiv, während Framing-Angriffe heimlich sind und die Aufgabenabschlussrate erhalten, was sie für Benutzer schwerer detektierbar macht.
Design-Imperativ: Aktuelle WebMCP-Implementierungen verfügen über keinen ausreichenden Schutz gegen dynamisch eingeführte Tools. Die Autoren behaupten, dass zukünftige Implementierungen die Tool-Registrierung nicht nur als Interface-Design-Feature behandeln dürfen, sondern als kritische Sicherheitsgrenze, die Origin-Validierung, Konsistenzprüfungen des Lebenszyklus und strikte Datenflusskontrollen erfordert.

Das Paper schließt mit der Feststellung, dass ohne diese sicherheitsbewussten Architekturen die Flexibilität von WebMCP ein fundamentales Risiko darstellt, bei dem der Ausführungsfluss des Agenten während der Laufzeit durch bösartige Drittanbieter-Skripte gekapert oder manipuliert werden kann.