Die neue MCP-Spezifikation verlagert Sicherheitsverantwortung auf Entwickler. Entdeckt die Risiken und wie man sie in Production abschwächt.
Die neue Model Context Protocol (MCP)-Spezifikation von Anthropic, die im Juni 2026 veröffentlicht wurde, verlagert die Sicherheitsverantwortung direkt auf die Entwickler. Früher übernahm das Protokoll diese. Jetzt seid ihr an der Reihe.
Diese Verschiebung ist nicht neu. Die Teams, die Claude mit MCP in Production einsetzen, Simple Booking im Hotelbereich, X mit seinen MCP-Servern für KI-Agenten, stellen sich bereits die Frage: Wo genau sind die Sicherheitslücken?
Die verantwortungsverlagerung: wo das problem liegt
Die neue MCP-Spezifikation ist zwar Enterprise-ready. Aber dieses Wort verbirgt eine Realität: Anthropic hat absichtlich einige Sicherheitskontrollen auf die Entwickler-Ebene verlagert, um mehr Flexibilität zu gewinnen.
Konkret bedeutet das drei Dinge:
1. Keine implizite Authentifizierung mehr
Früher enthielt MCP Sicherheitsmechanismen von Haus aus. Jetzt musst du die Authentifizierungskette selbst aufbauen. Eine E-Commerce-Agentur, die Claude mit Shopify verbindet und auf eine Kundendatenbank zugreift, muss verwalten, wie ein Claude-Agent auf sensible Daten, Namen, E-Mails, Telefonnummern, zugreift. Keine Magie hier.
2. Granulare Berechtigungen werden dein Problem
MCP sagt nicht mehr „dieses Tool kann lesen, aber nicht schreiben". Du sagst das. Ein Agent könnte potenziell eine Aktion ausführen, für die er nicht autorisiert ist, wenn du nicht die richtigen Regeln aufgebaut hast. Simple Booking kennt dieses Dilemma: Ihre MCP-Konnektoren integrieren ein CRS (Central Reservation System), das direkt Reservierungen beeinflusst. Eine falsch konfigurierte Berechtigung = eine versehentlich geänderte Reservierung.
3. Prompt-Injection wird kritischer
Claude ist intelligent, aber wenn ein MCP-Agent externe Anweisungen ohne Validierung akzeptiert, „rufe Tool X mit Parameter Y auf", hast du gerade einen Angriffsvektor für Angreifer geschaffen. Adversare versuchen nicht, das Protokoll zu hacken. Sie versuchen, deinen Agenten zu manipulieren.
Die vier konkreten fallstricke, auf die ihr stoßt
Fallstrick 1: credentials, die in umgebungsvariablen freigelegt werden
Das Klassische. Dein MCP-Server braucht einen API-Schlüssel, um mit einer Datenbank zu sprechen. Du packst ihn in .env. Soweit so gut. Nur: Wenn dein Docker-Container oder deine AWS-Lambda-Funktion abstürzen, werden diese Variablen in den Logs freigelegt.
Mit MCP wird jeder Verbindungsfehler zum Server an Claude gemeldet. Claude logged das. Und wenn Claude im Debug-Modus ist oder Logs nicht verschlüsselt sind, tschüss API-Schlüssel.
Entschärfung: Nutzt einen Secrets-Manager (Vault, AWS Secrets Manager). Injiziert die Credentials zur Laufzeit, nie hardcore.
Fallstrick 2: blinde vertrauensstellung gegenüber dem MCP-server
Du deployest einen MCP-Server, der 15 Tools bereitstellt. Claude ist verbunden. Ein Junior-Dev fügt ein neues Tool hinzu, das Kundendatensätze löscht. Ohne Zugriffskontrolle kann Claude es aufrufen.
Schlimmer: Wenn dieser Server in deinem internen Netzwerk läuft und jemand eine andere Maschine im Netzwerk kompromittiert, können sie zu MCP-Befehlen pivotieren.
Entschärfung: Jedes MCP-Tool muss eine explizite Liste haben, wer es aufrufen darf. Claude? Ja, aber nur wenn er X Kriterien erfüllt. Audit der Tools regelmäßig.
Fallstrick 3: unendliche timeouts, die blockieren
Ein MCP-Server antwortet langsam oder gar nicht. Claude wartet. Währenddessen stagniert eine Benutzeranfrage, die Session bleibt offen, der Speicher läuft über. Das ist nicht direkt eine Sicherheitslücke, aber es schafft DoS-Vektoren.
Noch schlimmer, wenn es absichtlich ist: Jemand sendet eine Anfrage, die MCP zu einer sehr langen Operation zwingt (Scan einer riesigen Datenbank, teure Berechnung).
Entschärfung: Striktes Timeout auf jedem MCP-Call. 5s, 10s maximal. Kein Unendlich.
Fallstrick 4: kein logging oder unzureichendes logging
Wenn Claude ein MCP-Tool aufruft und du nicht die Aktion, den Timestamp, die Parameter und das Ergebnis loggst, hast du keine Nachverfolgung. Ein Hotel, das 500 stornierte Reservierungen entdeckt, hat keine Spur, um nachzuverfolgen, was passiert ist.
Die schutzmechanismen, die ihr aufbauen müsst
1. Starke authentifizierung zwischen claude und deinem MCP-server
MCP verwendet JSON-RPC über stdio oder HTTP. Wenn es HTTP ist, nutzt HTTPS + einen gültigen Bearer-Token. Besser: mTLS mit Client-Zertifikaten.
Test: Dein MCP-Server muss jede Anfrage ohne gültige Authentifizierung ablehnen. Keine Ausnahmen.
2. Autorisierung nach rolle (rbac) oder attribut (abac)
Definiert explizit, wer welche Tools aufrufen darf.
| Agent-Rolle | Autorisierte Tools | Parameter begrenzt |
|---|---|---|
| ReadOnlyAnalyst | GetBookings, GetReviews | Keine sensiblen Parameter |
| ReservationManager | CreateBooking, ModifyBooking | Änderungen < 3 Tage vor Ankunft |
| Admin | Alle | Keine Limits |
Implementiert das in eurem MCP-Server. Vor der Ausführung eines Tools: Überprüft die Rolle von Claude (oder genauer: den Kontext der Session, die es nutzt).
3. Strenge validierung und bereinigung
Jeder Parameter, den MCP empfängt, muss validiert werden:
- Korrekter Typ (String, Zahl, etc.)
- Begrenzte Länge (nicht 10 MB Text in einem Feld)
- Format validiert (ein Datum ist wirklich ein Datum, eine E-Mail ist eine E-Mail)
- Keine Escape-Zeichen, die SQL-Injection ermöglichen könnten
// Beispiel: Endpoint, der eine Reservierung erstellt
// FALSCH
app.post('/MCP/create-booking', (req, res) -> {
const booking = req.body; // Direktes Risiko
db.insertBooking(booking);
});
// RICHTIG
app.post('/MCP/create-booking', (req, res) -> {
const schema = z.object({
clientId: z.string().uuid(),
checkIn: z.string().date(),
nights: z.number().min(1).max(365),
roomType: z.enum(['single', 'double', 'suite'])
});
const validated = schema.parse(req.body); // Wirft Fehler bei ungültig
db.insertBooking(validated);
});
4. Umfassendes logging mit kontext
Jeder MCP-Call muss gelogged werden mit:
- Genauer Timestamp
- Identität des Agenten (oder des Kontexts, der ihn nutzt)
- Aufgerufenes Tool + vollständige Parameter
- Ergebnis (Erfolg, Fehler, Exception)
- Ausführungsdauer
- Quell-IP-Adresse (falls relevant)
Speichert diese Logs in einem unveränderlichen System (CloudWatch, Splunk, oder eine einfache append-only verschlüsselte Datei).
5. Echtzeitüberwachung und alerts
Erkennt Anomalien:
- Zu viele Aufrufe eines Tools in kurzer Zeit -> DoS-Versuch
- Ein Tool mit ungewöhnlichen Parametern aufgerufen -> Fuzz-Attacke
- Wiederholte Fehler -> Aufklärungs- oder Vulnerability-Scanning
Konfiguriert einen Alert, wenn Claude „GetUserData" 100-mal in 30 Sekunden aufruft.
Das schulbeispiel: X und seine MCP-server
X (ehemals Twitter) hat MCP-Server gestartet, damit Claude, Cursor, Grok Build und andere KI-Tools direkt auf X zugreifen können. Die gleiche Logik wie Simple Booking und Hotelreservierungen.
Der Unterschied: Daten auf X sind standardmäßig öffentlich. Ein Agent kann Tweets abrufen, ohne Schaden zu verursachen. Aber wenn man einen X MCP-Server hätte, der private Nachrichten oder interne Analytics offenlegt, würde sich das Szenario komplett ändern.
Anthropic und X sind davon ausgegangen, dass Entwickler, die diese Server integrieren, Barriers setzen. Spoiler: Das ist nicht immer der Fall.
Häufig gestellte fragen
Sollte man die MCP-kommunikation auch auf localhost verschlüsseln?
Ja, wenn sensible Daten übertragen werden. Wenn es nur harmlose Berechnungen sind (Celsius in Fahrenheit konvertieren), nein. Aber sobald es um Kunden, Konten, Zahlungen geht: Verschlüsselt.
Was ist der unterschied zwischen MCP und einer klassischen REST-API aus sicherheitssicht?
Grundlegend: keiner. MCP ist nur eine JSON-RPC-Konvention. Die gleichen Sicherheitsprinzipien gelten. Der Unterschied ist, dass viele Devs denken, dass weil es „für KI" ist, es weniger kritisch ist. Fehler.
Wie teste ich die sicherheit meines MCP-servers?
Fuzzing: Zufällige Parameter senden, riesige Strings, Nulls, seltsame Zeichen. Tools wie Burp Suite verwenden, um MCP-Calls zu abfangen. SQL-Injection in jedem Parameter versuchen. Timeouts messen. Rolle-Bypasses suchen.
Gibt es eine zertifizierung oder einen standard für sicheres MCP?
Noch nicht. MCP ist zu jung. Anthropic veröffentlicht Empfehlungen, aber nichts Offizielles. Stattdessen wendet klassische API-Sicherheitsstandards an: OWASP Top 10, das funktioniert.
Wie gehe ich mit MCP um, wenn der claude-agent administratorrechte braucht?
Alptraum-Szenario: Du musst Claude die Möglichkeit geben, Daten zu löschen. Option 1: Ihm ein separates Tool „DeleteWithConfirmation" geben, das menschliche Genehmigung verlangt (du sagst dem System „genehmige den Agenten für diese Aktion"). Option 2: Granulare Tools mit sehr begrenzten Rollen. Option 3: Überhaupt nicht und nimm einen Menschen für destruktive Operationen.
Reicht die authentifizierung zwischen claude und MCP aus, oder muss ich auch claude -> anthropic sichern?
Beide. Du musst dem Kanal zwischen Claude und deinem Server vertrauen. Aber du musst auch Anthropic vertrauen, dass sie deine Daten nicht loggen/freilegen. Anthropic bietet Vertraulichkeitsgarantien für Enterprise-Pläne. Überprüft euren Vertrag.
Fazit
Die neue MCP-Spezifikation von Anthropic ist flexibler, aber standardmäßig weniger sicher. Sicherheit ist nicht mehr eingebaut. Sie hängt von dir ab.
Die drei Reflexe, die ihr haben solltet:
- Starke Authentifizierung zwischen Claude und MCP, HTTPS + Tokens, mTLS wenn möglich.
- Granulare Autorisierung, jedes Tool hat eine explizite Liste, wer es aufrufen darf und wie.
- Vollständige Observability, jeder Aufruf wird gelogged, ist auditierbar, kann alertet werden.
Wenn du MCP in Production deployest ohne diese drei Säulen, spielst du Roulette. Und spoiler: Die Kugel wird irgendwann in der Kammer sein.
Braucht ihr Hilfe, um eure MCP-Implementierung zu sichern? Sprechen wir über eure Architektur bei fstck.co, wir haben echte Fälle in Hotelbranche, E-Commerce und Fintech.
