Model Context Protocol Sicherheitsrisiken und Datenströme

Während die Tech-Welt über KI-Agenten jubelt, die endlich mit der echten Welt sprechen können, öffnet sich leise eine Tür, die niemand bewacht. Das Model Context Protocol – kurz MCP – ist der Standard, der genau das möglich macht: Ein universelles Protokoll, über das KI-Assistenten auf Datenbanken, APIs, Dateisysteme und Cloud-Services zugreifen. Anthropic hat es Ende 2024 als Open-Source-Standard veröffentlicht, und innerhalb weniger Monate haben alle großen Player nachgezogen. [1]

Das Problem: MCP wurde für Entwickler gebaut, nicht für Compliance-Abteilungen. Und genau dort, wo der Komfort aufhört und die Governance anfangen müsste, klafft ein Loch, das die meisten Unternehmen noch nicht einmal bemerkt haben.

Ein Protokoll, das alles verbindet – und nichts kontrolliert

MCP funktioniert nach einem simplen Prinzip: Ein Client (der KI-Agent) verbindet sich mit einem Server (der Datenquelle), und der Server stellt Tools, Ressourcen und Prompts bereit. Das ist elegant. Das ist mächtig. Und das ist gefährlich.

Denn die offizielle MCP-Spezifikation setzt ausdrücklich keine Sicherheit auf Protokollebene durch. [2] Keine Authentifizierung, keine Autorisierung, kein Audit-Logging – all das liegt vollständig in der Verantwortung der Implementierer. In der Praxis bedeutet das: Der durchschnittliche MCP-Server, den ein begeisterter Entwickler an einem Nachmittag aufsetzt, hat die Zugriffskontrolle eines offenen WLAN in einem Café.

Die meisten heute verfügbaren MCP-Server wurden für einzelne Entwickler und kleine Teams konzipiert. [3] Ein MCP-Server mit starken Governance-Kontrollen – Authentifizierung, Autorisierung, Logging, Rate Limiting – ermöglicht eine sichere, revisionssichere KI-Integration. Ein MCP-Server ohne diese Kontrollen erlaubt der KI alles, was der Service-Account darf, unter dem sie läuft. Ohne nutzerbezogene Einschränkungen. Ohne Logging. Ohne Compliance-Dokumentation.

Und hier wird es heikel: In Unternehmen entstehen MCP-Server nicht durch zentrale IT-Entscheidungen. Sie entstehen, weil ein Team in der Marketingabteilung ChatGPT an das CRM anschließen will, weil ein Analyst Claude mit der internen Datenbank verbindet, weil ein Entwickler einen Prototyp baut und vergisst, ihn wieder abzuschalten. Die Schatten-IT der KI-Ära hat einen neuen Namen: Schatten-MCP.

Die fünf Angriffsvektoren, die niemand auf dem Schirm hat

Die konkreten Risiken von unkontrollierten MCP-Implementierungen sind keine theoretischen Szenarien. Sie sind dokumentiert, kategorisiert und in mehreren Sicherheits-Whitepapers analysiert. [4]

Prompt Injection über Kontextmanipulation. Der kritischste Angriffsvektor. Ein kompromittierter MCP-Server kann in seinen Antworten versteckte Anweisungen einbetten – in Textfeldern, Notizen, Logs oder Dokumenten. Der KI-Agent interpretiert diese als legitime Instruktionen und führt sie aus. Das reicht von der Exfiltration sensibler Daten bis zur Manipulation von Geschäftsentscheidungen. [5]

Credential-Diebstahl durch Konfigurationslecks. MCP-Konfigurationen enthalten typischerweise API-Keys, die direkt in Konfigurationsdateien stehen. Wer Zugriff auf eine claude_desktop_config.json oder eine .env-Datei hat, erbt sämtliche Berechtigungen des verbundenen Service-Accounts. Langlebige API-Keys und übermäßig großzügige OAuth-Scopes sind die Regel, nicht die Ausnahme.

Server-Kompromittierung über die Supply Chain. Community-MCP-Server werden selten auditiert. Ein manipulierter Server kann Tool-Verhalten ändern, Prompts vergiften oder neue, bösartige Tools einschleusen – und der Agent bemerkt den Unterschied nicht. [5]

Über-Privilegierung durch Komfort. Während der Pilotphase gewährte Berechtigungen bleiben in der Produktion bestehen. Ein MCP-Server, der für einen Proof-of-Concept vollen Datenbankzugriff bekam, behält diesen Zugriff, wenn niemand die Scopes reduziert.

Audit-Blindheit. Ohne umfassendes Logging – wer hat wann mit welchem Tool welche Parameter aufgerufen und welches Ergebnis erhalten – kann kein Unternehmen Missbrauch erkennen, Vorfälle untersuchen oder Compliance nachweisen.

Der Single Point of Failure im Herzen der KI-Infrastruktur

Model Context Protocol Zugriffskontrolle im Unternehmensumfeld

Was MCP von herkömmlichen API-Integrationen unterscheidet, ist die Aggregation. Ein einzelner MCP-Server kann Anmeldedaten für Dutzende von Unternehmensservices bündeln – Slack, Jira, Confluence, die interne Datenbank, das CRM, das Dateisystem. [5] Ein kompromittierter MCP-Server ist kein isolierter Vorfall. Er ist ein Schlüsselbund zu allem, was das Unternehmen hat.

Anthropic hat dieses Risiko erkannt und reagiert. Die Übernahme von Stainless – dem führenden Anbieter für automatische SDK-Generierung und MCP-Tooling – im Mai 2026 ist ein strategischer Zug, um die Qualität und Sicherheit der MCP-Infrastruktur zentral zu kontrollieren. [6] Stainless hat jedes offizielle Anthropic SDK seit den frühesten Tagen der Claude API generiert. Hunderte von Unternehmen nutzen ihre Tools, um SDKs, CLIs und MCP-Server zu erstellen.

Aber Anthropic kann nicht jede wilde MCP-Implementierung kontrollieren, die in Unternehmen entsteht. Die CoSAI (Coalition for Secure AI) hat in einem Whitepaper mehr als 40 MCP-Bedrohungen identifiziert, die die meisten Organisationen nicht adressieren. [4] Cloudflare hat eine eigene MCP-Architektur vorgestellt, die Gateway-Layer und zentrale Governance-Kontrollen für Unternehmen implementiert. [7] Red Hat warnt explizit, dass die Implementierungsverantwortung für Sicherheit vollständig bei den Security-Teams liegt – das Protokoll selbst liefert keine. [3]

Die Industrie reagiert. Aber sie reagiert auf ein Problem, das bereits in Tausenden von Unternehmen existiert, während die Sicherheitsteams noch diskutieren.

Warum klassische Sicherheitsmodelle versagen

Das fundamentale Problem mit MCP ist nicht technischer Natur. Es ist konzeptionell. Klassische IT-Sicherheit operiert mit klaren Grenzen: Netzwerke haben Perimeter, Anwendungen haben definierte APIs, Benutzer haben Rollen und Berechtigungen. MCP löst all diese Grenzen auf.

Ein KI-Agent mit MCP-Zugriff operiert nicht wie ein Benutzer, der sich an ein System anmeldet. Er operiert wie ein Benutzer, der sich gleichzeitig an alle Systeme anmeldet und Aktionen über Systemgrenzen hinweg orchestriert. Die Frage „Wer hat Zugriff auf was?" wird ersetzt durch „Welcher Kontext fließt wohin?" – und auf diese Frage hat kein bestehendes Identity-and-Access-Management eine Antwort.

Verschärft wird das durch die Dynamik der Agenten-Ära. MCP-Server können Tools dynamisch bereitstellen und ändern. Ein Agent, der heute nur lesen kann, könnte morgen schreiben – weil jemand den Server aktualisiert hat, ohne die Sicherheitsimplikationen zu bedenken. Das ist keine hypothetische Sorge. Das ist die Realität in jedem Unternehmen, das MCP ohne zentrale Governance betreibt.

Die Empfehlung der Sicherheitsforscher ist eindeutig: Zero-Trust für Konnektoren. [5] Default-Deny. Nur explizit freigegebene Server und Tools erlauben. Minimale Berechtigungen. Kurzlebige, scoped Tokens statt langlebiger API-Keys. Unveränderliches Audit-Logging. Anomalie-Erkennung für ungewöhnliche Tool-Aufrufe.

Das klingt nach Standard-Sicherheitshygiene. Ist es auch. Aber in der Praxis tut es fast niemand.

Was Unternehmen jetzt konkret tun müssen

Die gute Nachricht: MCP ist kein Sicherheitsproblem, das unlösbar ist. Es ist ein Governance-Problem, das lösbar wird, sobald man es als solches behandelt. Veeam und andere Sicherheitsanbieter empfehlen einen konkreten Fahrplan. [5]

Erstens: Inventarisierung. Finden Sie heraus, welche MCP-Server in Ihrem Unternehmen laufen. Nicht nur die offiziellen – vor allem die inoffiziellen. Jede Abteilung, die KI-Tools nutzt, ist ein potenzieller MCP-Betreiber. Die IT-Abteilung muss wissen, welche Kontextquellen angeschlossen sind, bevor sie über Kontrollen nachdenken kann.

Zweitens: Policy Enforcement Gateway. Setzen Sie einen zentralen Kontrollpunkt ein, durch den alle MCP-Verbindungen laufen. Allowlisting, Request/Response-Inspektion, Egress-Kontrollen. Kein MCP-Server darf direkt mit dem Internet kommunizieren, ohne dass jemand mithört.

Drittens: Least Privilege by Design. Starten Sie mit Read-Only. Immer. Schreibzugriffe nur nach expliziter Freigabe, mit dokumentierter Begründung und zeitlicher Begrenzung. Jeder MCP-Server bekommt nur die minimalen Berechtigungen, die für seinen spezifischen Anwendungsfall nötig sind.

Viertens: Immutable Audit Logging. Protokollieren Sie jede Interaktion: Identität, Tool-Name, Parameter, Ergebnis, Zeitstempel. Diese Logs müssen unveränderlich sein – nicht in derselben Infrastruktur, die sie überwachen.

Fünftens: Anomalie-Erkennung. Überwachen Sie Tool-Call-Spikes, ungewöhnliche Sequenzen und abnormale Datenvolumen. Ein Agent, der plötzlich tausend Datenbankabfragen pro Minute absetzt, ist entweder falsch konfiguriert oder kompromittiert. Beides muss sofort erkennbar sein.

Der Kontext ist das neue Öl – und ebenso brennbar

MCP ist nicht das Problem. MCP ist die Lösung für ein echtes Interoperabilitätsproblem. Aber jede Lösung, die mächtig genug ist, um nützlich zu sein, ist mächtig genug, um gefährlich zu sein.

Die Unternehmen, die MCP jetzt richtig einführen – mit Governance, mit Kontrolle, mit Bewusstsein für die Risiken – werden einen strukturellen Vorteil haben. Ihre KI-Agenten werden mehr können, schneller arbeiten, bessere Ergebnisse liefern. Die Unternehmen, die MCP ignorieren oder unkontrolliert wuchern lassen, werden eines Tages feststellen, dass ihr wertvollstes Asset – der Kontext ihrer Geschäftsprozesse, ihrer Kunden, ihrer Strategien – durch eine Tür abgeflossen ist, die nie jemand bewacht hat.

Die Frage ist nicht, ob Sie MCP einsetzen. Diese Entscheidung haben Ihre Mitarbeiter bereits für Sie getroffen. Die Frage ist, ob Sie wissen, welche Türen offen stehen.

Referenzen

  1. Anthropic – Model Context Protocol (MCP) Open-Source-Veröffentlichung und Spezifikation
    https://modelcontextprotocol.io
  2. Red Hat – Model Context Protocol (MCP): Understanding Security Risks and Controls
    https://www.redhat.com/en/blog/model-context-protocol-mcp-understanding-security-risks-and-controls
  3. TechZeitgeist – MCP einfach erklärt: Warum KI-Agenten neue Schnittstellen und neue Sicherheitsregeln brauchen
    https://www.techzeitgeist.de/mcp-model-context-protocol-ki-agenten-sicherheit-erklaert/
  4. CoSAI/OASIS – Model Context Protocol Security Whitepaper, über 40 identifizierte Bedrohungen, 2026
    https://github.com/cosai-oasis/ws4-secure-design-agentic-systems/blob/main/model-context-protocol-security.md
  5. Veeam – Model Context Protocol (MCP) Security Risks Explained
    https://www.veeam.com/blog/model-context-protocol-security-risks.html
  6. Anthropic – Übernahme von Stainless zur Stärkung der KI-Agenten-Konnektivität, Mai 2026
    https://www.anthropic.com/news/anthropic-acquires-stainless
  7. InfoQ – Cloudflare Outlines MCP Architecture as Enterprises Confront Security and Governance Risks, April 2026
    https://www.infoq.com/news/2026/04/cloudflare-mcp/