Das Vertrauensmodell von MCP ließ einen vergifteten Agenten in einen anderen vordringen

Das Protokoll, das zum Standardweg geworden ist, KI-Agenten miteinander zu verbinden, hat ein Vertrauensproblem – und seine Ausprägung ist es wert, verstanden zu werden, bevor der nächste Vorfall eintritt.

Ars Technica berichtete am 5. Oktober, dass ein unabhängiger Forscher, Syed Anas Mohiuddin, eine Angriffsklasse demonstriert hat, die er „Protocol Pivoting“ nennt. Die Idee ist einfach. Innerhalb eines Netzwerks kommunizieren Agenten miteinander über das Model Context Protocol, kurz MCP. Die Leitplanken sind am schwächsten an der Stelle, an der ein Agent eine Aufgabe an einen anderen übergibt, weil der zweite Agent dem ersten standardmäßig vertraut. Platziert man eine bösartige Anweisung in einem Übersetzungs- oder Datenanalyse-Agenten, dem es an strenger Eingabevalidierung fehlt, gibt er die Anweisung an nachgelagerte Stellen weiter. Der Empfänger gehorcht, denn warum sollte ein vertrauenswürdiger Kollege lügen?

Mohiuddins Proof of Concept erstreckte sich über fünf nicht miteinander verbundene Organisationen: Google, JPMorgan Chase, Weviate, Rapid7, die interministerielle Digitaldirektion Frankreichs und eine US-Bundesbehörde. Diese Organisationen haben wenig gemeinsam – außer dem intensiven Einsatz von Agenten. Das ist der Punkt. Die Schwäche liegt in der Verkabelung, nicht in einem einzelnen Produkt.

Zwei CVEs und eine Bewertungslücke

Die konkreten Fehler sind gewöhnlich, und genau das macht die Geschichte unangenehm. Der MCP-Server von Rapid7 trägt CVE-2026-97228, den das Unternehmen im September 2026 behob, obwohl die Schwachstelle mit 2,7 von 10 bewertet wurde. Googles Problem wurde höher eingestuft, mit einer 8, und betraf googleapis/mcp-toolbox. Sein HTTP-Client hatte keine CheckRedirect-Richtlinie und keine Validierung der Ziel-IP, sodass ein manipulierter Pfadparameter eine Anfrage auf einen internen Endpunkt umleiten konnte. Google fügte IP-Allowlists und -Blocklists hinzu und ließ die Toolbox unsichere Basis-URLs beim Start ablehnen.

Die Diskrepanz bei den Schweregradbewertungen ist eine eigene Lektion. Zwei Organisationen fanden vergleichbare Schwächen im selben Protokoll und bewerteten sie sehr unterschiedlich, was darauf hindeutet, dass die Branche sich noch nicht darauf verständigt hat, wie schwer eine Vertrauenslücke zwischen Agenten wiegen sollte.

Nicht jeder akzeptiert „Protocol Pivoting“ als neue Kategorie. Markus Vervier, Forscher bei X41 D-Sec, sagte gegenüber Ars Technica, er lese dies als indirekte Prompt-Injection, dieselbe Technik, die Sicherheitsteams seit zwei Jahren verfolgen. Diese Einordnung ist fair, und sie schärft zugleich das praktische Problem: Das Verteidigungs-Playbook für Prompt-Injection geht davon aus, dass die Eingabe von außen kommt. Hier kommt sie von innen, mit internen Anmeldedaten.

Die Lücke ist architektonisch, nicht mit einem Patch zu beheben

Ein separater Bericht des Sicherheitsanbieters ClawSecure führt die Analyse eine Ebene tiefer. Seine Forscher testeten Linear, Notion und Dropbox Dash und argumentieren, der Fehler liege in der MCP-Spezifikation und nicht in der Implementierung eines einzelnen Anbieters. In Notion und Linear fanden sie MCP-Server, die automatisch von Angreifern kontrollierte Links abrufen, sobald Inhalte erstellt werden – ganz ohne Modell im Ablauf. Jeder mit Schreibzugriff auf einen Workspace kann ihn in einen Leck-Kanal verwandeln, wodurch ein clever formulierter Prompt überflüssig wird.

Ihre Zahlen sind ernüchternd. Von 20 Verschleierungstechniken, darunter Zero-Width-Unicode und Homoglyphen, überstanden 17 den Roundtrip. Über 14 Modelle aus fünf Labors hinweg blockierte keines die Bedrohungen konsequent; das leistungsstärkste Modell, Claude Opus 4.7, befolgte bösartige Anweisungen immer noch in etwa 26,7 % der Fälle.

ClawSecure verkauft Sicherheitsprodukte, und der Bericht wurde nicht unabhängig repliziert; daher sollte die Aussage zur Plattformebene mit angemessener Vorsicht behandelt werden. Die zugrunde liegenden Bedingungen sind jedoch leicht zu überprüfen. MCP verzeichnet mehr als 500 Millionen monatliche SDK-Downloads und knapp 16.000 öffentliche Server, und einer Zählung zufolge nutzen nur 8,5 % dieser Server OAuth. Die Verbreitung war der Härtung voraus.

AWS lieferte in einem am 2. Oktober veröffentlichten Bulletin eigene Belege. Drei Fehler in seiner Open-Source-Plattform Loom zur Agenten-Orchestrierung könnten eine nicht authentifizierte administrative Übernahme, die Offenlegung von OAuth2-Anmeldedaten und den Zugriff auf interne Dienste ermöglichen. Der schwerwiegendste, CVE-2026-103956, erlaubte jedem Netzwerkclient, die Agenten-Kontrollfläche in Bereitstellungen ohne konfigurierten Identitätsanbieter zu erreichen. Die Loom-Versionen 1.6.1 und 1.7.0 schließen die Lücken.

Warum die standardmäßige Vertrauensannahme der eigentliche Befund ist

Blendet man die CVEs aus, sticht eine Designentscheidung hervor. Agenten sind auf Zusammenarbeit ausgelegt, also authentifizieren sie sich gegenseitig und verhalten sich dann, als würden gültige Anmeldedaten auch eine gültige Anfrage bedeuten. Klassisches Zero Trust sagt das Gegenteil: jede Anfrage muss aus sich selbst heraus legitimiert werden, auch aus dem Inneren des Perimeters.

Mohiuddins Angriffe funktionieren, indem sie diese Umkehrung ausnutzen. Die bösartige Anweisung überwindet die Autorisierungsgrenze zwischen Systemen gerade deshalb, weil sie im Code nie eine Grenze überschreitet. Sie wandert innerhalb eines vertrauenswürdigen Geflechts von Agent zu Agent, und keine Ebene bleibt übrig, die fragt, ob die Anfrage Sinn ergab.

Was Teams diese Woche tun können

Die unmittelbaren Korrekturen sind unspektakulär und schon jetzt verfügbar. Behandeln Sie jede Anweisung, die von einem Sprachmodell kommt, als feindliche Eingabe – egal, welcher Agent sie erzeugt hat. Erzwingen Sie eine strikte Behandlung von Weiterleitungen und validieren Sie Ziel-IPs. Verlangen Sie eine Authentifizierung pro Agent, bevor ein Agent an einen anderen delegiert, und protokollieren Sie die Delegation, damit eine Kette von Übergaben im Nachhinein rekonstruiert werden kann.

Längerfristig ist zu erwarten, dass Standardisierungsgremien Protocol Pivoting als benannte Bedrohungsklasse festschreiben, was Anbieter dazu drängen würde, Zero-Trust-Prüfungen innerhalb von MCP statt daneben auszuliefern. Auditoren werden folgen, und Fragen zu Leitplanken zwischen Agenten werden in Compliance-Reviews auftauchen, so wie es Firewall-Regeln vor einer Generation taten.

Das Unangenehme an dieser Geschichte ist, dass der Trick besser funktioniert, sobald die Agenten einander vertrauen. Jede Organisation, die ihre Tools hastig über MCP verbindet, baut genau dieses Vertrauensgeflecht gerade jetzt auf, und das meiste davon entsteht ohne einen Plan dafür, was passiert, wenn sich herausstellt, dass ein Mitglied des Teams lügt.

Warum das jetzt aufkam

Keine der zugrunde liegenden Techniken ist neu. Server-Side Request Forgery und Injection-Schwachstellen stehen seit Jahren auf der OWASP-Liste. Geändert hat sich, wo sie ausgeführt werden. Agenten gaben diesen alten Fehlern einen neuen Zustellweg, denn ein Agent handelt bereitwillig aufgrund eines Satzes in einem Dokument, eines Feldes in einer Datenbankzeile oder einer Zeile in der Ausgabe eines anderen Agenten. Die Anweisung muss nicht von einem Angreifer getippt werden. Sie muss nur irgendwo landen, wo das Modell sie liest.

Deshalb umfasst die Offenlegung eine Bank, eine Suchmaschine, einen Sicherheitsanbieter und eine Regierungsdirektion. Sie teilten weder Code noch einen Anbieter. Sie teilten eine Architektur, und diese Architektur trägt die Annahme, dass jeder Teilnehmer vertrauenswürdig ist. MCP wurde in etwa einem Jahr von einer neuartigen Idee zu kritischer Infrastruktur, mit Downloads in Hunderten Millionen pro Monat, und die Sicherheitsüberprüfung, die dieses Wachstum normalerweise begleiten würde, hat größtenteils nicht stattgefunden.

Es gibt eine Version dieser Geschichte, die gut endet. Die Fehler werden behoben, die Verwalter des Protokolls reagieren, und die Angriffe erfordern entweder Schreibzugriff oder eine Fußfassung innerhalb des Netzwerks, was eine erhebliche Hürde ist. Doch die entscheidende Korrektur ist kultureller, nicht technischer Natur. Teams, die Agenten einführen, müssen aufhören, gültige interne Anmeldedaten als Beweis dafür zu behandeln, dass eine Anfrage legitim ist, und beginnen, jede Anfrage so zu validieren, als käme sie von einem Fremden. Das ist eine schwerer umzusetzende Änderung als jeder Patch, und sie ist diejenige, die die nächste Runde von Vorfällen testen wird.