
Tierney - stock.adobe.com
MCP: Die Sicherheitsrisiken des Model Context Protocols
Das Model Context Protocol (MCP) erleichtert die Interaktion zwischen KI-Modellen und externen Diensten. Das bringt eine Reihe von Sicherheitsrisiken mit sich. Ein Überblick.
Das im November 2024 veröffentlichte Model Context Protocol (MCP) von Anthropic hat sich schnell zu einem Standard für die Verbindung von KI-Systemen mit externen Tools und Datenquellen entwickelt.
Obwohl MCP noch in den Kinderschuhen steckt, wird es bereits von vielen großen Technologieanbietern und einem weitreichenden Ökosystem von KI-Anwendern eingesetzt. Tausende verschiedener MCP-Server ermöglichen derzeit die Verbindung zu verschiedenen Anwendungen und Diensten von einem Desktop-Client aus.
Einer der größten Nachteile von MCP sind jedoch die damit verbundenen Sicherheitsrisiken. Es gibt viele dokumentierte Schwachstellen, und das Protokoll weist Mängel in Bezug auf Sicherheitsmechanismen und zentralisierte Verwaltung auf.
Daher müssen MCP-Benutzer die Funktionsweise des Protokolls, die damit verbundenen Risiken und Strategien zur Minderung von Schwachstellen verstehen. Fünf wesentliche MCP-Sicherheitsrisiken sind besonders hervorzuheben:
- Offenlegung von Anmeldedaten
- Nicht verifizierte MCP-Server von Drittanbietern
- Prompt-Injection-Angriffe
- Kompromittierte Server
- Bösartiger Code und unbeabsichtigte Aktionen

Wie MCP die KI-Modelle mit externen Diensten verbindet
MCP ermöglicht generativen KI-Clients die Kommunikation mit Drittanbieterdiensten, die drei Hauptfunktionen bieten:
- Ressourcen: Datendateien oder API-Antworten, die mit lokalen Dateien interagieren.
- Tools: Modellgesteuerte GPT-Funktionen, was bedeutet, dass Tools von Servern für Clients verfügbar gemacht werden, damit das KI-Modell sie automatisch aufrufen kann.
- Prompts: Vorab verfasste Eingabeaufforderungen, die dem Benutzer bei bestimmten Aufgaben helfen.
Die gesamte Logik wird vollständig von einem MCP-Server ausgeführt, einer Softwarekomponente, die lokal auf dem Rechner installiert ist, auf dem sie ausgeführt wird.
Damit MCP mit einem Drittanbieterdienst kommunizieren kann, muss es sich bei diesem authentifizieren können. Dazu ist häufig ein API-Schlüssel oder ein Geheimnis erforderlich, das lokal auf dem Rechner gespeichert ist.
Im März 2025 fügte MCP die OAuth-Spezifikation hinzu, ein Autorisierungsframework, das es einer Anwendung ermöglicht, ohne Weitergabe von Anmeldedaten auf externe Ressourcen zuzugreifen. Dadurch können Benutzer Remote-MCP-Server ausführen. Allerdings haben noch nicht alle Benutzer diese Funktion implementiert; viele betreiben weiterhin Server mit lokalen API-Schlüsseln.
5 MCP-Sicherheitsrisiken und Strategien zu ihrer Eindämmung
MCP ermöglicht KI-Systemen den Zugriff auf Daten, die Verwendung von Tools von Drittanbietern und die Ausführung von Befehlen. Diese Fähigkeiten bringen erhebliche Sicherheitsrisiken mit sich. Im Folgenden werden fünf MCP-Sicherheitsrisiken und Strategien zu ihrer Eindämmung vorgestellt.
1. Offenlegung von Anmeldedaten
Ein Hauptrisiko bei MCP ist die Offenlegung von Anmeldedaten. Oftmals umfasst die MCP-Konfiguration API-Schlüssel, die direkt in eine Konfigurationsdatei eingefügt werden, wie beispielsweise beim Claude-Desktop. Jemand, der den Client kompromittiert hat, könnte auf diese Schlüssel zugreifen und möglicherweise auf die Jira-Instanz zugreifen, wie in Abbildung 2 dargestellt.

Wenn der Server dies unterstützt, ist die Verwendung von OAuth mit Remote-MCP-Servern eine Möglichkeit, das Risiko einer Offenlegung von Anmeldedaten zu verringern. Benutzer können auch eine Proxy-Komponente hinzufügen, beispielsweise Cloudflare oder Azure API Management, die eine OAuth-Authentifizierung vor dem MCP-Server bereitstellt.
Wenn der Server OAuth nicht unterstützt, besteht die einzige Möglichkeit, das Risiko einer Offenlegung von Anmeldedaten zu minimieren, darin, Zugriffsschlüssel in der Konfiguration zuzuweisen. Dies sollte jedoch nach Möglichkeit vermieden werden, da dadurch zusätzliche Sicherheitsrisiken und Verwaltungsprobleme entstehen.
Außerdem gibt es keine optimale Methode, um die MCP-Konfiguration an Clients zu verteilen. Eine Möglichkeit wäre die Bereitstellung einer zentralisierten virtuellen Desktop-Infrastruktur (VDI), über die Endbenutzer auf einen MCP-fähigen Client zugreifen können. Dadurch wird sichergestellt, dass API-Schlüssel nur auf zentralisierten Rechnern verfügbar sind.
2. Nicht verifizierte MCP-Server von Drittanbietern
Viele öffentlich zugängliche MCP-Server werden von Community-Mitgliedern und nicht verifizierten Quellen erstellt.
Obwohl die meisten davon technisch funktionieren, werden sie oft nicht gewartet und weisen Sicherheitslücken auf – einige sind sogar absichtlich bösartig programmiert, um Tokens oder API-Schlüssel zu sammeln, während sie scheinbar normal funktionieren.
Benutzer sollten nur offizielle MCP-Server von vertrauenswürdigen Anbietern verwenden, wie beispielsweise den öffentlichen GitHub-Server github/github-mcp-server. Viele große Technologieunternehmen verfügen mittlerweile über eine eigene Liste mit verifizierten MCP-Servern. Microsoft beispielsweise führt eine Liste mit MCP-Servern.
3. Prompt-Injection-Angriffe
Ein weiteres großes Sicherheitsrisiko bei MCP sind Prompt-Injection-Angriffe und Tool Poisoning.
Angreifer können versteckte Eingabeaufforderungen oder bösartige Anweisungen in die Metadaten eines Tools einschleusen. Benutzer bemerken nichts Ungewöhnliches, aber das LLM könnte diese Prompts als legitime Befehle behandeln – und damit die Tür für Datenlecks oder andere unbefugte Aktionen öffnen.
Ein Großteil dieses Risikos lässt sich durch die Verwendung von verifizierten und vertrauenswürdigen MCP-Servern und Tools von Drittanbietern vermeiden.
4. Kompromittierte Server
Ein weiteres Sicherheitsrisiko von MCP besteht darin, dass ein böswilliger Akteur einen Community-MCP-Server kompromittiert und die Quelle durch bösartige Inhalte ersetzt.
Da die meisten MCP-Server entweder mit dem Befehl pip install oder npm install installiert werden, haben Benutzer nur begrenzte Möglichkeiten, festzustellen, ob eine MCP-Komponente kompromittiert wurde, es sei denn, sie verwenden einen Package Analyzer eines Drittanbieters.
5. Bösartiger Code und unbeabsichtigte Aktionen
MCP kann auf Dateisysteme zugreifen und Befehle direkt auf dem Host ausführen, von dem aus es ausgeführt wird. Daher tritt ein weiteres Risikoszenario auf, wenn MCP beliebigen Code direkt aus einer Malware-Datei ausführt.

Dies kann passieren, wenn ein Benutzer sich der Risiken nicht bewusst ist, die mit den Aktionen des MCP-Servers verbunden sind. Sobald ein Benutzer beispielsweise einen MCP-Server konfiguriert hat, hat er nur noch die Möglichkeit, ein bestimmtes Tool zu blockieren oder zuzulassen. Wenn dies zugelassen wird, kann das KI-Modell unbeabsichtigte Aktionen ausführen, beispielsweise das Löschen eines Benutzers oder Objekts.
Es gibt einige Maßnahmen, mit denen dieses Sicherheitsrisiko minimiert werden kann.

Eine Möglichkeit besteht darin, sicherzustellen, dass MCP-Server in einer isolierten Umgebung mit eingeschränktem Zugriff auf den Rechner ausgeführt werden, beispielsweise durch Ausführen der Komponenten in einem Docker-Container. Einige MCP-Server bieten eine entsprechende Option oder sind im Docker MCP Hub aufgeführt.
Eine weitere Strategie zur Risikominderung besteht darin, Befehle und Tools zu deaktivieren, die Lese- oder Ausführungsberechtigungen von einem MCP-Server aus ermöglichen, wie in Abbildung 4 dargestellt. Leider muss dies lokal auf jedem Rechner erfolgen, oft in Kombination mit einem API-Schlüssel, der nur Lesezugriff auf ein System oder einen Dienst erlaubt.