MCP-Server prüfen, bevor Ihr KI-Agent seine Tools erhält

Behandeln Sie einen MCP-Server wie Code eines Drittanbieters, der mit Ihren Zugangsdaten handelt, und prüfen Sie ihn, bevor der Agent ihn aufrufen kann. Die folgenden Prüfungen stützen sich auf die MCP-Autorisierungsspezifikation (Revision 2025-06-18) und die MCP Security Best Practices (Revision 2025-11-25). Die Revisionen unterscheiden sich, prüfen Sie daher die aktuelle Spezifikation, bevor Sie sich auf eine Anforderung verlassen.

Autorisierung ist optional, prüfen Sie also, ob sie vorhanden ist

Server mit HTTP-Transport sollten der Autorisierungsspezifikation folgen. Server mit STDIO sollten das nicht tun und beziehen ihre Zugangsdaten stattdessen aus der Umgebung. Listen Sie bei einem lokalen STDIO-Server die Umgebungsvariablen auf, die Ihre Client-Konfiguration an den Prozess übergibt, und fragen Sie sich bei jeder, ob sie wirklich benötigt wird.

Senden Sie bei einem HTTP-Server eine nicht authentifizierte Anfrage:

curl -i https://mcp.example.com/mcp

Sie sollten ein 401 Unauthorized mit einem WWW-Authenticate-Header erhalten, der die URL der Resource-Metadaten nennt. Rufen Sie diese ab und prüfen Sie, dass das Dokument authorization_servers mit mindestens einem Eintrag enthält. Antwortet der Server stattdessen mit Daten, brechen Sie an dieser Stelle ab.

Bestätigen Sie anschließend die Punkte, die die Spezifikation als verpflichtend kennzeichnet:

• Der Client sendet bei jeder HTTP-Anfrage Authorization: Bearer <access-token>, und das Token erscheint nie im Query-String der URI.
• Endpunkte des Autorisierungsservers nutzen HTTPS, und Redirect-URIs sind localhost oder HTTPS.
• Der Autorisierungsserver gleicht Redirect-URIs exakt mit vorab registrierten Werten ab.
• Clients implementieren PKCE.

Clients sollten außerdem den Parameter state verifizieren, und Autorisierungsserver sollten kurzlebige Access Tokens ausstellen.

Token-Audience und Scope

Der Client muss den Parameter resource (RFC 8707) sowohl in der Autorisierungs- als auch in der Token-Anfrage senden, und der Server muss validieren, dass jedes Token gezielt für ihn ausgestellt wurde. Andernfalls funktionieren Tokens, die für andere Dienste ausgestellt wurden, auch gegen diesen Server.

Token Passthrough ist schlimmer: Der Server akzeptiert ein Token, das nicht für ihn ausgestellt wurde, und leitet es unverändert an nachgelagerte Systeme weiter. Kontrollen wie Rate Limiting und Monitoring können von der Token-Audience abhängen, und nachgelagerte Logs ordnen Anfragen unter Umständen der falschen Identität zu, was die Untersuchung erschwert.

Um die Audience-Bindung zu testen, fordern Sie mit einem registrierten Client ein Token für eine andere Ressource beim token_endpoint aus den Metadaten des Autorisierungsservers an. Spielen Sie es anschließend gegen den MCP-Server ab:

curl -i -H "Authorization: Bearer $OTHER_TOKEN" https://mcp.example.com/mcp

Erwartet wird 401. Ein gültiges Token ohne die nötigen Berechtigungen sollte 403 erhalten. Stellt der Autorisierungsserver ein solches Token nicht aus, fragen Sie den Anbieter, wie der MCP-Server die Audience prüft.

Fragen Sie außerdem, wo der Server Tokens speichert. Bei Public Clients müssen Refresh Tokens rotiert werden, und Tokens, die auf dem Server zwischengespeichert oder protokolliert werden, sind ein lohnendes Ziel für Diebstahl.

Proxy-Server und Consent

Wenn der MCP-Server eine Drittanbieter-API mit einer einzigen statischen Client-ID vorschaltet, lesen Sie den Abschnitt zum Confused Deputy in den Best Practices. Der Angriff setzt eine statische Client-ID, Dynamic Client Registration, ein Consent-Cookie des Autorisierungsservers des Drittanbieters und fehlenden Consent pro Client am Proxy voraus. Letzteres können Sie selbst beheben: Der Proxy sollte pro Benutzer ein Register genehmigter client_id-Werte führen und auf seiner eigenen Consent-Seite Client-Name, Scopes und Redirect-URI anzeigen. Diese Seite muss das Einbetten per iframe mit frame-ancestors oder X-Frame-Options: DENY unterbinden.

Tools per Allowlist freigeben und dann verkleinern

Lassen Sie sich vom Server die Liste seiner Tools geben und vergleichen Sie sie mit dem, was die Aufgabe erfordert. Alles darüber hinaus ist Excessive Functionality im Sinne von OWASP LLM06:2025. Entfernen Sie es oder verhindern Sie, dass der Agent es aufruft.

Speichern Sie die Liste als Baseline und bilden Sie nach jedem Server-Update die Differenz, damit ein per Update hinzugekommenes Tool geprüft wird, bevor der Agent es aufrufen kann. Prüfen Sie dann jedes verbleibende Tool:

• Ist es offen formuliert, etwa "Shell-Befehl ausführen" oder "URL abrufen"? Ersetzen Sie es durch ein enger gefasstes Tool. OWASPs Beispiel ist ein Tool zum Schreiben von Dateien statt Shell-Zugriff.
• Welche Identität nutzt es nachgelagert? Ein Tool, das Daten liest, sollte nur mit SELECT verbinden, nicht mit UPDATE, INSERT und DELETE.
• Handelt es für einen einzelnen Benutzer? Dann sollte es sich per OAuth mit minimalem Scope authentifizieren und nicht über ein generisches privilegiertes Konto.

Setzen Sie die Grenzen im nachgelagerten System durch. OWASP nennt das Complete Mediation: Verlassen Sie sich nicht darauf, dass das Modell entscheidet, ob eine Aktion erlaubt ist.

Menschliche Freigabe für schreibende Aktionen

Halluzinationen und Prompt Injection sind häufige Auslöser schädlicher Aktionen, deshalb braucht jede folgenreiche Aktion einen Menschen in der Entscheidungsschleife. OWASP beschreibt einen Mail-Assistenten, der eingehende Nachrichten zusammenfasst. Eine eingeschleuste E-Mail verleitet ihn dazu, das Postfach nach sensiblen Informationen zu durchsuchen und sie an den Angreifer weiterzuleiten.

Eine schreibgeschützte Extension, ein schreibgeschützter OAuth-Scope oder die manuelle Prüfung jeder vorbereiteten Mail vor dem Versand hätten diesen Angriff jeweils unterbunden. Kombinieren Sie diese Maßnahmen, wo immer möglich.

Alles, was löscht, sendet oder veröffentlicht, gehört auf die Freigabeliste. Legen Sie die Freigabe in die Extension oder in das nachgelagerte System. Logging und Rate Limiting verhindern Excessive Agency nicht, erleichtern aber das Erkennen unerwünschter Aktionen.

Wenn der Client serverseitig läuft

Während der OAuth-Discovery ruft der Client URLs ab, die der Server liefert, darunter resource_metadata, authorization_servers und token_endpoint. Ein bösartiger Server kann diese auf interne Adressen oder den Cloud-Metadaten-Endpunkt unter 169.254.169.254 zeigen lassen.

Verlangen Sie in der Produktion HTTPS, blockieren Sie private und reservierte Adressbereiche und validieren Sie Redirect-Ziele oder deaktivieren Sie automatische Redirects. Schreiben Sie keine IP-Validierung von Hand, denn Tricks mit Oktal- und Hexadezimaldarstellungen sowie IPv4-mapped IPv6 überlisten selbst geschriebene Parser. Erwägen Sie einen Egress-Proxy wie Smokescreen.

Testen Sie das anschließend. Setzen Sie einen feindlichen Testserver auf, der ein 401 zurückgibt, dessen WWW-Authenticate-Header eine resource_metadata-URL mit Ziel http://169.254.169.254/ enthält, und wiederholen Sie den Test mit einer URL, die auf eine interne Adresse umleitet. Der Client sollte beides ablehnen, und ein Listener auf dem internen Ziel sollte keine Anfrage sehen.

Womit Sie beginnen

1. Listen Sie jeden MCP-Server auf, den Ihre Agenten nutzen, mit Transport und Betreiber. Entfernen Sie jeden, den Sie nicht zuordnen können.
2. Führen Sie curl -i gegen jeden HTTP-Server aus und bestätigen Sie das 401 mit einem WWW-Authenticate-Header. Spielen Sie dann ein für eine andere Ressource ausgestelltes Token ab.
3. Prüfen Sie bei Proxy-Servern mit statischer Client-ID den Consent-Ablauf: Register pro Client, Inhalt der Consent-Seite, Schutz vor Framing.
4. Legen Sie für jeden Server eine Baseline der Tool-Liste an, kürzen Sie sie auf das, was die Aufgabe erfordert, geben Sie jedem Tool die am wenigsten privilegierte Identität und verlangen Sie menschliche Freigabe für Tools, die schreiben oder löschen.
5. Führen Sie bei serverseitigen Clients den SSRF-Test mit einem feindlichen Testserver durch.
6. Wiederholen Sie die Schritte 2 bis 5, sobald ein Server ein Update erhält, ein Tool hinzufügt oder seine Scopes ändert.

Für eine externe Prüfung siehe unsere Beratung. Unsere Penetrationstests können die Token- und Consent-Prüfungen gegen Ihr Setup durchführen.