KI-Agenten vertrauen sich blind: Was die MCP-Lücken lehren
06. Oktober 2026
KI-generiert, redaktionell von 8thsense ausgewählt, geprüft und freigegeben. EU AI Act, Art. 50
Ein unabhängiger Sicherheitsforscher hat bei Google, der Großbank JPMorgan Chase, dem Datenbankanbieter Weaviate und zwei Behörden im Kern denselben Fehler gefunden: KI-Agenten, die über das Model Context Protocol (MCP) mit Werkzeugen und anderen Agenten verbunden sind, reichen eingeschleuste Befehle ungeprüft weiter. Alle fünf Organisationen haben die Lücken inzwischen geschlossen. Die Lehre reicht aber weit über Konzerne hinaus. Wer heute KI-Agenten mit Zugriff auf Postfach, CRM oder Datenbank anbindet, baut sich dieselbe Vertrauenskette ins eigene Haus.
Was der Forscher herausgefunden hat
Hinter den Funden steht Syed Anas Mohiuddin, ein Forscher ohne institutionelle Anbindung. Laut seiner eigenen Übersicht haben Google, JPMorgan Chase, Weaviate, die französische Digitaldirektion DINUM (für data.gouv.fr) und die Stadtverwaltung von Tangerang in Indonesien die Probleme bestätigt und behoben (Quelle: anas-security-portfolio.vercel.app). Weitere Meldungen gingen unter anderem an 1Password, Jupyter, Rapid7 und Warp. Fünf Meldungen an US-Bundesbehörden, darunter das Veteranenministerium, waren nach seinen Angaben Anfang September noch in Prüfung. Ars Technica hat die Funde am 5. Oktober aufgegriffen und mit beteiligten Unternehmen gesprochen (Quelle: arstechnica.com).
Wie der Angriff funktioniert
Das Muster nennt Mohiuddin „Protocol Pivoting”. Ein Angreifer versteckt Text in Inhalten, die ein Agent liest, etwa in einer Webseite, einem Dokument oder der Antwort eines Werkzeugs. Der Agent hält den Text für einen normalen Auftrag und gibt ihn als delegierte Aufgabe an den nächsten Agenten weiter. Der wiederum führt ihn aus, weil er dem Absender grundsätzlich vertraut. Douglas McKee, Director of Vulnerability Intelligence bei Rapid7, beschreibt es gegenüber Ars Technica so: Jedes Protokoll prüfe seine eigene Haustür, aber niemand bewache den Flur dazwischen. Technisch landeten viele Fälle bei einer altbekannten Schwachstelle, der Server-Side Request Forgery (SSRF): Ein Server ruft im Auftrag des Angreifers interne Adressen auf, zum Beispiel Cloud-Metadaten mit Zugangsdaten.
Der Fall Google im Detail
Am schwersten wog die Lücke in Googles MCP Toolbox für Datenbanken. Der offizielle CVE-Eintrag CVE-2026-14540 vom 31. Juli 2026 beschreibt sie als SSRF in den Versionen 0.3.0 bis 1.4.0 mit einem CVSS-Wert von 8,0 (Quelle: cve.org). Der HTTP-Client folgte Weiterleitungen ohne Einschränkung und prüfte die Ziel-IP-Adressen nicht. Ein präparierter Pfad-Parameter, etwa aus einem manipulierten Prompt, konnte das Werkzeug so auf interne Endpunkte umlenken. Googles Korrektur arbeitet mit Erlaubnis- und Sperrlisten für IP-Bereiche und lehnt unsichere Basis-URLs schon beim Start ab. Die Rapid7-Lücke stufte das Unternehmen dagegen nur mit 2,7 von 10 ein und hat sie im September behoben.
Neuer Angriff oder alter Bekannter?
Nicht alle Fachleute halten den neuen Namen für nötig. Markus Vervier vom Sicherheitsunternehmen X41 D-Sec sieht darin schlicht indirekte Prompt Injection: Dass der schädliche Text über ein anderes Protokoll hereinkomme, sei für den Angriff nicht zwingend, mache ihn aber unerwartet und schwer abzuwehren (Quelle: arstechnica.com). McKee sieht es ähnlich nüchtern: Die Fehler darunter seien alte Bekannte wie Injection und SSRF, die Gegenmittel hätten sich seit 20 Jahren nicht verändert. Das eigentlich Neue ist die Verbreitung. MCP steckt inzwischen in sehr vielen Agenten-Setups, bevor das Protokoll ausreichend gehärtet wurde. Mohiuddin hat seine Empfehlungen zusätzlich als Internet-Draft bei der IETF eingereicht. Das ist ein Einzelvorschlag ohne offiziellen Status, aber eine brauchbare Checkliste (Quelle: datatracker.ietf.org).
Was das für Unternehmen bedeutet
Die Lücken betreffen nicht nur Konzerne. Wer in einem Pflegedienst, einer Tanzschule oder einer Agentur einen KI-Assistenten an Postfach, Kalender oder Kundendatenbank anbindet, nutzt sehr oft genau diese Bausteine: fertige MCP-Server aus dem Netz, die mit weitreichenden Zugangsdaten laufen. Eine einzige präparierte Mail kann dann reichen, damit der Agent Daten an Stellen schickt, an die sie nicht gehören. Eine kurze Prüfliste, abgeleitet aus den Empfehlungen des Forschers und des IETF-Drafts:
Minimale Rechte: Jeder Agent und jeder MCP-Server bekommt nur die Zugänge, die er für genau eine Aufgabe braucht. Lesender Zugriff statt Schreibrechten, wo immer möglich.
Keine blinde Vertrauenskette: Was ein Agent von einem anderen Agenten oder einem Werkzeug bekommt, wird behandelt wie Eingaben eines Fremden aus dem Internet.
Freigabeschritte: Versand, Löschen, Zahlungen und Datenexporte laufen nur nach Bestätigung durch einen Menschen.
Netz abschotten: MCP-Server dürfen keine internen Adressen und keine Cloud-Metadaten erreichen, Weiterleitungen sind standardmäßig aus.
Updates und Protokolle: Eingesetzte MCP-Server regelmäßig aktualisieren, Werkzeugaufrufe mitloggen, sensible Antworten vor dem Logging schwärzen.
Der pragmatische Einstieg kostet vor allem Zeit, kaum Geld: eine Bestandsaufnahme, welche KI-Werkzeuge im Betrieb mit welchen Zugängen laufen, oft in einem halben Tag erledigt. Schwieriger ist die saubere Umsetzung, denn generische Agenten-Baukästen kennen die eigenen Prozesse nicht und vergeben Rechte gern großzügig. Wer Prozessautomatisierung mit Agenten ernsthaft angeht, sollte Rechte, Freigaben und Netzgrenzen von Anfang an mitplanen, statt sie nachträglich aufzusetzen. Eine strukturierte KI-Automation beginnt deshalb mit der Frage, was ein Agent auf keinen Fall dürfen soll, und erst danach mit der Frage, was er alles kann.
