Das Model Context Protocol verbindet KI-Agenten mit Datenbanken, Ticketsystemen, Dateisystemen und SIEM-Plattformen. Ein MCP-Server kann alles sein — und genau das ist das Problem: Jeder MCP-Server ist eine Vertrauensgrenze, und die wenigsten Implementierungen behandeln ihn als eine.
Seit der Erstfassung dieses Beitrags im April hat sich das Bild in zwei Richtungen bewegt. Die Protokollseite ist besser geworden. Die Ökosystemseite ist schlechter geworden.
Die vier Angriffswege
Tool Poisoning. Jedes Tool bringt eine Beschreibung mit, die dem Modell sagt, was es tut. Für das Modell ist sie verbindlich, für den Nutzer meist unsichtbar. Wer dort Anweisungen platziert, steuert den Agenten. Invariant Labs hat das 2025 vorgeführt: Ein bösartiger Server im selben Agentenkontext wie ein legitimer WhatsApp-Server las per vergifteter Beschreibung den kompletten Nachrichtenverlauf aus. Kein Nutzerfehler, kein Netzwerk-Exploit.
Rug Pull. Tool-Definitionen sind nicht eingefroren. Ein Server kann harmlos starten und die Beschreibungen später ändern — ohne Meldung an den Client. Die meisten Clients erkennen das nicht einmal.
Tool Shadowing. Sind mehrere Server verbunden, kann ein bösartiger die Nutzung der Tools eines anderen beeinflussen. Der Angriff läuft über die Beschreibung, nicht über Namenskollision: Server B erklärt dem Modell, wie es das Tool von Server A „richtig" zu benutzen hat.
Indirect Prompt Injection. Ein Server liefert nicht nur Tools, sondern auch Daten. Was aus E-Mails, Dokumenten oder Datenbanken kommt, landet im Kontext — samt der Anweisungen, die jemand dort hinterlegt hat. OWASP führt das in der Top 10 für Agentic Applications 2026 als ASI01 Agent Goal Hijack.
Was sich seit April geändert hat
Die Autorisierung ist repariert. Die Spezifikation von November 2025 behandelt MCP-Server als OAuth-2.0-Resource-Server und schreibt OAuth 2.1, PKCE und audience-gebundene Tokens vor. Das Update von 2026 ergänzt inkrementelle Scope-Zustimmung: Der Client fragt pro Vorgang das Minimum ab statt alle Berechtigungen vorab.
Das schließt das Confused-Deputy-Problem — einen Server, der mit seinen eigenen weiten Rechten für einen Nutzer handelt, der diese Rechte nicht hat.
Es löst Tool Poisoning und Prompt Injection nicht. Beide greifen an, wie ein Sprachmodell Text verarbeitet, nicht wie Tokens ausgestellt werden. Kein Autorisierungsmodell der Welt hilft gegen eine Anweisung, die im Kontext steht und die das Modell für legitim hält.
Zwei Befunde von 2026, die das Bild verschärfen
Microsoft, 30. Juni 2026. Das Security-Research-Team hat vergiftete Tool-Beschreibungen als allgemeines Exfiltrationsverfahren gegen jeden Agenten dokumentiert, der MCP-artige Tool-Metadaten verarbeitet — nicht als Eigenart einer einzelnen Implementierung. Das Referenzszenario ist bemerkenswert alltäglich: ein Copilot-Studio-Agent in der Buchhaltung, drei angebundene Tools, eines davon ein Drittanbieter-Dienst zur Rechnungsanreicherung.
Cloud Security Alliance, April 2026. Der Bericht MCP by Design beschreibt eine systemische Remote-Code-Execution über die Art, wie der STDIO-Transport Server-Kommandos behandelt. Der Nebenbefund ist der eigentliche Hammer: Neun von elf getesteten MCP-Tool-Registries akzeptierten eine bösartige Proof-of-Concept-Einreichung ohne nennenswerte Prüfung.
Wer also einen Server aus einer Registry zieht, weil das seriöser wirkt als ein GitHub-Fork, irrt sich. Das Repository kann ehrlich sein und das Registry-Paket trotzdem nicht.
Dazu kommt: Die NSA hat im Mai 2026 ein eigenes Cybersecurity Information Sheet zu MCP veröffentlicht. Wenn ein Protokoll aus dem Entwickler-Ökosystem es binnen achtzehn Monaten auf ein NSA-Merkblatt schafft, ist die Frage nach Governance keine akademische mehr.
Der blinde Fleck, über den niemand schreibt
Alle Analysen behandeln den bösartigen Server. Der häufigere Fall ist der kaputte.
Wir haben genau das diese Woche im eigenen Betrieb erlebt: Ein Update-Endpunkt unseres Intel-MCP nahm Schreibvorgänge entgegen, quittierte sie mit HTTP 200 und einem vollständigen Datensatz — und schrieb nichts. Ursache war ein Pydantic-Modell, das unbekannte Feldnamen still verwarf. Der Client hatte keine Möglichkeit, Erfolg von Nichts-Passiert zu unterscheiden.
Das ist keine Sicherheitslücke im klassischen Sinn, aber es ist dieselbe Kategorie: Ein Tool, dessen Rückmeldung nicht der Realität entspricht, korrumpiert jede Entscheidung, die darauf aufbaut — ob die Entscheidung von einem Menschen oder einem Agenten getroffen wird. Ein Agent, der glaubt, er habe eine Konfiguration geschrieben, arbeitet ab diesem Punkt auf einer falschen Weltannahme weiter.
Zwei Zeilen haben es behoben: extra="forbid" im Modell, damit unbekannte Felder einen Fehler auslösen statt zu verschwinden, und ein changed-Feld in der Antwort, das benennt, was tatsächlich geschrieben wurde. Beides gehört in jede MCP-Server-Spezifikation, die etwas verändert.
Was zu tun ist
- Inventar. Welche MCP-Server laufen in Ihrer Organisation, wer hat sie installiert, worauf greifen sie zu? Shadow-MCP ist das neue Shadow-IT — Entwickler binden Server eigenständig an, ohne Review.
- Vollständige Tool-Definitionen prüfen, nicht die Kurzfassung in der Oberfläche. Der Angriff steht im Teil, den der Nutzer nicht sieht. Invariant Labs stellt dafür
mcp-scan als Open Source bereit.
- Beschreibungen versionieren. Bekannte Sollstände hinterlegen und bei Abweichung alarmieren. Ohne das gibt es keinen Rug-Pull-Alarm, weil das Protokoll Änderungen nicht meldet.
- Ausgehende Verbindungen begrenzen. Ein Server, der eine Datenbank abfragt, braucht kein Internet. Sensible Server strikt von allgemeinen trennen.
- Least Privilege plus menschlicher Checkpoint. Löschungen, Massenänderungen, Datenexporte, ausgehende Kommunikation und Zahlungen gehören hinter eine Bestätigung — nicht wegen des Angreifers, sondern wegen der irreversiblen Fehlentscheidung.
- Tool-Aufrufe ins SIEM. Welches Tool, welche Parameter, welche Identität, welches Ergebnis. Die NSA empfiehlt in ihrem Merkblatt genau das, inklusive Hashes der Ergebnisse. Ohne diese Telemetrie ist der Agent ein blinder Fleck im Monitoring — und im Vorfall gibt es nichts zu rekonstruieren.
Aus der Praxis
Wir setzen MCP im eigenen Stack produktiv ein: KI-Agenten an SIEM, Ticketing und Infrastruktur-Management. Die beschriebenen Angriffswege haben wir im Lab nachgestellt, und daraus sind vier Regeln geworden, an die wir uns selbst halten.
Erstens: für sicherheitskritische Anbindungen ausschließlich selbst entwickelte Server. Zweitens: Least Privilege ohne Ausnahme — Lese-Server können nicht schreiben, Datenbank-Server haben keinen Internetzugang. Drittens: jeder Tool-Aufruf wird protokolliert und im XIEM®-Stack auf Anomalien überwacht. Viertens: Tool-Definitionen sind versioniert, Änderungen erzeugen einen Alarm.
Punkt vier hat sich in diesem Jahr am deutlichsten ausgezahlt — nicht wegen eines Angriffs, sondern weil damit auch schlicht fehlerhafte Deployments auffallen.
Nutzen Sie MCP im Unternehmen? Wir unterstützen beim Audit und bei der sicheren Integration.
Quellen