MCP-Server Sicherheit: Deine Keys im Klartext?

MCP-Server halten die Zugangsdaten zu deinen Systemen – meist im Klartext. Wo die Risiken liegen und wie du dein Setup in fünf Schritten absicherst.

MCP-Server Sicherheit ist das Thema, das in vielen KI-Setups noch niemand angefasst hat. Das Model Context Protocol verbindet KI-Assistenten mit echten Systemen – Datenbanken, Dateiablagen, Cloud-APIs. Damit das funktioniert, braucht der MCP-Server die Zugangsdaten dieser Systeme. Er wird damit zu einem der sensibelsten Bausteine der Umgebung. Ein Beitrag von The Hacker News vom 17. August 2026 hat das Thema wieder hochgespült – ein guter Anlass, das eigene Setup ehrlich anzusehen.

Warum MCP-Server Zugangsdaten anhäufen

Das Model Context Protocol ist ein offener Standard: 2024 von Anthropic gestartet, seit Dezember 2025 unter dem Dach der Agentic AI Foundation der Linux Foundation. Es gibt also keinen einzelnen Hersteller mehr, der für die Sicherheit der tausenden veröffentlichten Server geradesteht – und genau da beginnt das Problem.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

Technisch erlaubt MCP einem KI-Agenten, nicht nur zu antworten, sondern zu handeln: einen Datensatz abrufen, eine Datei öffnen, eine API aufrufen. Dazwischen sitzt der MCP-Server, ein kleines Programm, das die erlaubten Aktionen bereitstellt. Und um eine Aktion auszuführen, braucht es die Anmeldedaten des Zielsystems. Der strukturelle Punkt dabei: Ein Agent ist keine Suchmaschine mehr, sondern eine handelnde Identität. Ein abgeflossenes Token bedeutet nicht nur, dass jemand Daten sieht – er kann damit auch etwas tun.

Die typischen Schwachstellen

Der Beitrag von The Hacker News ist als Gastbeitrag von Keeper Security gekennzeichnet, einem Anbieter für Secrets-Management. Das gehört zur Einordnung dazu: Die Analyse ist brauchbar, die Produktempfehlung am Ende liest man mit diesem Wissen. Genannt werden fünf Muster, die ich aus eigener Praxis bestätigen kann:

Klartext-Zugangsdaten in Konfigurationsdateien. Bei den meisten MCP-Servern besteht die Einrichtung darin, einen Konfigurationsblock mit dem Token hineinzukopieren. Die Datei bleibt dann liegen – auf der Platte, im Sync-Ordner, gelegentlich versehentlich im Git-Repository.
Verstreute Geheimnisse. Ohne zentrale Ablage verwaltet jeder Agent seine eigenen Schlüssel. Kopien sammeln sich, niemand hat eine vollständige Liste, und rotiert wird deshalb praktisch nie.
Prompt Injection. Ein Agent liest, was man ihm gibt. Versteckte Anweisungen in einem Dokument, einem Ticket oder auf einer Webseite können ihn dazu bringen, seine Werkzeuge falsch zu benutzen.
Zu weite Berechtigungen. Beim Entwickeln vergibt man großzügige Scopes, um Fehler zu vermeiden – und die gehen dann so in den Betrieb.
Fremde Server als Lieferkettenrisiko. Jeder darf einen MCP-Server veröffentlichen.

Für den letzten Punkt gibt es einen belegten Fall: CVE-2025-6514 im OAuth-Proxy mcp-remote, der lokal auf dem Client läuft. Ein bösartiger – oder per Man-in-the-Middle gekaperter – MCP-Server konnte über eine präparierte authorization_endpoint-Response-URL Betriebssystembefehle auf der Client-Maschine ausführen (CWE-78). Betroffen sind die Versionen 0.0.5 bis einschließlich 0.1.15. Gefunden hat die Lücke Or Peles vom JFrog Security Research Team, veröffentlicht wurde sie am 9. Juli 2025.

Zwei Details, die man kennen sollte, bevor man die Zahl weiterträgt: Die Bewertung mit CVSS 3.1 und dem Base Score 9.6 („kritisch”, Vektor AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) stammt von JFrog als CNA – das NVD führt den Eintrag bis heute ohne eigene Bewertung. Und UI:R heißt: Es braucht eine Nutzeraktion, nämlich das Verbinden mit dem präparierten Server. Der Angriff läuft also nicht gegen den Server, sondern gegen den Rechner, auf dem der Client läuft.

Was das für dich bedeutet

Wenn du MCP nur lokal auf deinem eigenen Rechner nutzt, ist das Risiko überschaubar – aber es ist nicht null, und es liegt woanders, als die meisten vermuten. Deine Konfiguration ist bei den gängigen Desktop-Clients eine unverschlüsselte JSON-Datei im Benutzerprofil. Liegt dieses Profil in einem synchronisierten Cloud-Ordner, hast du deine Produktiv-Tokens in die Cloud gelegt, ohne es zu entscheiden. Läuft ein Backup mit, liegen sie zusätzlich im Backup – unrotiert und unbefristet gültig.

Im Unternehmenskontext verschiebt sich das Bild noch einmal deutlich. Aus Identity-Sicht ist ein MCP-Server nichts anderes als ein Dienstkonto mit weitreichenden Rechten, das niemand im Berechtigungsreview hat, weil es in keinem Verzeichnis auftaucht. Das ist exakt das Problem, das wir bei Service-Accounts seit zwanzig Jahren kennen – nur richten Fachbereiche es diesmal selbst ein, in Minuten, ohne Ticket. „Shadow AI” ist dafür ein hübscher Begriff; nüchtern betrachtet ist es unverwaltete privilegierte Identität.

Fünf Schritte, die heute Sinn ergeben

Die generischen Empfehlungen – zentralisieren, Least Privilege, Human in the Loop, Inventur – findest du so auch bei Keeper. Sie sind richtig, aber unspezifisch. Hier ist die Reihenfolge, in der ich sie für ein reales Setup abarbeiten würde, plus das, was in solchen Listen meist fehlt:

Inventur machen. Öffne deine MCP-Konfiguration und zähl nach, wie viele Tokens dort im Klartext stehen und wann du sie zuletzt erneuert hast. Diese Zahl ist bei fast jedem überraschend hoch.
Config aus Cloud-Sync und Backup-Set herausnehmen. Der Schritt, den keine Best-Practice-Liste nennt und der am schnellsten wirkt: Solange die Konfigurationsdatei mitsynchronisiert wird, hilft dir Rotation wenig, weil alte Stände weiterleben.
Secrets aus der Config holen. Eine einzige Quelle für alle Schlüssel, aus der zur Laufzeit gelesen wird – das löst Klartext-Ablage und Wildwuchs in einem Schritt. Ich lade meine Keys ausschließlich über einen zentralen Loader; in Prompt und Config-Datei steht kein Passwort mehr.
Ein eigenes Konto pro MCP-Server, mit möglichst lesenden Rechten. Nicht nur wegen Least Privilege: Erst dadurch siehst du im Log, welcher Agent gehandelt hat. Ein Sammel-Account macht jede spätere Aufklärung unmöglich.
Schreibende Aktionen bestätigen lassen und Versionen pflegen. Löschen, Veröffentlichen, Zugriff auf Produktivsysteme: ausdrückliche Rückfrage. Das ist der Punkt, an dem ein Prompt-Injection-Versuch scheitert, statt still durchzulaufen. Und bei mcp-remote ist die Lücke seit 0.1.16 behoben – aktuell ist allerdings 0.1.38, also nicht nur „größer als der Fix” prüfen, sondern mitziehen.

Die simpelste Regel bleibt dabei die wirksamste: keinen MCP-Server aus unbekannter Quelle anschließen. Welche sich in der Praxis bewährt haben, steht in meinem Überblick zu den besten MCP-Servern für Claude Desktop. Und wer den Datenabfluss grundsätzlich vermeiden will, betreibt sein Modell lokal – die passende Hardware für lokale KI und LLMs habe ich separat zusammengestellt.

Quellen

Dranbleiben

Diese Analysen als Newsletter

Ein Mal pro Woche Klartext zu KI, Security & Crypto – direkt in dein Postfach.

Jetzt anmelden

MCP-Server Sicherheit: Wenn KI-Agenten deine Keys halten