Zum Inhalt springen
Illustration: Illustration: Ein kleiner Server ist per Kabel an ein KI-Modul angeschlossen; dazwischen ein Prüftor mit Scannerrahmen, am Kabel ein Vorhängeschloss, daneben ein schmaler Token-Schlüssel.
KI

MCP-Server sicher einsetzen: Rechte, Tokens, Prüfliste

Von · · 8 Min. Lesezeit

Ein MCP-Server ist ein Programm, das einem KI-Client Werkzeuge zur Verfügung stellt: Dateien lesen, eine Datenbank abfragen, ein Ticket anlegen, Suchdaten holen. Das Model Context Protocol regelt nur, wie Client und Server miteinander sprechen. Lokal startet der Client den Server als eigenen Prozess und spricht über stdio mit ihm, entfernt läuft die Verbindung über HTTP und wird per OAuth abgesichert. Mit claude mcp add ist so ein Server in Claude Code in zehn Sekunden eingebunden. Genau darin liegt das Problem.

Ein MCP-Server ist keine Schnittstelle, sondern ausführbarer Code mit Zugriff. Der lokale Server läuft mit den Rechten des Programms, das ihn startet, also mit deinen: Er kann ~/.ssh/ lesen, Netzwerkverbindungen öffnen und Dateien löschen. Der entfernte Server bekommt ein Token und handelt damit in deinem Namen. Und beide liefern Text, den das Modell liest und befolgen kann.

Was ein Agent mit den Rechten anstellt, die er bekommt, steht in KI-Agenten: Sicherheit und Risiken im Betrieb. Hier geht es um die Stelle davor: um den Server, der ihm diese Rechte überhaupt erst gibt.

Was die Spezifikation selbst als Angriff beschreibt#

Das MCP-Projekt führt eine eigene Seite Security Best Practices, ergänzend zur Autorisierungs-Spezifikation. Für Betreiber einer Website oder einer kleinen Entwicklung sind fünf Punkte daraus relevant.

Kompromittierter lokaler Server. Ein lokaler Server ist ein heruntergeladenes Programm. Die Spezifikation nennt drei Wege: ein schädlicher Startbefehl in der Konfiguration, Schadcode im Server selbst und ein lokal offener Server, der per DNS-Rebinding aus dem Browser angesprochen wird. Ihr Beispiel ist ein Startbefehl, der erst ein Paket mit npx installiert und dann den privaten SSH-Schlüssel per curl nach außen schickt. Clients mit Ein-Klick-Einrichtung müssen deshalb den vollständigen Befehl ungekürzt anzeigen und eine ausdrückliche Freigabe verlangen. Die Spezifikation empfiehlt zusätzlich, Server in einer Sandbox mit minimalen Rechten zu starten.

Token-Weitergabe. Ein Server, der ein Token annimmt, das gar nicht für ihn ausgestellt wurde, und es unverändert an eine fremde API weiterreicht, umgeht deren Rate-Limits und Protokolle. Im Log der API steht dann die falsche Identität. Die Spezifikation verbietet das ausdrücklich: Ein Server „MUST NOT accept any tokens that were not explicitly issued for the MCP server“.

Confused Deputy. Ein MCP-Server, der als Vermittler zu einer fremden API arbeitet und dort mit einer festen Client-ID auftritt, kann zur Hintertür werden. Der Ablauf: Du hast der fremden API einmal zugestimmt, der Browser merkt sich das per Cookie. Ein Angreifer registriert sich beim Vermittler mit eigener Rücksprungadresse und schickt dir einen Link. Dein Klick überspringt die Zustimmung, und der Autorisierungscode landet bei ihm. Gegenmittel ist eine eigene Zustimmung je Client auf der Seite des MCP-Servers. Das musst du nicht selbst bauen, aber du solltest bei einem gehosteten Server wissen, ob der Anbieter es tut.

Zu breite Scopes. Ein Token mit files:* oder admin:* ist nach einem Diebstahl ein Generalschlüssel. Die Spezifikation empfiehlt, mit einem minimalen Satz an Leserechten zu beginnen und Schreibrechte erst anzufordern, wenn eine Aktion sie verlangt. Als häufigsten Fehler nennt sie Sammel-Scopes wie *, all oder full-access.

Übernommene Zustandskennungen. Seit der Fassung vom 28. Juli 2026 hat MCP keine Sitzungen auf Protokollebene mehr. Ein Server, der sich etwas über mehrere Aufrufe merkt, vergibt dafür eine Kennung, etwa für einen Warenkorb. Wer diese Kennung errät oder abgreift, arbeitet im Zustand eines anderen Nutzers, wenn der Server sie nicht an den angemeldeten Nutzer bindet. Der Besitz einer Kennung ist keine Anmeldung, schreibt die Spezifikation.

Was in der Werkzeugbeschreibung steht#

Jeder Server liefert zu jedem Werkzeug eine Beschreibung in natürlicher Sprache. Das Modell liest sie, um zu entscheiden, wann es das Werkzeug benutzt. Der Nutzer sieht sie meist nicht.

Invariant Labs hat am 1. April 2025 gezeigt, was daraus folgt (Tool Poisoning Attacks): Ein Werkzeug namens add, das zwei Zahlen addieren soll, trägt in seiner Beschreibung eine versteckte Anweisung, vorher ~/.cursor/mcp.json und ~/.ssh/id_rsa zu lesen und den Inhalt in einem unauffälligen Parameter mitzuschicken. Dem Nutzer wird eine Rechenerklärung angezeigt. Dasselbe Muster wirkt über Servergrenzen hinweg: Ein bösartiger Server kann mit seiner Beschreibung beeinflussen, wie das Modell das Mail-Werkzeug eines anderen, vertrauenswürdigen Servers benutzt.

Es ist Prompt Injection, nur dass die Anweisung nicht in einer Webseite oder einer Mail steckt, sondern in der Werkzeugliste selbst. Die Spezifikation trägt dem Rechnung: Clients müssen Annotationen zu Werkzeugen als nicht vertrauenswürdig behandeln, solange sie nicht von einem vertrauenswürdigen Server stammen (MCP-Spezifikation, Tools).

Nach der Freigabe ist nicht vor der Freigabe. Ein Server kann seine Werkzeugbeschreibungen jederzeit ändern. Invariant Labs nennt das „Rug Pull“: Du prüfst den Server, gibst ihn frei, und beim nächsten Start liefert er eine andere Beschreibung. Dass das kein Gedankenspiel ist, zeigt CVE-2025-54136 im Code-Editor Cursor, veröffentlicht am 1. August 2025: Wer Schreibzugriff auf ein Repository mit MCP-Konfiguration hatte, konnte einen bereits freigegebenen Server so ändern, dass er beliebige Befehle ausführte, ohne dass erneut gefragt wurde. Behoben ab Version 1.3. Seitdem fragt Cursor bei jeder Änderung eines Eintrags neu.

Illustration: Illustration: Zwei fast gleiche Steckkarten an einem Server; hinter der rechten liegt eine zweite, versetzte Lage.

Was Claude Code beim Einbinden tut#

Claude Code kennt drei Geltungsbereiche für MCP-Server (Claude Code, MCP). local ist die Voreinstellung und gilt nur für dich im aktuellen Projekt, user für alle deine Projekte. Beide stehen in ~/.claude.json. project steht in .mcp.json im Projektverzeichnis und wird mit dem Repository geteilt.

Der dritte Bereich ist der heikle. In einer interaktiven Sitzung fragt Claude Code nach, bevor es einen Server aus einer .mcp.json benutzt. In claude -p-Läufen, Agent-SDK-Sitzungen und Cloud-Sitzungen lädt es diese Server ohne Rückfrage. Wer Claude Code in einem Skript oder einer CI-Pipeline auf einem fremden Repository laufen lässt, startet damit, was in dessen .mcp.json steht. Getroffene Freigaben setzt claude mcp reset-project-choices zurück.

Zwei Schutzmechanismen sind eingebaut: In url und headers eines entfernten Servers liest Claude Code bestimmte Zugangsvariablen wie ANTHROPIC_API_KEY oder NPM_TOKEN als leer, damit ein Projekt sie nicht an einen fremden Server schicken kann. Und Organisationen können mit allowedMcpServers und deniedMcpServers festlegen, welche Server überhaupt zulässig sind. Die Dokumentation selbst warnt: Prüf jeden Server, bevor du ihn verbindest, und Server, die externe Inhalte holen, öffnen den Weg für Prompt Injection.

Prüfliste vor dem Einbinden#

  1. Herkunft klären. Wer veröffentlicht den Server? Der Hersteller des Dienstes selbst, ein bekanntes Projekt, ein Einzelner ohne Historie? Bei lokalen Servern den Quellcode wenigstens überfliegen: Was steht in der Werkzeugliste, welche Netzwerkziele kommen vor?
  2. Version festschreiben. npx -y paket holt bei jedem Start die neueste Fassung. npx -y paket@1.4.2 holt immer dieselbe. Ein Update ist dann eine Entscheidung und kein Zufall.
  3. Werkzeugbeschreibungen lesen. Einmal beim Einbinden und nach jedem Update. Steht dort mehr als eine Beschreibung der Funktion, etwa Anweisungen an das Modell oder Verweise auf andere Werkzeuge, fliegt der Server raus.
  4. Ein eigenes Token je Server. Kein persönliches Admin-Token, kein Schlüssel, den drei Server teilen. Wird ein Server kompromittiert, sperrst du genau einen Zugang.
  5. Minimalen Umfang vergeben. Ein Analyse-Server braucht Leserechte auf die Search Console, keine Rechte zum Verwalten von Nutzern. Wo der Dienst es anbietet: Token auf ein Projekt, ein Repository, eine Property beschränken.
  6. Mit Lesezugriff anfangen. Zwei Wochen nur lesen lassen, dann entscheiden, welche Schreibrechte tatsächlich fehlen.
  7. Bestätigung vor dem Schreiben. Werkzeuge, die senden, veröffentlichen oder löschen, nicht dauerhaft freigeben. Die Spezifikation empfiehlt für sensible Aufrufe eine Rückfrage und die Anzeige der Eingaben vor dem Aufruf.
  8. Lokale Server einsperren. Ein Container ohne Zugriff auf das Home-Verzeichnis und mit beschränktem Netzwerk nimmt einem schädlichen Server den größten Teil seiner Möglichkeiten.
  9. Geheimnisse aus dem Repository heraushalten. In .mcp.json gehört ${API_KEY}, nicht der Schlüssel selbst. Der Wert kommt aus der Umgebung oder dem Schlüsselbund des Betriebssystems.
  10. Durchsehen, was angebunden ist. claude mcp list einmal im Monat. Server, die niemand mehr benutzt, entfernen und ihre Tokens beim Dienst widerrufen.

Was nicht hilft#

Beliebtheit im Verzeichnis. Sterne, Downloads und ein Platz weit oben in einer Serverliste sagen nichts darüber, was die nächste Version tut. Gerade beliebte Pakete sind das Ziel, weil eine kompromittierte Version viele trifft. OWASP führt das in den Top 10 for Agentic Applications 2026 als eigenen Punkt ASI04 Agentic Supply Chain Vulnerabilities.

„Läuft ja nur lokal.“ Lokal heißt: mit deinen Rechten, auf dem Rechner mit deinen Schlüsseln. Ein entfernter Server sieht nur, was du ihm schickst. Ein lokaler sieht alles, was du sehen kannst.

Eine Anweisung im Prompt. „Benutze keine Werkzeuge, die Dateien außerhalb des Projekts lesen“ ist eine Bitte an ein Modell, das gerade eine gegenteilige Anweisung in einer Werkzeugbeschreibung gelesen hat. Was ein Server nicht tun soll, darf er technisch nicht können.

Einmal prüfen und vergessen. Die Freigabe gilt der Fassung, die du gesehen hast. Ohne festgeschriebene Version prüfst du bei jedem Start etwas, das du nie gesehen hast.

Der ehrliche Schluss#

MCP ist nützlich, weil es so wenig Aufwand macht, einer KI ein neues Werkzeug zu geben. Derselbe geringe Aufwand macht es leicht, ihr eines zu geben, das niemand geprüft hat. Für einen kleinen Betrieb reicht die Prüfliste oben: wenige Server, bekannte Herkunft, feste Versionen, enge Tokens. Wie ein Arbeitsablauf mit wenigen, eng begrenzten Servern in der Praxis aussieht, zeigt Claude Code für SEO. Was danach noch schiefgehen kann, betrifft den Agenten selbst, und dafür gelten die fünf Maßnahmen aus dem Beitrag zu den Risiken von KI-Agenten.

Stand 04.10.2026. Quellen am selben Tag abgerufen; MCP-Spezifikation in der Fassung vom 28.07.2026.

Weiterlesen