Die neue MCP-Spezifikation verlagert Sicherheit auf Entwickler. Konkrete Checkliste zur Sicherung deines MCP-Servers ohne deine KI-Agenten zu bremsen.
Die neue Spezifikation des Model Context Protocol, veröffentlicht Ende Juni 2026, verlagert einen kritischen Teil der Sicherheitsverantwortung des Protokolls auf die Entwickler, die es implementieren. Konkret: Wenn dein MCP-Server ein sensibles Tool ohne strikte OAuth-Token-Validierung verfügbar macht, kommt der Fehler aus deinem Code, nicht aus dem von Anthropic entwickelten Protokoll.
Das ist ein Paradigmenwechsel, keine einfache Patch. Bisher war MCP relativ permissiv, was die Authentifizierungsverwaltung auf den Servern betraf. Die neue enterprise-ready Version, dokumentiert von SecurityWeek Ende Juni, schließt diesen Spielraum und zwingt Teams, ihre Implementierungen selbst zu härten. Wir hatten das bereits erwähnt in Agentic Commerce auf Shopify: MCP wird zur Standard-Schnittstelle zwischen KI-Agenten und Business-Systemen. Das Problem: Einen Agenten an dein CRM oder deine Bestelldatenbank anzuhängen, ohne sie abzusichern, öffnet eine Tür, die niemand überwacht.
Was sich in der MCP-spezifikation von juni 2026 geändert hat
Das MCP-Protokoll funktioniert als einheitliche Schnittstelle: Ein KI-Agent, Claude, Cursor oder jeder andere kompatible Client, verbindet sich, um externe Tools aufzurufen, ohne spezifischen Code pro Integration. X (das ehemalige Twitter) startete Ende Juni seinen eigenen MCP-Server, um Agenten wie Claude oder Grok Build direkten Zugriff auf seine Plattform zu geben, laut TechCrunch. HiBob tat dasselbe wenige Tage später mit einer MCP-Integration, die Slack mit seinem HRIS verbindet.
Diese schnelle Adoption hat eine Kehrseite. Je mehr MCP-Server öffentlich exponiert sind, desto größer wird die Angriffsfläche. Die neue Spezifikation beantwortet das, indem sie formalisierte Anforderungen an OAuth-Token- und Scope-Verwaltung einführt. Aber sie erzwingt sie nicht technisch, sie dokumentiert, was ein „enterprise-ready"-Server tun muss. Es bleibt jedem Entwickler überlassen, das umzusetzen oder zu ignorieren.
Hier liegt der kontraintuitive Punkt: Eine auf dem Papier sicherere Spezifikation kann das Ökosystem kurzfristig weniger sicher machen, weil sie den Eindruck erweckt, dass das Protokoll das Problem bereits löst. Das tut es nicht. Es dokumentiert das Problem und reicht dir die Kartoffel weiter.
Die fehler, die wir bereits bei MCP-deployments sehen
Tool poisoning: wenn ein server lügt, was er tut
Ein MCP-Server erklärt seine Tools über ein Manifest in natürlicher Sprache, eine Beschreibung, die der Agent liest, um zu entscheiden, wann er es aufrufen soll. Nichts hindert einen böswilligen oder kompromittierten Server daran, ein Tool als „schreibgeschützt" zu deklarieren, das in Wirklichkeit in deine Datenbank schreibt. Der Agent vertraut der Beschreibung, nicht dem realen Code. Das ist der am besten dokumentierte Angriffsvektor in der MCP-Sicherheitscommunity seit Anfang 2026.
Falsch konfiguriertes OAuth, der angriff nummer eins
Die meisten Vorfälle entstehen durch eine klassische Verwechslung: Zu breite Scopes, Tokens, die nie ablaufen, oder schlimmer noch, zwischen mehreren Agenten auf dem gleichen Server geteilte Tokens. Ein kompromittierter MCP-Token gibt Zugriff auf alles, was der Scope autorisiert, nicht nur auf die aktuelle Anfrage.
Fehlende sandboxing zwischen agent und dateisystem
Viele MCP-Server laufen noch lokal mit quasi vollständigem Disk-Zugriff, um die Entwicklung zu vereinfachen. Das funktioniert großartig, bis der Agent einen bösen Prompt erhält, der über ein externes Dokument injiziert wird, und einen Shell-Befehl ausführt, zu dem er nie Zugriff hätte haben sollen.
Wie man einen MCP-server in der produktion absichert
Das empfehlen wir konkret, nach Priorität geordnet:
- Granulare OAuth-Scopes, ein Scope pro Tool, niemals einen globalen „Admin"-Scope.
- Kurze Token-Ablaufzeiten, 15 bis 60 Minuten, mit expliziter Aktualisierung statt Tokens, die Wochen lang gültig bleiben.
- Validierung des Tool-Manifests bei jedem Aufruf, nicht nur beim initialen Handshake.
- Systematisches Sandboxing, isolierter Container, schreibgeschütztes Dateisystem außer für dedizierte Verzeichnisse.
- Audit-Logs pro Tool-Aufruf, mit Alerting bei ungewöhnlichen Mustern (Häufigkeit, Zeiten, unerwartete Scopes).
- Rate Limiting auf der MCP-Seite, unabhängig von der Rate Limiting der zugrunde liegenden API.
Diese Liste hat nichts Revolutionäres. Es ist im Wesentlichen klassische API-Hygiene, angewendet auf ein Protokoll, das jünger ist als die meisten REST-Standards. Der Unterschied ist, dass noch niemand automatische Reflexe hat, weil MCP kaum über ein Jahr öffentliche Existenz hat.
Eine ehrliche Einschränkung: Diese Maßnahmen verlangsamen die Entwicklung. Ein Scope pro Tool bedeutet mehr Konfiguration bei jedem neuen Tool. Wenn dein Team schnell entwickelt und auf einem MVP iteriert, das intern und nicht öffentlich exponiert ist, kann dieser Grad an Rigor unverhältnismäßig sein. Reservier ihn für Server, die für Dritte exponiert oder mit sensiblen Daten umgehen.
MCP vs. klassische REST-API: sicherheit im vergleich
| Kriterium | Klassische REST-API | MCP-Server |
|---|---|---|
| Authentifizierung | OAuth 2.0 / API-Keys, reifer Standard | OAuth in die Spezifikation integriert, aber variable Implementierung |
| Fähigkeitserkennung | Statische Dokumentation (OpenAPI) | Dynamisches Manifest vom Agent zur Laufzeit gelesen |
| Angriffsfläche | Bekannte, feste Endpoints | Dynamisch deklarierte Tools, schwerer zu auditieren |
| Zugriffskontrolle | Etablierte Rollen und Berechtigungen | Scopes noch in der Praxis nicht granular genug |
| Ökosystem-Reife | 15+ Jahre bewährte Muster | Knapp zwei Jahre, Best Practices noch im Fluss |
Die Tabelle spricht für sich: MCP ist nicht weniger sicherbar als eine REST-API, aber das Ökosystem aus Tools, Scannern und Best Practices hat seinen Rückstand noch nicht aufgeholt. Das wird kommen. Bis dahin ist es deine Aufgabe, das auszugleichen.
Was die großen player bereits tun
Anthropic hat sein Modell Ende Juni 2026 zu Claude Sonnet 5 weiterentwickelt, das Sonnet 4.6 ablöst, das im Februar veröffentlicht wurde, laut 9to5Mac. Ein leistungsfähigeres Modell bedeutet mechanisch mehr Risiken im Agentenbereich: Je autonomer der Agent entscheidet, desto mehr Konsequenzen hat ein MCP-Fehler vorgelagert. X hat sich entschieden, einen öffentlichen MCP-Server verfügbar zu machen, damit Agenten wie Claude oder Cursor Build direkt mit seiner Plattform interagieren können, eine Wahl, die bei dieser Größenordnung besonders strikte Token-Governance erfordert. HiBob hingegen hat sich für eine geschlossenere Integration entschieden, indem es sein HRIS via MCP an Slack angebunden hat, statt einen offenen Server für beliebige Clients freizugeben.
Zwei Philosophien, zwei Risikostufen. Wenn dein Shopify-Shop oder dein internes SaaS einen MCP-Server exponieren erwägt, ist die erste Frage: Braucht du wirklich offenen Zugriff, oder reicht Zugriff auf deine eigenen Agenten?
Fazit
Drei Punkte zum Merken. Erstens: Die neue MCP-Spezifikation sichert deine Deployments nicht automatisch, sie dokumentiert Anforderungen, die du selbst implementieren musst. Zweitens: Die häufigsten Fehler bleiben Klassiker: Zu breite Scopes, Tokens, die nicht ablaufen, fehlender Sandbox. Drittens: Rigor kostet Geschwindigkeit, reservier sie für wirklich exponierte Server.
Wenn du bereits einen KI-Agenten exponierst, der über MCP mit deinem Stack verbunden ist, oder noch zwischen No-Code und Custom-Implementierung zögerst, haben wir die Abwägungen detailliert in No-Code vs. Code für KI-Agenten beschrieben. Brauchst du ein Sicherheits-Audit an deinem MCP-Server vor dem Produktionsgang? Kontaktier uns auf fstck.co.
Häufig gestellte fragen
Wie weiß ich, ob mein MCP-server anfällig für tool poisoning ist?
Verifiziere, dass das von jedem Tool deklarierte Manifest genau seinem realen Verhalten in der Produktion entspricht, nicht nur der Dokumentation. Ein einfaches Audit: Protokolliere jeden Tool-Aufruf und vergleiche die tatsächliche Aktion (Schreib-, Lesezugriff, externer Aufruf) mit der Beschreibung im Manifest.
Sollte ich warten, bis MCP reift, bevor ich es in der produktion einsetze?
Nein, aber du musst den Rigurlevel an die tatsächliche Exposition des Servers anpassen. Ein interner MCP-Server, zugänglich nur von deinen eigenen Agenten in einem privaten Netzwerk, verträgt weniger Anforderungen als ein Server, der öffentlich für Third-Party-Clients exponiert ist.
Was ist der unterschied zwischen OAuth-scopes einer REST-API und denen eines MCP-servers?
Das Prinzip ist gleich, Zugriff auf das Nötigste begrenzen, aber die MCP-Spezifikation ermutigt einen Scope pro Tool statt pro Ressource. In der Praxis bleiben viele aktuelle Implementierungen zu permissiv, weil Tools zum Verwalten dieser Granularität noch nicht ausgereift sind.
Gibt ein kompromittierter MCP-token zugriff auf alle tools des servers?
Das hängt vollständig von der Scope-Konfiguration ab. Hat der Token einen globalen Scope, ja, der Angreifer erhält Zugriff auf alles, das dieser Scope autorisiert. Deshalb ist Scope-Granularität kein optionales Detail, sondern die erste Abwehrlinie.
Ist MCP risikoreicher als klassische API-integration?
Nicht grundsätzlich risikoreicher, aber weniger ausgereift, was Audit-Tools und standardisierte Best Practices angeht. Die dynamische Fähigkeitserkennung, die MCPs Stärke ist, erschwert auch die statische Sicherheitsanalyse, die man leicht bei einer in OpenAPI dokumentierten REST-API durchführt.
