01Was MCP ist – und warum es Angriffsfläche schafft
Das Model Context Protocol verbindet KI-Anwendungen über eine einheitliche Schnittstelle mit Tools, Datenquellen und APIs; MCP-Server agieren dabei als Brücke und oft mit delegierten Nutzerberechtigungen. Dynamische Tool-Einbindung zur Laufzeit, implizite Vertrauensbeziehungen zwischen Komponenten und geteilte Kontexte schaffen Angriffspfade, die klassische API-Sicherheit nicht abdeckt. Hinzu kommt: Das Protokoll definiert weder verpflichtende Zugriffskontrolle noch Token-Lifecycle-Management – sichere Umsetzung liegt vollständig bei den Implementierern.
02MCP-spezifische Bedrohungen
Zu den zentralen Risiken zählen Tool Poisoning (versteckte Anweisungen in Tool-Beschreibungen), Rug Pulls (nachträglicher Austausch bereits freigegebener Tool-Definitionen) und Code Injection durch ungeprüft weitergereichte Modell-Eingaben. Token Passthrough erzeugt ein Confused-Deputy-Risiko: Der MCP-Server wird missbraucht, um mit fremden Nutzerrechten unautorisierte Aktionen auszuführen; unsicher gespeicherte API-Keys und OAuth-Tokens ermöglichen Credential-Diebstahl. Reale Vorfälle – von der Exfiltration privater GitHub-Repositories über abgeflossene WhatsApp-Nachrichten bis zur RCE-Schwachstelle CVE-2025-49596 im MCP Inspector – belegen, dass diese Angriffe praktisch funktionieren.
03Server-seitige Härtung
Der OWASP-Leitfaden fordert OAuth 2.1/OIDC für alle Remote-MCP-Server, kurzlebige und eng gescopte Tokens sowie Schema-Validierung sämtlicher Ein- und Ausgaben. Nutzer und Sessions sind strikt zu isolieren, Tool-Ausführung gehört in gehärtete Sandboxes (Container, seccomp/AppArmor) mit minimalen Rechten und segmentiertem Netzwerk. Secrets liegen in Vaults und dürfen dem LLM zu keinem Zeitpunkt zugänglich sein.
04Client- und Host-Absicherung
Wiz Research empfiehlt, nur MCP-Server aus vertrauenswürdigen Quellen einzusetzen und sie vor der Nutzung wie privilegierte Software-Pakete zu auditieren – Auto-Installation und Auto-Run von Tools sind Hochrisiko-Muster. Ein reifer MCP-Client mit Freigabe-Dialogen, Berechtigungsmanagement und Human-in-the-Loop für kritische Aktionen begrenzt den Schaden kompromittierter Server. Ein zentrales MCP-Gateway und Allowlisting im Host bündeln Audit-Logging, Guardrails und Richtliniendurchsetzung an einem Kontrollpunkt.
05Erkennung und Betrieb
Alle Tool- und Modell-Aufrufe sollten inklusive Parametern und beteiligten Identitäten protokolliert und in bestehende SIEM- und Detection-Pipelines integriert werden. Die NSA empfiehlt zudem, das eigene Netz regelmäßig auf unauthentifizierte, verwundbare oder nicht freigegebene MCP-Server zu scannen – da MCP-Server Ports dynamisch wechseln können, sind periodische Scans mit Differenzberichten sinnvoll. Ergänzend gehört ein formaler Prozess zur Beobachtung MCP-bezogener Schwachstellen (CVEs, Herstelleradvisories) in den Regelbetrieb.
06Governance und Freigabeprozess
Kein Tool und keine Tool-Änderung sollte ohne formalen Freigabeprozess produktiv gehen: Code-Scanning (SAST), Dependency-Analyse (SCA) und manuelles Security-Review sind Pflicht. Signierte Tool-Manifeste mit Version-Pinning sichern die Integrität; die beworbene Funktionalität einer Tool-Beschreibung ist gegen das tatsächliche Laufzeitverhalten zu validieren. Ein gepflegtes Inventar aller eingesetzten MCP-Server und -Tools mit Versionen und Patch-Historie beschleunigt Triage und Reaktion, wenn neue Schwachstellen bekannt werden.
