MCP schafft neue Angriffswege zwischen KI-Agenten
Das Model Context Protocol, kurz MCP, verbindet KI-Anwendungen mit Werkzeugen, Datenbanken und spezialisierten Agenten. Sicherheitsforscher haben nun gezeigt, wie Angreifer diese Verbindungen nutzen können, um bösartige Anweisungen durch interne Agentenketten zu schleusen.
Das Kernproblem ist nicht ein einzelnes KI-Modell. Viele Spezialagenten für Übersetzung, Datenanalyse oder Datenbankzugriffe besitzen nur schwache Schutzmechanismen. Nachgelagerte Systeme vertrauen darauf, dass intern weitergereichte Aufgaben bereits geprüft wurden.
In den vergangenen fünf Monaten haben Google und mindestens vier weitere Organisationen entsprechende Schwachstellen in Agenten-Setups eingeräumt. Untersucht wurden Umgebungen von Google, JP Morgan Chase, Weaviate, Rapid7, der französischen Digitaldirektion und der US-Bundesregierung. Zu den konkreten technischen Fehlern liegen allerdings nur für Google und Rapid7 nähere Angaben vor.
Prompt Injection wandert durch die Agentenkette
Ein Angreifer kann manipulierten Text in Dokumenten, Webseiten oder anderen Inhalten platzieren. Ein Agent liest diese Anweisung und reicht sie als vermeintlich reguläre Aufgabe weiter. Der nächste Agent führt sie aus, weil er der internen Quelle vertraut.
„KI-Agenten geben Angreifern neue Verbindungen, über die sie sich bewegen können. Ein Agent liest präparierten Text, delegiert ihn als normale Aufgabe und der nächste Agent führt ihn aus, weil er dem Absender vertraut.“
Markus Vervier von der deutschen Sicherheitsfirma X41 D-Sec ordnet dieses Muster als indirekte Prompt Injection ein. Dabei stammt die schädliche Anweisung nicht unmittelbar vom Benutzer, sondern aus einem Inhalt, den das System verarbeitet. Ähnliche Risiken zeigt eine selbstreplizierende Prompt Injection bei OpenAI.
Google-Lücke ermöglichte interne Netzwerkanfragen
Besonders schwer wog eine Schwachstelle in Googles MCP Toolbox für Datenbanken unter der Bezeichnung googleapis/mcp-toolbox. Der verwendete HTTP-Client kontrollierte Weiterleitungen nicht ausreichend und prüfte Ziel-IP-Adressen mangelhaft.
Dadurch war eine Server-Side Request Forgery, kurz SSRF, möglich. Bei diesem Angriff bringt manipulierte Eingabe einen Server dazu, unerlaubte Anfragen an interne Systeme zu senden. Ein präparierter Pfadparameter konnte die Toolbox laut Forscher Syed Anas Mohiuddin dazu bewegen, einer Weiterleitung zu einem internen Endpunkt zu folgen.
| Betroffene Umgebung | Schwachstelle | Schweregrad | Status |
|---|---|---|---|
| Google googleapis/mcp-toolbox | Fehlende Redirect-Kontrolle und mangelhafte IP-Validierung | 8 von 10 | Absicherung durch erlaubte und gesperrte IP-Bereiche |
| Rapid7 | CVE-2026-97228 | 2,7 von 10 | Nach Angaben aus der Untersuchung im Vormonat behoben |
MCP-Server speichern häufig Zugangsdaten, die Agenten für ihre Aufgaben benötigen. Wird ein solcher Server erfolgreich missbraucht, kann der Angriff deshalb über eine manipulierte Anweisung hinausgehen und Zugriffsrechte im internen Netzwerk betreffen.
Protocol Pivoting verbindet mehrere Schwachstellen
Mohiuddin bezeichnet die Angriffsmethode als „Protocol Pivoting“. Gemeint ist ein mehrstufiger Angriff, der über ein Protokoll wie MCP beginnt und anschließend Vertrauensannahmen in einem anderen Protokoll ausnutzt. Dazu zählen Googles Agent-to-Agent-Protokoll A2A oder das Agent Network Protocol.
Die Bezeichnung ist neu, die technischen Ursachen sind es nicht. Injection-Angriffe, SSRF und unzureichende Eingabeprüfung beschäftigen die IT-Sicherheit seit rund 20 Jahren. Neu ist vor allem die Zahl automatisierter Verbindungen, über die sich manipulierte Aufgaben bewegen können.
Dass solche Ketten reale Unternehmenssysteme erreichen, ist kein theoretisches Problem. Weitere Untersuchungen dokumentieren bereits, wie KI-Agenten mindestens 27 Unternehmen kompromittierten.
Zero Trust muss auch für interne Agenten gelten
Zero Trust bedeutet, dass keine Verbindung allein aufgrund ihrer Position im internen Netzwerk als vertrauenswürdig gilt. Jeder Zugriff muss geprüft, begrenzt und autorisiert werden. In den untersuchten Agentenarchitekturen wurde dieses Prinzip an den Übergängen zwischen Werkzeugen und Agenten offenbar nicht konsequent umgesetzt.
„Alles, was ein LLM an ein Werkzeug übergibt, sollte wie die Eingabe eines Fremden aus dem Internet behandelt werden.“
Für Unternehmen bedeutet das konkret: Eingaben müssen an jeder Übergabestelle validiert werden. Interne Adressbereiche benötigen SSRF-Schutz, erlaubte Ziele sollten über Positivlisten definiert sein und Agenten dürfen nur die tatsächlich benötigten Rechte erhalten. Auch delegierte Aufgaben aus internen Quellen benötigen eine erneute Autorisierung.
Eigene Agenten senken Abhängigkeit, nicht Verantwortung
MCP und offene Agentenarchitekturen können die Abhängigkeit von geschlossenen SaaS-Plattformen reduzieren. Eigene Systeme ermöglichen mehr Kontrolle über Datenhaltung, Modelle und Prozesse. Sie verlagern jedoch zugleich die vollständige Sicherheitsverantwortung in das betreibende Unternehmen.
Für Organisationen im DACH-Raum ist das besonders relevant, wenn interne Datenbanken personenbezogene oder andere vertrauliche Informationen enthalten. Ein kompromittierter Agent kann dann nicht nur Betriebsgeheimnisse offenlegen, sondern auch DSGVO-relevante Datenabflüsse verursachen.
Lizenzkosten lassen sich durch eigene Agentenlösungen senken. Dem stehen Aufwände für Härtung, Rechteverwaltung, Protokollierung und regelmäßige Sicherheitsprüfungen gegenüber. Self-Hosting ist deshalb keine automatische Sicherheitslösung, sondern eine bewusste Übernahme von Kontrolle und Risiko.