Für MCP gibt es keine Admin-Konsole. Das ist die Kernaussage einer Analyse, die untersucht, welche MCP-Server Mitarbeiter auf ihren Laptops verbunden haben. Der Satz klingt beiläufig, beschreibt aber etwas Grundsätzliches: keine Lücke, die ein Anbieter gelassen hätte, sondern eine Eigenschaft des Protokolls. Damit fällt die erste Stelle weg, an der ein Sicherheitsteam normalerweise nachsieht.
Denn dort steht nichts. Kein SSO-Log, weil die meisten MCP-Server lokal starten und nie gegenüber etwas authentifizieren, das man kontrolliert. Kein Beschaffungseintrag, weil nichts beschafft wurde. Keine Admin-Konsole, weil das Protokoll keine definiert. Keine Netzwerksignatur, weil ein stdio-Server über eine Pipe zwischen zwei Prozessen auf derselben Maschine kommuniziert.
Was übrig bleibt: eine JSON-Datei im Home-Verzeichnis eines Entwicklers, von Hand bearbeitet. Die einzige Quelle der Wahrheit, und sie liegt auf einem Laptop. Daraus ergibt sich die Frage nach der Sichtbarkeit von MCP-Servern — unangenehmer, als sie zunächst klingt.
Wo die Konfiguration tatsächlich liegt
MCP wurde für einen lokalen Client entworfen, der im Auftrag eines einzelnen Nutzers einen lokalen Server startet. Daraus folgt, dass jeder Client seine eigene Konfiguration pflegt. Claude Desktop liest die claude_desktop_config.json aus dem Application-Support-Verzeichnis des Nutzers, Cursor liest .cursor/mcp.json auf Nutzer- oder Projektebene, Claude Code verwendet .mcp.json im Projekt zusammen mit einer Nutzerkonfiguration, und VS Code hält seine MCP-Einträge in den Editor-Einstellungen.
| Client | Konfiguration |
|---|---|
| Claude Desktop | claude_desktop_config.json im Application-Support-Verzeichnis |
| Cursor | .cursor/mcp.json auf Nutzer- oder Projektebene |
| Claude Code | .mcp.json im Projekt plus Nutzerkonfiguration |
| VS Code / Copilot | MCP-Einträge in den Editor-Einstellungen |
Wer drei dieser Clients parallel nutzt, hat drei getrennte Inventare, und keines weiß von den anderen. Eine einzelne Datei sagt dir also nur etwas über einen Client auf einer Maschine. Die organisatorische Frage verlangt dagegen alle Dateien, auf allen Maschinen, fortlaufend. Denn die Antwort ändert sich, sobald jemand eine Datei bearbeitet.
Der Servername grenzt nichts ein
Der häufigste Fehler beim ersten Inventarversuch: Servernamen sammeln und die Aufgabe für erledigt halten. Der Name ist ein Etikett, gewählt von dem, der die Konfiguration geschrieben hat. Er wird nicht validiert, nicht registriert und steht in keiner überprüfbaren Beziehung zu dem, was der Server tut. Ein Eintrag namens docs kann jede ausführbare Datei mit beliebigen Argumenten starten.
Die Autoren ordnen das in dieselbe Kategorie ein wie das, was sie bei Claude Code als namensgebundenes Vertrauen beschrieben haben: Was ein Nutzer bestätigt, und was tatsächlich läuft, verbindet nur eine Zeichenkette — und die kann ein Angreifer wählen. Wer den Servernamen als Identität behandelt, hält eine Behauptung für einen Beweis. Für die MCP-Sicherheit ist das der folgenreichste Denkfehler.
Was wirklich zählt: der aufgelöste Befehl
Vier Angaben entscheiden, ob ein Eintrag harmlos oder riskant ist. Die erste ist der Einstiegspunkt. Zeigt er auf /bin/bash, /bin/sh oder python -c, übergibt der Server dem verbundenen Agenten eine Shell auf dem Laptop. Kein subtiles Risiko, sondern in der Konfiguration offen sichtbar — vorausgesetzt, jemand liest sie.
Die zweite sind Paket und Version, die tatsächlich laufen. Die meisten MCP-Server starten über npx mit einem gleitenden Tag, das erst zur Startzeit aufgelöst wird. Ausgeführt wird also der Code, den die Registry zuletzt ausgeliefert hat — nicht der, den jemand geprüft hat. Beim Figma-MCP-Server wurde eine Schwachstelle in einem Patch-Release behoben, den die meisten Nutzer erhielten, ohne sich je dafür entschieden zu haben.
Die dritte sind die Zugangsdaten. API-Schlüssel und Tokens werden regelmäßig über Umgebungsvariablen in derselben Konfigurationsdatei an MCP-Server übergeben. Ein Inventar, das Servernamen erfasst, aber nicht, was ihnen übergeben wurde, lässt genau den Teil aus, den ein Sicherheitsteam am dringendsten braucht. Die vierte ist der Transport. stdio und HTTP haben unterschiedliche Angriffsflächen — das zeigen die drei CVEs des n8n-MCP-Servers: Alle drei setzten den HTTP-Multitenant-Modus voraus, keiner erreicht eine lokale stdio-Installation.
Warum das ein Endpoint-Problem ist
Man kann das als Identitätsproblem behandeln und mit Tokens und Scopes lösen wollen. Das hilft den entfernten, OAuth-gestützten Servern — erreicht aber die Mehrheit nicht, die aus lokalen, per Konfigurationsdatei gestarteten Prozessen besteht. Ebenso kann man es als Netzwerkproblem behandeln. Es scheitert aus demselben Grund, aus dem die Erkennung lokaler LLMs auf der Netzwerkebene scheitert: Ein stdio-Server spricht mit seinem Client über eine Pipe, und nichts überquert dabei eine Schnittstelle, die man beobachten könnte.
Die Konfigurationsdatei liegt auf dem Endpunkt. Der Prozess läuft dort. Die Zugangsdaten liegen dort. Jede Antwort, die den Endpunkt nicht liest, ist eine Schlussfolgerung aus Indizien — und so entstehen Zahlen, die selbstsicher falsch sind. MCP-Server-Sicherheitsrisiken erkennen heißt also, dort nachzusehen, wo die Deklaration steht.
Was ein echtes Inventar erfassen muss
Ein brauchbares Inventar wird pro Maschine und pro Nutzer geführt und fortlaufend aktualisiert, nicht einmalig erfasst. Es verzeichnet: welche Agent-Clients installiert und aktiv sind; welche MCP-Server jeder Client deklariert; den aufgelösten Einstiegspunkt jedes Servers; Paket und tatsächlich laufende Version statt der nominell festgelegten; die über Umgebungsvariablen übergebenen Zugangsdaten und Geheimnisse; sowie den Transport und bei HTTP-Servern das, wogegen sie exponiert sind.
Diese Liste ist nicht exotisch. Es sind eine Handvoll Dateien und eine Prozesstabelle — genau die Daten, die ein Endpoint-Agent ohnehin für andere Zwecke erhebt. Die Lücke: Niemand hat ihm diese Fragen gestellt. Wer wissen will, welche MCP-Server Mitarbeiter verbunden haben, kommt an den MCP-Konfigurationsdateien nicht vorbei. Eine zentrale Registry, eine Admin-Konsole oder ein SSO-Log gibt es nicht. Und wie oft sich das ändert, gehört ebenfalls zur Antwort: Einen MCP-Server zu installieren ist eine Textbearbeitung mit anschließendem Client-Neustart. Kein Ticket, kein Beschaffungsschritt, kein Anmelderekord.
Einordnung
Ein einmalig erfasstes Inventar ist der Schnappschuss einer Konfiguration, die sich bereits geändert haben kann. MCP-Server-Inventarisierung muss deshalb dauerhaft laufen, keine einmalige Prüfung sein. Neue Infrastruktur braucht es dafür nicht — nur eine andere Frage an die bestehende Endpoint-Inventarisierung.
Die Analyse stammt von Repello AI und bewirbt am Ende das eigene Werkzeug Workstation Lens, das genau das leistet: die Dateien über die Flotte lesen, Einstiegspunkte auflösen, solche mit Shell-Verweis markieren und die real laufenden Versionen berichten. Diese Interessenlage sollte man beim Lesen im Kopf behalten. An der Struktur des Problems ändert sie nichts: Solange MCP keine organisatorische Kontrollebene definiert, bleibt die einzige verlässliche Aufzeichnung ein Textdokument in einem Home-Verzeichnis. MCP-Server ohne Admin-Konsole zu verwalten ist deshalb keine Notlösung, sondern der Normalfall. Man kann ihn schlecht oder gut betreiben — ignorieren lässt er sich nicht.
Quelle: repello.ai
