Shadow MCP-Server

Was ist Shadow MCP-Server?

Ein MCP-Server, der für einen kurzen Versuch gestartet wurde, läuft oft weiter, nachdem sich niemand mehr an ihn erinnert – häufig mit Standard-Zugangsdaten und einer weiter als beabsichtigt gefassten Netzwerkbindung. Die Client-Konfiguration verrät nichts über ihn, denn sie zeigt nur bewusst registrierte Server. Sie gehen unerklärlichem Datenverkehr nach, führen einen Discovery-Scan durch und finden drei nicht registrierte Server. Sie vergleichen Scan und Liste in beide Richtungen, bewerten jeden Server und erzwingen am Gateway eine Allowlist, damit nicht genehmigte Server für alle Teams blockiert sind.

Was Sie lernen in Shadow MCP-Server

• Erkennen Sie einen Shadow-MCP-Server: einen, der läuft und erreichbar ist, aber nie durch den Genehmigungsprozess der Organisation registriert wurde
• Erklären Sie, warum die Liste der registrierten Server eines Clients (z. B. claude mcp list) nur anzeigt, was absichtlich hinzugefügt wurde, und warum eine kontinuierliche Erkennung erforderlich ist, um herauszufinden, was sonst noch tatsächlich lauscht
• Bewerten Sie die Ergebnisse eines Discovery-Scans anhand konkreter Risikosignale: aktive Standard-Zugangsdaten, kein eingetragener Verantwortlicher oder eine Netzwerkbindung über localhost hinaus
• Erkennen Sie, dass auch ein Discovery-Tool blinde Flecken hat: Ein Localhost-Scan kann einen legitimen Remote-Server übersehen. Deshalb muss Discovery mit einer erzwungenen Allowlist kombiniert werden; der Scan selbst ist deswegen nicht unzuverlässig.
• Erzwingen Sie eine Allowlist an einem zentralen Gateway, anstatt sich auf die lokale Blockierung eines einzelnen Clients zu verlassen, sodass ein nicht genehmigter Server für jedes Team, das er sonst erreichen könnte, eingedämmt wird

Shadow MCP-Server — Trainingsschritte

1. Eine Frage vom Plattformkanal

   Alice ist für die MCP-Governance bei Sarnholt Systems verantwortlich. Den genehmigten Serverbestand vollständig zu halten und alles aufzuspüren, was ohne den Genehmigungsprozess in Betrieb ging, ist Teil ihrer regulären Arbeit und keine besondere Aufgabe. Im Plattformkanal landet eine Nachricht von Marcus Webb, einem der Ingenieure in ihrem Team.

2. WorkStream öffnen

   Alice öffnet WorkStream, um Marcus’ Nachricht vollständig zu lesen.

3. Marcus' Frage

   Die Nachricht bestätigt die Kurzmeldung. Marcus hat Datenverkehr entdeckt, den er nicht erklären kann. In der Liste, die er mit seiner CLI geprüft hat, fehlt der Server.

4. Die registrierten Server prüfen

   Bevor Alice davon ausgeht, dass Marcus' CLI defekt ist, führt sie selbst denselben Befehl aus.

5. Drei registriert, alle verbunden

   Die CLI zeigt ihre registrierten Server an.

6. Nach tatsächlich erreichbaren Servern suchen

   Die Liste registrierter Server zeigt nur die beabsichtigte Konfiguration. Um herauszufinden, welche Server tatsächlich erreichbar sind, braucht Alice einen Discovery-Scan statt einer erneuten Abfrage derselben CLI-Konfiguration.

7. Was der Scan gefunden hat

   Das Scan-Ergebnis hat zwei Teile: Server, die auch in der CLI-Liste stehen, und Server, die Marcus mit claude mcp list nicht finden konnte.

8. Prüfung: zwei unterschiedliche Listen

9. Zeit, es durchzusetzen

   Ein Terminal-Scan ist eine Momentaufnahme der aktuell erreichbaren Server. Ein morgen gestarteter und später vergessener Testserver fehlt in diesem Scan. Ohne erzwungene Allowlist könnte er dennoch erreichbar sein. Die Allowlist von Sarnholt wird am MCP Gateway durchgesetzt.

10. Öffnen des Gateways

    Serverfreigaben und die verbindliche Allowlist werden am Gateway verwaltet, nicht im Terminal eines einzelnen Entwicklers.