KI-SicherheitSchwachstellenHackerangriffe

Model Context Protocol: Warum KI-Sicherheitslücken nicht einfach zu patchen sind

Model Context Protocol: Warum KI-Sicherheitslücken nicht einfach zu patchen sind
Zusammenfassung

Das Model Context Protocol (MCP) ermöglicht es Organisationen, ihre KI-gestützten Anwendungen mit externen Datenquellen und Services zu verbinden. Doch diese Integration birgt fundamentale Sicherheitsrisiken, die sich nicht durch klassische Patches oder Konfigurationsänderungen beheben lassen. Anders als herkömmliche LLM-Anwendungen, die nur Antworten generieren, können MCP-fähige Systeme autonom echte Aktionen ausführen – von der Verwaltung von Kalendern bis zum Zugriff auf Unternehmensdaten. Dies eröffnet Angreifern neue Angriffsvektoren: Sie können versteckte Befehle in E-Mails oder Dokumenten einschleusen, die das Modell nicht von legitimen Inhalten unterscheiden kann, oder Metadaten von MCP-Tools manipulieren. Besonders kritisch sind indirekte Prompt-Injections, bei denen ein vergifteter E-Mail einen koordinierten Datendiebstahl über mehrere verbundene Services hinweg auslösen könnte. Deutsche Unternehmen und Behörden, die verstärkt auf KI-Integration setzen, müssen sich dieser architektonischen Schwachstellen bewusst sein und entsprechende Schutzmaßnahmen implementieren – von strenger Zugriffskontrolle bis zur kontinuierlichen Überwachung von MCP-Verkehren.

Das Kernproblem liegt in einer fundamentalen Schwäche von LLMs: Sie können nicht zwischen reinen Inhalten und ausführbaren Anweisungen unterscheiden. Wenn ein MCP-Connector externe Quellen wie E-Mails oder Dokumente abruft, verarbeitet das Modell alles als Input-Daten – sowohl legitime Inhalte als auch versteckte Befehle.

Cutolo beschreibt ein konkretes Szenario: Ein Angreifer sendet eine E-Mail mit normalem Text und versteckten Anweisungen an eine Person. Wenn diese ihr KI-Assistenten bittet, die E-Mail zusammenzufassen, wird der MCP-Connector die gesamte Nachricht abrufen und in den Kontext des LLMs einzuspeisen – inklusive der böswilligen Instruktionen. Das System könnte dann beispielsweise Dateien exfiltrieren oder im Namen des Nutzers E-Mails versenden, ohne dass dieser etwas davon mitbekommt. Bei Umgebungen mit mehreren MCP-Connectors zu lokalen Dateien, Jira, Google Drive und anderen Services kann eine einzige vergiftete E-Mail koordinierte Angriffe über alle diese Dienste hinweg auslösen.

Ein zweites Angriffsverfahren ist die sogenannte “Tool Poisoning”. Wenn ein LLM einen MCP-Server kontaktiert, fragt es zunächst alle verfügbaren Funktionen, deren Beschreibungen und Parameter ab. Ein Angreifer kann böswillige Anweisungen direkt in diese Metadaten einschleusen – wiederum mit dem Ziel, dass das Modell diese als Inhalte verarbeitet und ausführt.

Die dritte Bedrohung ist ein “Rug Pull”: Der Betreiber eines MCP-Servers oder ein Angreifer mit Zugriff darauf könnte diesen böswillig verändern. Das Protokoll hat keinen Mechanismus, um MCP-Clients über Änderungen zu benachrichtigen. Ein einst sicherer Server könnte also unbemerkt gehackt werden und dann malware Anweisungen an die KI-Agenten senden.

Weil diese Probleme in der Architektur selbst verankert sind, können sie nicht durch Patches oder Konfigurationsänderungen gelöst werden. Cutolo empfiehlt stattdessen: MCP-Server nach Datentyp trennen (privat vs. öffentlich), verdächtige Muster in Inhalten scannen, Menschen in sicherheitskritische Entscheidungen einbeziehen, alle Server inventarisieren und mit Minimal-Berechtigungen ausstatten, MCP-Verkehr protokollieren und KI-Verhalten auf Anomalien überwachen. Diese Maßnahmen erfordern ein Umdenken in der Sicherheitsarchitektur von KI-Systemen.