MCP- und Agenten-Sicherheit
MCP-Server absichern: der praktische Leitfaden
Einen MCP-Server abzusichern heißt, drei Dinge zu kontrollieren: wer mit ihm reden darf, was er tun darf und welchen Eingaben er vertraut. Denn ein MCP-Server ist kein harmloses Plugin. Er ist ein Programm, das mit vollem Zugriff auf die Systeme, Daten und Schlüssel des Agenten läuft. Deshalb vergrößert jeder MCP-Server die Angriffsfläche einer Anwendung erheblich.
- Auf jedem Transport authentifizieren, nie auf loopback vertrauen, Host und Origin exakt prüfen (DNS-Rebinding).
- Bei OAuth den Authorization-Server und die Metadaten-Herkunft pinnen, Scope auf das nötige Minimum begrenzen.
- Nicht vertrauenswürdige Inhalte und Tool-Metadaten als Daten behandeln, nie als Anweisung (Prompt-Injection und Tool-Poisoning).
- Jedes Tool mit minimalen Rechten (Least Privilege), destruktive und ausgehende Aktionen mit Bestätigung.
- Secrets nie loggen, spiegeln oder weiterreichen, ausgehende Abrufe gegen eine Host-Allowlist sperren (SSRF).
- Sichere Standardwerte: kein 0.0.0.0-Bind, keine Wildcard-Allowlist, keine mitgelieferten Default-Schlüssel.
Warum ein MCP-Server ein Sicherheitsrisiko ist
Das Model Context Protocol (MCP) verbindet KI-Agenten mit Werkzeugen, Daten und APIs. Der MCP-Server sitzt genau an dieser Nahtstelle. Er nimmt Anfragen des Agenten entgegen, ruft im Hintergrund echte Systeme auf und gibt Ergebnisse zurück. Zwei Eigenschaften machen ihn heikel. Erstens läuft er mit den Rechten und Zugangsdaten des Betreibers. Ein kompromittierter Server handelt also mit voller Vollmacht. Zweitens kann das Modell echte Nutzereingaben nicht zuverlässig von eingeschleusten Inhalten aus einer Datenquelle trennen. Genau das ermöglicht indirekte Prompt-Injection.
Die häufigsten Schwachstellen-Klassen
Als gemeinsame Referenz hat sich die OWASP MCP Top 10 etabliert, das erste offene Sicherheits-Framework speziell für MCP. Die folgende Übersicht ordnet die Klassen nach ihrer praktischen Häufigkeit und benennt bewusst keine konkreten verwundbaren Produkte.
| Klasse | Kern des Problems |
|---|---|
| Fehlende Transport-Authentifizierung | Ein Endpunkt ohne Auth, im Vertrauen auf loopback. Jeder lokale Prozess oder eine Webseite per DNS-Rebinding steuert dann die Tools mit den Zugangsdaten des Betreibers (Confused Deputy). |
| Fehler im OAuth-Vertrauensanker | MCP nutzt OAuth 2.1. Wird der Authorization-Server oder die Protected-Resource-Metadata nicht auf eine feste Herkunft gepinnt, kann ein Angreifer den Token-Fluss umlenken oder einen zu breiten Scope erzwingen. |
| Indirekte Prompt-Injection und Tool-Poisoning | Tools geben nicht vertrauenswürdige Inhalte oder manipulierte Tool-Beschreibungen zurück. Eingeschleuste Anweisungen erreichen die schreibenden oder ausführenden Tools des Servers. |
| Zu breite Berechtigungen | Ein Tool kann weit mehr als der Anwendungsfall braucht, etwa das ganze Dateisystem oder beliebiges SQL. Ein einziger Fehler eskaliert dadurch zum Vollzugriff. |
| Secret- und Credential-Leck | Tokens landen in Logs, werden gespiegelt oder ungeprüft an ein fremdes Ziel weitergereicht. Auch der Reverse-Channel über sampling und elicitation gehört hierher. |
| SSRF und ungefilterte Abrufe | Ein Tool lädt eine vom Aufrufer bestimmte URL ohne Host-Allowlist und ohne Sperre interner Adressen. |
| Unsichere Standardwerte | 0.0.0.0-Bind, Wildcard-Allowlist, DNS-Rebinding-Schutz aus, mitgelieferte Default-Signierschlüssel. Der Angriff braucht keinen Exploit, nur den unveränderten Standard. |
| Denial of Service | Unauthentifizierte Session-Erschöpfung oder unbegrenzte Dekompression legen den Server lahm. |
Die konkrete Absicherung
Jede Klasse hat eine strukturelle Gegenmaßnahme. Die folgende Checkliste ist der Kern der Absicherung.
Zugang kontrollieren
- Auf jedem Transport-Einstieg authentifizieren, ein per-Installation-Geheimnis auf jeder Route.
- Standardmäßig auf 127.0.0.1 binden, Host und Origin exakt gegen eine Allowlist prüfen, DNS-Rebinding-Schutz aktivieren.
- Bei OAuth die Herkunft von Authorization-Server und Metadaten pinnen, den angefragten Scope mit der tatsächlichen Berechtigung schneiden, die Audience des Tokens prüfen.
Eingaben misstrauen
- Nicht vertrauenswürdige Tool-Ausgaben klar als Daten kennzeichnen, nie als Anweisung interpretieren.
- Destruktive und ausgehende Tools nur mit expliziter Bestätigung, Lese- und Handlungsrechte trennen.
- Server-initiierte sampling- und elicitation-Anfragen nur mit ausdrücklicher Nutzer-Zustimmung, nie automatisch mit privatem Kontext füllen.
Wirkung begrenzen
- Jedes Tool auf das Minimum seines Anwendungsfalls beschränken, kein Universal-Werkzeug.
- Ausgehende Abrufe gegen eine Scheme- und Host-Allowlist sperren, loopback, link-local und interne Bereiche blocken, Redirects aus.
- Secrets nie loggen, spiegeln oder weiterreichen, Aufrufe host-seitig brokern, damit Geheimnisse nie beim ungeprüften Code liegen.
- Sicher per Default starten, riskante Modi nur mit ausdrücklichem Opt-in, in offensichtlich unsicheren Kombinationen den Start verweigern.
Diese Kontrollen greifen am besten, wenn sie von Anfang an in die Integration eingebaut werden statt nachträglich. Wer einen MCP-Server nicht nur prüfen, sondern von Grund auf sicher in Fachsysteme wie DATEV, Lexoffice oder Personio integrieren lassen will, findet das bei der Workflow-Agentur, MCP-Integration mit Sicherheits-Fokus.
Wie man prüft, ob ein MCP-Server wirklich sicher ist
Eine Checkliste abzuhaken ist nicht dasselbe, wie zu wissen, dass die Kontrollen halten. Ein reiner Muster-Scanner findet nur das bekannt Schlechte. Viele MCP-Risiken liegen aber im Design von Fähigkeiten und Vertrauensgrenzen, nicht in bekannten Code-Mustern. Belastbare Sicherheit braucht deshalb zwei Ebenen. Die erste ist eine statische Prüfung gegen definierte Invarianten. Die zweite ist eine dynamische Prüfung, die jeden Befund mit einem ausgeführten Nachweis belegt, statt ihn nur zu vermuten. Genau diese Disziplin trennt einen belastbaren Bericht von einer Liste falscher Alarme: jeder Einzelbefund wird vor der Meldung verifiziert.
Ist Ihr MCP-Server belastbar sicher?
In einem kostenlosen Erstgespräch benennen wir die eine Eigenschaft, von der Ihr Produkt abhängt, und ob sie belegbar ist. Jeder Befund kommt mit einem Proof of Concept, nicht mit einer Vermutung.
Erstgespräch anfragenCyberSec42 ist eine unabhängige technische Sicherheitsprüfung, keine akkreditierte Zertifizierungsstelle.
Häufige Fragen
Ist ein MCP-Server ein Sicherheitsrisiko?
Ja, sobald er nicht abgesichert ist. Ein MCP-Server läuft mit vollem Zugriff auf die Systeme und Zugangsdaten des Betreibers. Ohne Authentifizierung, Least Privilege und Schutz gegen Prompt-Injection kann ein kompromittierter oder fehlkonfigurierter Server mit voller Vollmacht handeln.
Wie sichere ich einen MCP-Server ab?
Kontrollieren Sie drei Dinge: den Zugang (Authentifizierung auf jedem Transport, Host- und Origin-Prüfung, OAuth-Pinning), die Rechte (Least Privilege pro Tool, Bestätigung für destruktive Aktionen) und die Eingaben (nicht vertrauenswürdige Inhalte als Daten behandeln, SSRF und Secret-Leaks verhindern). Starten Sie sicher per Default.
Was ist die OWASP MCP Top 10?
Die OWASP MCP Top 10 ist das erste offene Sicherheits-Framework speziell für das Model Context Protocol. Es listet die zehn kritischsten Risiko-Klassen von MCP-Servern und dient als gemeinsame Referenz für Entwickler und Security-Teams.
Reicht ein Scanner, um einen MCP-Server zu prüfen?
Nein, ein Scanner allein reicht nicht. Muster-Scanner finden bekannte Code-Muster, aber viele MCP-Risiken liegen in Berechtigungs-Design und Vertrauensgrenzen. Belastbar wird die Prüfung erst mit einer invariantenbasierten Analyse und einem ausgeführten Nachweis pro Befund.
Braucht mein MCP-Server einen Penetrationstest?
Wenn der Server Zugriff auf produktive Daten, Systeme oder Zugangsdaten hat, ja. Gerade vor dem ersten großen Enterprise-Kunden ist ein belastbarer Sicherheitsnachweis oft eine Voraussetzung im Einkauf.