MCP absichern: was das Model Context Protocol öffnet

Was MCP ändert

Bereits falsche oder vertrauliche Textausgaben können Schaden verursachen. Mit Werkzeugzugriff kommen direkte Aktionen in angeschlossenen Systemen hinzu. MCP ist das Protokoll, über das ein Assistent Werkzeuge und Datenquellen angeboten bekommt: Dateien lesen, ein Ticket anlegen, eine Abfrage ausführen.

Damit verschieben sich zwei Dinge. Erstens gibt es eine Vertrauensgrenze zwischen Client und Server, die authentifiziert und autorisiert werden muss. Zweitens kann Text, den das Modell irgendwo liest, zu einer Aktion führen. Beide Punkte sind aus der klassischen Anwendungssicherheit bekannt, tauchen hier aber in neuer Verpackung auf.

Die Spezifikation trägt dem Rechnung: Es gibt ein eigenes Dokument mit Sicherheitshinweisen, das ausdrücklich neben der Autorisierungsspezifikation und den OAuth-Sicherheitsempfehlungen aus RFC 9700 zu lesen ist.

Confused Deputy: die Zustimmung, die übersprungen wird

Der erste beschriebene Angriff betrifft MCP-Server, die als Proxy vor einer Fremd-API sitzen. Der Server benutzt gegenüber dem fremden Autorisierungsserver eine feste Client-ID, erlaubt seinen eigenen Clients aber eine dynamische Registrierung.

Nach der ersten regulären Anmeldung setzt der fremde Autorisierungsserver ein Zustimmungs-Cookie für diese feste Client-ID. Ein Angreifer registriert nun einen eigenen Client mit einer redirect_uri, die ihm gehört, und schickt dem Nutzer einen präparierten Link. Weil das Cookie noch da ist, überspringt der Autorisierungsserver den Zustimmungsdialog. Der Autorisierungscode landet beim Angreifer.

Die Spezifikation formuliert die Gegenmaßnahme als Pflicht: MCP-Proxy-Server müssen eine Zustimmung je Client einholen, bevor sie an den fremden Autorisierungsserver weiterleiten. Dazu gehört ein Register der freigegebenen Client-IDs je Nutzer, eine eigene Zustimmungsseite mit CSRF- und Klickjacking-Schutz und eine exakte, nicht musterbasierte Prüfung der redirect_uri. Ein Detail entscheidet über Erfolg oder Misserfolg: Die Sitzung mit dem state-Wert darf erst nach der Zustimmung gesetzt werden. Wer sie vorher setzt, macht die Zustimmungsseite wirkungslos.

Token Passthrough: fremde Token gehören abgelehnt

Die Spezifikation bezeichnet es als Anti-Muster, wenn ein MCP-Server Token vom Client entgegennimmt, ohne zu prüfen, ob sie für ihn ausgestellt wurden, und sie an die nachgelagerte API durchreicht. Die Regel ist eindeutig: MCP-Server dürfen keine Token akzeptieren, die nicht ausdrücklich für sie ausgestellt wurden.

Die Begründung ist praktisch. Durchsatzbegrenzung, Anfragevalidierung und Überwachung hängen an der Zielgruppe des Tokens. Wer sie umgeht, umgeht die Kontrollen. Dazu kommt die Protokollierung: Der nachgelagerte Dienst sieht dann Anfragen, die scheinbar von einer anderen Identität kommen als vom Server, der sie tatsächlich weiterleitet. Nach einem Vorfall ist das der Unterschied zwischen einer Rekonstruktion und einer Vermutung.

Prompt Injection trifft auf Werkzeuge

MCP löst Prompt Injection nicht, es erhöht den Einsatz. Die OWASP Top 10 for LLM Applications 2025 führt Prompt Injection als LLM01 an erster Stelle. Relevant sind hier zusätzlich LLM06 Excessive Agency, also zu weit gefasste Handlungsbefugnisse eines Modells, und LLM05 Improper Output Handling, also die ungeprüfte Weiterverarbeitung von Modellausgaben.

Kritisch ist die Kombination aus nicht vertrauenswürdigem Inhalt und weitreichenden Werkzeugrechten. Folgt ein Modell einer eingeschleusten Anweisung aus einem Ticket, kann es damit seine erlaubten Werkzeuge für eine unerwünschte Aktion einsetzen.

Ein Beispiel. Ein Team verbindet seinen Assistenten mit dem Ticketsystem und erlaubt ihm, Änderungen im Repository vorzuschlagen. Dann legt jemand von außen ein Ticket an, das den Assistenten auffordert, eine Sicherheitsprüfung im Code zu entfernen. Der Assistent kann die eingeschleuste Anweisung mit dem eigentlichen Auftrag verwechseln. Kleine Berechtigungen, eine isolierte Arbeitsumgebung und eine menschliche Prüfung vor dem Übernehmen der Änderung begrenzen die Folgen. Ein Systemprompt allein ersetzt diese Kontrollen nicht.

Berechtigungen klein halten, Freigaben einzeln erteilen

Die Spezifikation widmet der Berechtigungsgestaltung einen eigenen Abschnitt. Ein Token mit weit gefassten Berechtigungen wie files:* oder admin:* vergrößert den Schaden bei Diebstahl, erschwert den Entzug und macht die Protokolle unbrauchbar, weil aus einer Sammelberechtigung nicht mehr hervorgeht, was der Nutzer eigentlich wollte.

Empfohlen wird ein abgestuftes Modell: ein minimaler Satz zu Beginn, der nur risikoarme Lese- und Erkundungsoperationen abdeckt, und eine gezielte Erhöhung über eine WWW-Authenticate-Aufforderung, sobald eine privilegierte Operation zum ersten Mal versucht wird. Als häufige Fehler nennt die Spezifikation ausdrücklich: Sammelberechtigungen wie * oder full-access, das Bündeln unverwandter Rechte und die Annahme, die im Token behaupteten Berechtigungen ersetzten die serverseitige Autorisierung.

Lokal oder remote: zwei Risikoprofile

Geschützte HTTP-MCP-Server prüfen die Autorisierung bei jeder Anfrage und akzeptieren nur für sie bestimmte Tokens. Seit der Protokollversion 2026-07-28 gibt es keine Protokollsitzungen mehr. Zustandsreferenzen der Anwendung, etwa Workflow-IDs, müssen weiterhin gegen Übernahme geschützt und an die berechtigte Person gebunden werden. Sie ersetzen keine Authentifizierung. Prüfen Sie die tatsächlich genutzte Protokollversion: Ältere Implementierungen können noch Sitzungen verwenden [1, 2].

Lokale Server sind etwas anderes: Programme, die auf dem Rechner der Nutzerin laufen und dort direkten Systemzugriff haben können. Die Spezifikation nennt drei Angriffswege: ein bösartiger Startbefehl in der Client-Konfiguration, eine bösartige Nutzlast im Server selbst und der Zugriff auf einen ungesichert auf localhost laufenden Server. Unterstützt ein Client die Ein-Klick-Konfiguration lokaler Server, muss er vorher eine Zustimmung einholen, die den vollständigen, ungekürzten Befehl anzeigt und eine ausdrückliche Freigabe verlangt.

Für Unternehmen ist das die praktisch wichtigste Passage des ganzen Dokuments. Ein MCP-Server aus einem Paketregister ist ausführbarer Code mit den Rechten des angemeldeten Nutzers. Er gehört in denselben Freigabeprozess wie jede andere Software, und er gehört in eine Sandbox mit eingeschränktem Datei- und Netzwerkzugriff.

Checkliste für den Betrieb

• Jeder MCP-Server hat einen benannten Verantwortlichen und einen Freigabestand.
• Lokale Server laufen in einer Sandbox mit eingeschränktem Datei- und Netzwerkzugriff.
• Der Server lehnt Token ab, die nicht für ihn ausgestellt wurden.
• Zustimmung wird je Client eingeholt, redirect_uri exakt geprüft, state einmalig und kurzlebig.
• Zustandsreferenzen sind gegen Übernahme geschützt; Authentifizierung und Berechtigungen werden bei jeder Anfrage geprüft.
• Schreibende Werkzeuge sind einzeln freigegeben, nicht als Gruppe.
• Werkzeugaufrufe werden mit Identität, Aktion, Zeitpunkt und Ergebnis nachvollziehbar protokolliert. Parameter werden nur soweit nötig erfasst; Zugangsdaten und sensible Inhalte werden ausgelassen oder maskiert [5].

Was Sie danach entscheiden können

• Welche MCP-Server in Ihrem Haus laufen dürfen, wer sie freigibt und wer sie verantwortet.
• Welche Werkzeuge ein Assistent lesend bekommt, welche schreibend, und welche Aktionen eine menschliche Bestätigung brauchen.
• Wie Token, Zustimmungen und Protokolle aussehen müssen, bevor ein Server produktiv geht.

Häufige Fragen

Quellen

1. MCP Specification: Security Best Practices Model Context Protocol, Spezifikation 2026-07-28
2. MCP Specification: Authorization Model Context Protocol, Spezifikation 2026-07-28
3. OWASP Top 10 for LLM Applications 2025 OWASP GenAI Security Project
4. RFC 9700: Best Current Practice for OAuth 2.0 Security IETF, Januar 2025
5. Logging Cheat Sheet OWASP Cheat Sheet Series