MCP ist die Schnittstelle, über die KI-Modelle heute auf reale Systeme zugreifen – E-Mail, Datenbanken, Cloud-Ressourcen, interne Werkzeuge. Das Modell entscheidet nicht nur. Es handelt. Genau hier entsteht eine neue Angriffsklasse – und genau hier hat Microsoft am 10. März 2026 erstmals gepatcht.
Am 10. März 2026 veröffentlichte Microsoft im Rahmen seines regulären Patch Tuesday CVE-2026-26118 📎 – eine Server-Side-Request-Forgery-Schwachstelle (SSRF – eine Angriffsklasse, bei der ein Server dazu gebracht wird, Anfragen in fremdem Namen weiterzuleiten) in den Azure MCP Server Tools, also in einer Microsoft-Komponente für produktive MCP-basierte Azure-Integrationen. CVSS 8.8. Die Beschreibung ist präzise: Ein Angreifer, der mit einem MCP-gestützten Agenten interagieren kann, schleust eine präparierte URL ein statt eines normalen Azure-Ressourcenidentifiers. In Konfigurationen, in denen der MCP-Dienst Managed Identity Tokens – also dienstgebundene Cloud-Identitäten ohne klassisches Benutzerkonto – für ausgehende Requests nutzt, überträgt der Server diesen Token an die externe Adresse. Der Angreifer fängt ihn ab und erhält damit die Berechtigungen, die mit dieser Managed Identity verknüpft sind. Ohne Admin-Zugang. Ohne Exploit im klassischen Sinne.
Was diese Schwachstelle von früheren SSRF-Funden unterscheidet: Sie sitzt nicht in einer Legacy-Anwendung. Sie sitzt in der Schicht, über die KI-Agenten heute auf Azure-Ressourcen zugreifen. Ein Proof-of-Concept zirkuliert bereits auf GitHub.
Sechs Tage später kündigte das israelische Sicherheitsunternehmen Token Security aus Tel Aviv 📎 an, auf der RSAC 2026 eine weitergehende RCE-Schwachstelle in Microsofts Azure MCP Stack vorzustellen – unter dem Namen „MCPwned“. Die angekündigte Forschung beschreibt, wie ein Angreifer über diesen Stack einen gesamten Azure-Tenant kompromittieren kann. Die vollständige technische Detailoffenlegung steht zum Zeitpunkt dieses Artikels noch aus.
Adversa AI zählt im März-2026-Digest 📎 30 CVEs in 60 Tagen, gezählt über MCP-bezogene Komponenten und Implementierungen. Ein nicht repräsentativer, aber groß angelegter Community-Scan von 5.618 MCP-Servern 📎 aus dieser Woche findet eine SSRF-Exponierungsrate von 36,7 Prozent bei Servern, die externe URLs akzeptieren. OWASP hat in diesem Monat ein erstes offizielles MCP-Top-10-Projekt in Beta 📎 veröffentlicht.
Das Model Context Protocol ist seit dem 25. November 2024 verfügbar. Sechzehn Monate. Und es ist bereits eines der aktuell am schnellsten wachsenden Angriffsfelder im KI-Stack.
Was MCP ist – und warum es sich anders anfühlt als andere Protokolle
Im November 2024 veröffentlichte Anthropic das Model Context Protocol 📎. Der offizielle Rahmen: Ein offener Standard, der KI-Modellen ermöglicht, mit externen Werkzeugen, Datenquellen und Diensten zu interagieren. Die Kurzformel, die sich in der Community durchgesetzt hat: „USB-C für KI-Anwendungen.“
Das Bild ist treffend – und genau deswegen gefährlich. USB-C verbindet Geräte. MCP verbindet Entscheidungsfähigkeit. USB-C hat eine physische Sicherheitsschicht: Das Kabel muss eingesteckt werden, es gibt einen Stecker, den ein Mensch in der Hand hält. MCP hat diese Schicht nicht. Die Verbindung zwischen dem KI-Modell und dem externen Dienst – Gmail, Google Drive, Ihre interne Datenbank, Ihre CI/CD-Pipeline – ist eine Softwareschicht, die im Hintergrund läuft. Wer darin etwas verändert, tut das unsichtbar.
MCP ist nicht die nächste API. Es ist die erste API, die handelt.
Ich habe in diesem Blog bereits beschrieben, was passiert, wenn ein Sicherheitstool zur Waffe wird 📎: Das Tool, dem man vertraut, führt seine Aufgabe korrekt aus – und gleichzeitig tut es etwas anderes. MCP ist dieselbe Denkfigur, eine Abstraktionsebene höher. Nicht das Tool selbst ist kompromittiert. Das Modell, das das Tool aufruft, wird manipuliert. Die Werkzeuge gehorchen – sie wissen nicht, dass der Befehl nicht vom Nutzer kam.
Das strukturelle Vertrauensproblem
MCP-Server sind Middleware. Sie sitzen zwischen dem KI-Modell und den Systemen, mit denen es spricht. Sie definieren, welche Werkzeuge das Modell aufrufen darf – und wie. Sie speichern die OAuth-Tokens, die für den Zugriff auf Gmail, Google Drive, Salesforce, Slack benötigt werden.
Das bedeutet: Wer einen MCP-Server kompromittiert, erhält nicht den Zugriff auf ein System. Er erhält den Zugriff auf alle Systeme, die dieser MCP-Server kennt – und das Modell als willigen Ausführer dazu.
Was die Zahlen dazu sagen, ist nicht beruhigend. Security-Research-Analysen von Docker 📎 deuten darauf hin, dass etwa zwei Drittel der Open-Source-MCP-Server schwache Sicherheitspraktiken aufweisen. OAuth-Authentifizierungsfehler finden sich Schätzungen zufolge bei rund 43 Prozent 📎, Command-Injection-Schwachstellen ebenfalls. Ein Drittel erlaubt uneingeschränkten Netzwerkzugang nach außen.
Das sind keine Nischenimplementierungen. Das sind die Basis-Server, auf denen produktive KI-Integrations-Stacks aufgebaut werden.
Vier dokumentierte Vorfälle – keine Theorie
Was folgt, ist keine Risikomodellierung. Es sind dokumentierte Vorfälle, die zusammen ein Muster ergeben, das für jede Organisation handlungsrelevant ist, die heute KI-Assistenten mit externen Diensten koppelt.
Der Postmark-Incident: Vertrauen als Angriffsfläche. Am 17. September 2025 wurde in Version 1.0.16 des npm-Pakets postmark-mcp eine einzige Zeile Code eingefügt. Zeile 231. Eine BCC-Anweisung. Jede E-Mail, die ein KI-Assistent über diesen MCP-Server versendete, wurde fortan blind kopiert an phan@giftshop[.]club. Das Paket war zu diesem Zeitpunkt rund 1.500 Mal pro Woche heruntergeladen 📎 und potenziell breit in Entwickler-Workflows einsetzbar. Sicherheitsforscher von Koi Security schätzen 📎, dass täglich zwischen 3.000 und 15.000 E-Mails abgeflossen sind – Passwort-Resets, MFA-Codes, Rechnungen, interne Korrespondenz, Kundendaten. Es war der erste dokumentierte bösartige MCP-Server in der Wildnis. Besonders relevant für den Enterprise-Kontext: MCP-Server, die in agentic Pipelines laufen, versenden E-Mails autonom, ohne menschliche Zwischenprüfung. Wer das Paket installiert hatte und nicht aktiv nachschaute, hatte es noch, nachdem der Publisher es gelöscht hatte. Das Protokoll hat dabei tadellos funktioniert. Es wurde missbraucht, nicht gebrochen.
CVE-2025-6514: Remote Code Execution durch fehlende Validierung. Im Juli 2025 veröffentlichte das JFrog Security Research Team 📎 CVE-2025-6514 – eine kritische Schwachstelle (CVSS 9.6) in mcp-remote in den Versionen 0.0.5 bis 0.1.15, dem meistgenutzten OAuth-Proxy für MCP-Clients wie Claude Desktop, Cursor und VS Code. Die Schwachstelle: mcp-remote übergab die authorization_endpoint-URL eines Servers ohne Validierung direkt an die System-Shell. Ein präparierter MCP-Server konnte damit beliebige Betriebssystembefehle auf der Maschine des Entwicklers ausführen. Vollständige Systemkompromittierung, ausgelöst durch das Verbinden mit einem MCP-Endpunkt. Das Paket war zu diesem Zeitpunkt mehr als 437.000 Mal heruntergeladen 📎 worden und in Integrationsleitfäden von Cloudflare, Hugging Face und Auth0 empfohlen. Behoben in Version 0.1.16.
GitHub MCP: Wenn ein öffentliches Issue private Repositories leert. Im Mai 2025 demonstrierten Forscher von Invariant Labs 📎, wie eine Prompt-Injection in einem öffentlichen GitHub-Issue den GitHub-MCP-Server so manipulieren konnte, dass er Daten aus privaten Repositories exfiltrierte – und diese Daten in einem öffentlichen Pull Request ablegte. Der Angriffsvektor: Ein übermäßig weitreichendes Personal Access Token, kombiniert mit nicht isolierten MCP-Tool-Calls. Das Modell hat nichts falsch gemacht. Es hat den Befehl ausgeführt, der ihm gegeben wurde – von einem Issue-Text, den niemand als Angriff erkannt hätte.
CVE-2026-26118: Managed Identity Token als Beute. Microsofts Patch Tuesday vom 10. März 2026 enthielt die erste öffentlich dokumentierte MCP-Schwachstelle in einer produktiven Microsoft-Komponente für Azure-Integrationen. Die Ursache ist kein Protokolldesignproblem – es ist ein klassischer SSRF-Implementierungsfehler: fehlende URL-Validierung, keine Filterung ausgehender Anfragen an interne Metadatenendpunkte. Der Community-Scan von 5.618 MCP-Servern 📎 aus dieser Woche findet dieselbe Schwachstellenklasse bei 36,7 Prozent aller Server, die externe URLs akzeptieren – und kommt zu dem Schluss: „These are not novel AI attacks. They are 2010-era web vulnerabilities showing up in 2026 AI infrastructure because MCP server authors are systems engineers and ML engineers, not security engineers.“ Das ist der eigentliche Befund. Die Angriffsfläche ist bekannt. Die Verteidiger sind es nicht.
Diese vier Vorfälle verbindet ein gemeinsames Merkmal: Kein Zero-Day. Keine staatliche Angriffsinfrastruktur. Protokollvertrauen, fehlende Validierung, überprivilegierte Tokens. MCP ist kein neues Risiko. MCP ist ein Multiplikator bestehender Risiken – in einer Infrastruktur, für die noch niemand zuständig ist.
Drei Angriffsvektoren, die keine Zero-Days brauchen
Jenseits der konkreten Vorfälle gibt es drei strukturelle Angriffsmuster, die für die Einschätzung des eigenen Risikos relevant sind. Allen dreien liegt dieselbe Verschiebung zugrunde: Die Agenten-Schicht ist die Ebene, in der Modelle nicht mehr nur Antworten generieren, sondern Aktionen orchestrieren. Und sie ist die Ebene, auf der Angriffe heute stattfinden.
Prompt Injection durch externe Inhalte. Das Modell liest eine E-Mail, eine Webseite, ein Dokument. In diesem Inhalt sind Instruktionen eingebettet – das ist Prompt Injection: manipulierte Inhalte, die das Modell steuern, ohne dass der Nutzer es bemerkt. Unsichtbar für den menschlichen Leser, weil sie als weißer Text auf weißem Hintergrund stehen oder in Metadaten versteckt sind. Palo Alto Networks Unit42 hat diesen Angriffspfad in einer kontrollierten Demonstration 📎 präzise dokumentiert: Versteckte Anweisungen auf einer Webseite, die das Modell im Rahmen einer normalen Aufgabe aufruft. Die .env-Datei des Entwicklers landet auf einem externen Server. Das Modell hat nichts falsch gemacht – es hat genau das getan, wofür es konfiguriert war.
Tool Poisoning. Nicht der Schadcode selbst, sondern die Beschreibung eines Werkzeugs enthält die Anweisung. Das Modell liest diese Beschreibung, bevor es das Werkzeug aufruft. Sicherheitsforscher haben diese Methode reproduzierbar demonstriert 📎: Ein mathematisches Werkzeug enthält in seiner Beschreibung die Instruktion, vor der Berechnung die Konfigurationsdateien des Projekts zu lesen und ihren Inhalt mitzuübergeben – und dem Nutzer gegenüber nichts davon zu erwähnen. Das Modell folgt. Es ist dieselbe Denkfigur, die ich im Trivy-Artikel als Weaponization of Trust beschrieben habe 📎: nicht die Funktion, sondern der Kontext dieser Funktion wird zur Waffe.
Credential-Akkumulation als High-Value-Target. MCP-Server aggregieren Zugangsdaten für mehrere Dienste an einem Ort. Wer einen MCP-Server kompromittiert, erhält nicht ein Credential – er erhält alle. Und der Zugriff mit einem gestohlenen OAuth-Token erscheint in keinem Log als Anomalie. Es gibt keinen Login-Alert. Es gibt keine geografische Anomalie. Der Zugriff sieht aus wie immer.
Das ist das eigentliche Risikoprofil. Nicht Totalausfall, sondern unsichtbare Persistenz.
Der Einwand, den ich höre – und warum er nicht trägt
Wenn ich dieses Thema in Gesprächen mit CISOs und ISBs anspreche, kommt regelmäßig eine Variante desselben Einwands: „MCP ist ein Entwickler-Tool. Wir reden über Dev-Umgebungen, nicht über Produktion. Das ist nicht unser Problem.“
Das war vor einem Jahr eine vertretbare Einschätzung. Sie ist es heute nicht mehr.
CVE-2026-26118 steckt in den Azure MCP Server Tools – also in einer Microsoft-Komponente, die in produktiven Azure-Integrationen eingesetzt wird. MCP findet sich zunehmend in Unternehmensanwendungen, in CRM-Integrationen, in automatisierten E-Mail-Pipelines, in HR-Prozessen. Viele Organisationen, die heute KI-Assistenten einsetzen, die eigenständig E-Mails senden, Dokumente abrufen oder in SaaS-Plattformen schreiben, betreiben MCP-basierte Verbindungsschichten – oft ohne es zu wissen. Shadow-MCP-Deployments sind kein neues Phänomen – Shadow-IT gibt es bei jeder neuen Technologiewelle. Was sie im MCP-Kontext anders macht: Die Zugriffstiefe ist höher als bei einer nicht-sanktionierten SaaS-App. Nach Einschätzung von Sicherheitsforschern bei Oasis Security 📎 gelten sie als besonders schwer kontrollierbare Angriffsklasse im KI-Agenten-Stack.
Der zweite häufige Einwand lautet: „Wir haben Human-in-the-Loop. Das KI-Modell tut nichts ohne unsere Freigabe.“ Kommerzielle Plattformen bauen zunehmend Mitigationen ein – Tool-Description-Integrity-Checks, Sandboxing, Least-Privilege-Konfigurationen pro Tool. Wer diese Maßnahmen aktiv implementiert hat, ist besser aufgestellt. Aber es stimmt nicht mehr pauschal, sobald agentic AI-Systeme in der Pipeline sind – und es stimmt strukturell nicht für die Angriffsklasse der Prompt Injection, bei der das Modell aus seiner eigenen Perspektive legitime Anweisungen ausführt. Die Freigabe-Logik schützt gegen unerwartetes Modellverhalten. Sie schützt nicht gegen manipulierte Modellbefehle, die wie normale Anfragen aussehen.
Der dritte Einwand: „Wir nutzen einen kommerziellen KI-Anbieter mit ISO 27001 und SOC-2.“ Was das tatsächlich belegt und was nicht, habe ich am Beispiel von KI in regulierten Umgebungen präzise herausgearbeitet 📎: Die Zertifizierung des Modellanbieters sagt nichts darüber aus, wie die MCP-Server gesichert sind, die diesen Anbieter mit Ihren Systemen verbinden. Das sind zwei verschiedene Sicherheitsbereiche, und nur einer davon ist durch die Zertifizierung abgedeckt.
Die Governance-Lücke, die noch niemand benennt
In den meisten Risikobewertungen tauchen MCP-Integrationen nicht systematisch auf. Sie stehen in keiner NIS-2-Lieferantenanalyse. Sie erscheinen in keiner CRA-Konformitätsprüfung. Das liegt nicht daran, dass sie nicht relevant wären – es liegt daran, dass die Frameworks nicht für diese Angriffsklasse geschrieben wurden.
Das ändert sich gerade. OWASP hat in diesem Monat ein erstes offizielles MCP-Top-10-Projekt in Beta 📎 veröffentlicht – eine Taxonomie der kritischsten Risikoklassen im MCP-Ökosystem, von Credential-Exposition über Tool Poisoning bis zu Shadow-MCP-Deployments. Wer die Geschichte der OWASP Top 10 für Web-Anwendungen kennt, weiß, was das bedeutet: Eine Angriffsklasse bekommt ein Framework. Regulatoren beginnen zu zitieren. Auditoren beginnen zu fragen.
Wenn ein KI-Assistent in einer NIS-2-pflichtigen Organisation Zugriff auf E-Mail-Systeme, Dokumentenablagen und interne Kommunikationsplattformen hat – welche Lieferantenanalyse deckt die MCP-Server ab, die diese Verbindungen herstellen? Wer prüft, ob die Tool-Beschreibungen, auf die das Modell vertraut, unverändert sind? Welche Logging-Anforderungen gelten für Aktionen, die nicht ein Mensch, sondern ein Modell auf Basis einer Prompt-Injektion ausgelöst hat?
Die Antwort ist in den meisten Organisationen: keine, niemand, keine.
Das ist kein technisches Versäumnis. Es ist eine Governance-Lücke. § 38 BSIG 📎 verpflichtet die Unternehmensleitung, Risikomanagementmaßnahmen zu billigen und zu überwachen. § 30 Abs. 2 Nr. 4 BSIG 📎 adressiert explizit Sicherheit in der Lieferkette und bei Drittparteien. Wer MCP-Server in regulierten Umgebungen betreibt, wird sie aus meiner Sicht als Teil der Drittparteien- und Lieferkettenrisiken behandeln müssen – mit Dokumentation, Risikoklassifizierung und expliziter Akzeptanzentscheidung. Eine explizite Behördenauslegung speziell zu MCP gibt es noch nicht. Die regulatorische Ableitung ist aber tragfähig – und diese Frage wird gestellt werden.
Ich habe das strukturelle Problem bereits im Kontext der SOC-Erkennungsinfrastruktur beschrieben 📎: Das System, das überwachen soll, wird selbst nicht überwacht. MCP ist dieselbe Denkfigur, in der Agenten-Schicht: Das System, das entscheiden soll, was das Modell tut, wird nicht selbst auf Integrität geprüft.
Diese Lücke ist selbst ein Befund.
Die Agenten-Dimension: Wenn das Modell selbst nicht mehr Zweck, sondern Werkzeug ist
Es gibt eine Entwicklung, die dieses Problem in den nächsten Monaten erheblich schärfer machen wird: autonome KI-Agenten.
Aktuelle MCP-Deployments setzen typischerweise noch einen menschlichen Nutzer voraus, der eine Aufgabe stellt und die Ausführung beobachtet. Agentic AI-Systeme entfernen diese Beobachtungsschicht. Das Modell erhält eine Aufgabe, arbeitet sie autonom ab, ruft MCP-Tools in Sequenzen auf, trifft Entscheidungen ohne menschliche Zwischenprüfung – und ein erfolgreicher Angriff durchläuft keine menschliche Bestätigung mehr.
Was ich in der Analyse über KI-Modelle unter Eskalationsdruck beschrieben habe 📎, gilt strukturell auch hier: Modelle neigen dazu, bei unklaren Anweisungen in Richtung der Aktion zu tendieren, die ihnen am nächsten liegt. Wenn eine Prompt-Injektion einen Agenten in einem solchen Kontext trifft, ist die Bremse – der Mensch, der zustimmt – nicht vorhanden.
Das OWASP LLM Top 10 listet Prompt Injection als Risiko Nummer eins 📎 in KI-Anwendungen. In MCP-Umgebungen verschiebt sich die Konsequenz: Statt lediglich falschen Text zu generieren, löst eine erfolgreiche Injektion reale Aktionen in verbundenen Systemen aus. Der Unterschied zwischen einem Modell, das eine falsche Antwort gibt, und einem Modell, das auf Basis einer Injektion einen Managed Identity Token an eine externe Adresse überträgt, ist kein gradueller. Es ist ein kategorialer.
Was das für israelische Technologieunternehmen bedeutet
Das israelische Sicherheitsunternehmen Oasis Security 📎 – 2022 gegründet von Danny Brickman und Amit Zimerman, beide ehemalige Mitglieder der israelischen Intelligence Unit 81 – hat Mitte März 2026 eine Series-B-Runde über 120 Millionen Dollar abgeschlossen. Gesamtfinanzierung: 195 Millionen Dollar. Das Unternehmen positioniert sich explizit als Lösung für das Problem, das MCP in seiner schärfsten Form stellt: die Verwaltung und Absicherung von Machine Identities und KI-Agenten-Zugriffen auf kritische Unternehmenssysteme. Und Token Security, ebenfalls aus Tel Aviv 📎, präsentiert auf der RSAC 2026 Forschung, die zeigt, wie tief die Angriffsfläche im Azure-MCP-Stack bereits reicht.
Der Zeitpunkt ist kein Zufall. Er ist eine direkte Antwort auf eine Marktreaktion, die in den letzten sechs Monaten sichtbar geworden ist. Israel hat in der Container-Laufzeitsicherheit globale Standards gesetzt – Aqua Security, Sysdig und andere haben gezeigt, dass man Sicherheit in den Deployment-Stack integrieren kann, bevor ein Problem sichtbar wird. MCP-Sicherheit ist dieselbe Kategorie, eine Abstraktionsebene höher.
Was ich dabei beobachte: Der Markteintritt in Europa folgt oft derselben Logik wie bei früheren Produktkategorien – technische Überlegenheit als primäres Verkaufsargument, regulatorische Anschlussfähigkeit als nachgelagerte Überlegung. Ich habe das am Beispiel des europäischen Luftfahrtmarktes beschrieben 📎 und am CRA-Thema für Hardware-Hersteller ausgeführt 📎: Der Markt öffnet sich nicht entlang technologischer Leistungsfähigkeit, sondern entlang regulatorischer Anschlussfähigkeit.
Für MCP-Sicherheitsprodukte stellt sich dieselbe Frage mit zusätzlicher Dringlichkeit. Der Markt für KI-Agenten-Sicherheit in regulierten Branchen – Finanzdienstleister, kritische Infrastruktur, Gesundheitswesen – verlangt nicht nur ein funktionierendes Produkt. Er verlangt Nachweisfähigkeit. Auditierbarkeit. Die Fähigkeit zu zeigen, dass die eigene Lösung in eine NIS-2-konforme Governance-Struktur integrierbar ist, ohne neue Angriffsflächen zu schaffen. Wer das früh besetzt, hat einen strukturellen Vorteil. Wer es ignoriert, wird – wie im Trivy-Fall sichtbar – nicht an der Produktqualität scheitern, sondern an der Vertrauenslücke, die im Fall eines Incidents aufgeht.
Drei Fragen für den Montag
Wer in seiner Organisation KI-Assistenten mit MCP-Anbindung betreibt – oder plant, dies zu tun – sollte drei konkrete Fragen beantwortet haben, bevor der nächste Incident die Fragen stellt.
Erstens: Welche MCP-Server sind in Ihrer Umgebung aktiv, welche Dienste können sie erreichen, und wer hat sie installiert? In vielen Organisationen ist diese Liste nicht vorhanden. Das ist kein Sicherheitsproblem allein – es ist ein Governance-Problem, das als Teil der Drittparteien- und Lieferkettenrisiken dokumentiert sein muss. Shadow-MCP-Deployments – von Entwicklern ohne Security-Oversight installiert – kommen in der Praxis häufiger vor, als Security-Teams vermuten.
Zweitens: Wer überwacht die Integrität der Tool-Beschreibungen, auf die Ihre Modelle vertrauen? Tool-Beschreibungen sind der Angriffsvektor des Tool Poisoning. Eine Baseline zu haben und Abweichungen zu detektieren, ist technisch trivial – aber nur, wenn jemand die Aufgabe explizit übernommen hat. Wer das stille Versagen der SOC-Erkennungsinfrastruktur 📎 kennt, erkennt das Muster: Das System, das schützen soll, wird selbst nicht geprüft.
Drittens: Welche menschliche Bestätigungsschicht haben Sie für KI-Aktionen mit außenwirksamen Konsequenzen – Sendevorgänge, Dateitransfers, Credential-Nutzungen? Die Antwort „das Modell fragt nach“ ist keine ausreichende Antwort, sobald autonome Agenten in der Pipeline sind. Und die Antwort „wir haben Human-in-the-Loop“ schützt nicht gegen Prompt Injection – weil das Modell aus seiner eigenen Perspektive einen legitimen Befehl ausführt.
Wer diese drei Fragen beantworten kann, hat die wichtigste Vorarbeit geleistet. Was technisch daraus folgt, ist überschaubar: MCP-Server in isolierten Netzwerksegmenten betreiben, Tokens pro Tool auf das notwendige Minimum beschränken, ausgehende Requests auf validierte Endpunkte einschränken, Tool-Descriptions versionieren und auf Abweichungen monitoren, alle MCP-Aktionen in das bestehende Logging integrieren – nicht als separates Silo. Das sind keine neuen Disziplinen. Es sind bekannte Sicherheitsprinzipien, die auf eine neue Infrastrukturschicht angewendet werden müssen.
Diese Fragen haben keine regulatorischen Standardantworten. Sie verlangen Abwägung. Und sie verlangen, dass jemand in der Organisation diese Abwägung explizit vorgenommen und dokumentiert hat – bevor ein Regulator oder ein Incident die Dokumentation einfordert.
Was dieser Artikel nicht beantwortet
Wie weit CVE-2026-26118 in produktiven Azure-Umgebungen bereits ausgenutzt wurde, ist öffentlich nicht bekannt – Microsoft hat keine Exploitation-in-the-Wild gemeldet, aber der Proof-of-Concept zirkuliert. Was die „MCPwned“-Forschung von Token Security auf der RSAC 2026 konkret zeigen wird, ist zum Zeitpunkt dieses Artikels nicht vollständig veröffentlicht. Welche regulatorischen Einordnungen sich für Unternehmen ergeben, die KI-Agenten mit MCP-Anbindung in NIS-2-relevanten Systemen betreiben, ist noch nicht durch konkrete Behördenentscheidungen geformt – das OWASP MCP Top 10 in Beta ist ein erster Schritt in diese Richtung, kein Abschluss. Und die AuthZed-Timeline dokumentierter MCP-Sicherheitsvorfälle 📎 wächst schneller als die Governance-Infrastruktur, die diese Angriffe beherrschbar machen würde.
30 CVEs in 60 Tagen. Das ist kein Reifezeichen eines Protokolls, das unter Beobachtung steht. Es ist das Erkennungsrauschen einer Angriffsklasse, die gerade erst entdeckt wird.
Diese Lücke ist selbst ein Befund.
Eine persönliche Anmerkung: In meiner Arbeit als Executive Security Architect begleite ich israelische Technologieunternehmen beim Markteintritt in Deutschland und Europa – und zunehmend auch europäische Unternehmen dabei, KI-gestützte Architekturen so aufzubauen, dass sie den regulatorischen Anforderungen standhalten, die 2027 vollständig in Kraft sein werden. MCP ist das Thema, das in diesen Gesprächen zuletzt am häufigsten vorkommt – und gleichzeitig das, für das es die wenigsten validierten Antworten gibt. Das ist kein Hindernis. Es ist der Ausgangspunkt.
Sie integrieren KI-Assistenten in regulierte Umgebungen und fragen sich, welche MCP-bezogenen Risiken in Ihrer NIS-2-Dokumentation fehlen? Oder Sie entwickeln als israelisches Sicherheitsunternehmen eine Lösung für diesen Markt und suchen den Einstieg in den europäischen regulierten Sektor – wie ich es zuletzt im KRITIS-Kontext beschrieben habe 📎? Schreiben Sie mir direkt. 📎
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar