MCP Registry: Eigene Subregistry für Enterprise IT?

Phillip Pham, Pexon Consulting | 11 Min. Lesezeit | 23.04.2026

TL;DR

Die MCP Registry ist seit September 2025 der zentrale Discovery-Layer für Model Context Protocol Server — von 390 auf rund 2.000 Einträge in zehn Wochen gewachsen. Pexon Consulting, Microsoft Partner mit 80 Mitarbeitern in Deutschland, baut für regulierte DACH-Kunden eigene Subregistries als kuratierten Filter zwischen Public Registry und Produktion. So vermeiden Banken und Versicherer CVE-Exposure ohne Innovationsstop.

Was sich am 8. September 2025 verändert hat

Am 8. September 2025 hat Anthropic die offizielle MCP Registry unter registry.modelcontextprotocol.io im Preview gelauncht. In den ersten zehn Wochen ist sie von 390 auf rund 2.000 Einträge gewachsen — plus 407 Prozent. Der alternative Index Glama listet inzwischen 21.949 Open-Source MCP Server, die offiziellen Anthropic-SDKs werden über 97 Millionen Mal pro Monat heruntergeladen.

Wir bei Pexon hatten in den Wochen nach dem Launch fast täglich die gleiche Konversation mit IT-Leitern aus Versicherung, Banking und Fertigung: „Unsere Entwickler installieren jetzt MCP Server. Wer hat das eigentlich freigegeben?“ Die ehrliche Antwort: niemand. Eine Public Registry ohne Kuratierungs-Layer ist für regulierte Branchen kein Discovery-Tool — sie ist eine offene Tür.

Dieser Artikel beantwortet drei Fragen, die uns Mid-Management-IT-Leiter im April 2026 stellen: Wie funktioniert die MCP Registry technisch? Welche konkreten Sicherheitsvorfälle gab es in den ersten Monaten? Und ab welcher Unternehmensgröße lohnt sich eine eigene Subregistry?

Die Architektur: Was eine Metaregistry technisch leistet

Die MCP Registry ist eine Metaregistry. Sie hostet keine Software, sondern Metadaten über Software. Wenn Sie ein MCP-Server-Paket installieren, lädt der Client die Metadaten aus der Registry und das eigentliche Paket aus npm, PyPI, Docker Hub oder einem GitHub Release.

Jeder Eintrag folgt dem Format server.json. Der wichtigste Block ist die Identität, die Paket-Quelle und die Runtime-Konfiguration:

{
  "name": "io.github.modelcontextprotocol/filesystem",
  "description": "Read and write files on the local filesystem",
  "packages": [
    {
      "registry_name": "npm",
      "name": "@modelcontextprotocol/server-filesystem",
      "version": "0.6.2"
    }
  ],
  "runtime_arguments": [
    {"type": "named", "name": "--allowed-paths"}
  ]
}

Das Naming-Schema validiert die Eigentümerschaft über zwei Wege. io.github.username/ wird über GitHub-OAuth oder GitHub-Actions-OIDC verifiziert. com.yourcompany/ über DNS-TXT-Records oder einen HTTP-Verifikations-Endpoint. Das verhindert Namespace-Squatting — schützt aber nicht vor bösartigem Code im Paket selbst. Genau dort liegt das Sicherheitsproblem.

Drei Deployment-Modi sind erlaubt: Package Deployment (Client lädt das Paket lokal aus npm/PyPI/Docker), Remote Deployment (Client verbindet sich per Streamable HTTP oder Server-Sent Events zu einem gehosteten Endpoint) und Hybrid Deployment. Für Enterprise relevant ist vor allem Remote — weil sich nur dort die Ausführung kontrollieren lässt.

Die Sicherheitslage 2026: Drei Vorfälle, die Sie kennen müssen

Im Juli 2025 hat JFrog CVE-2025-6514 im offiziellen mcp-remote-Paket veröffentlicht. CVSS 9.6, OS-Command-Injection über den OAuth authorization_endpoint. Betroffen waren die Versionen 0.0.5 bis 0.1.15 — und damit alle 437.000 Downloads vor dem Fix in 0.1.16. Ein Angreifer konnte mit einem präparierten OAuth-Server beliebigen Code auf jeder Maschine ausführen, die mcp-remote für die Verbindung zu remoten MCP Servern nutzte.

Im Mai 2025 demonstrierten die Invariant Labs den GitHub MCP Data Heist: Eine bösartige öffentliche GitHub Issue enthielt Prompt-Injection-Anweisungen. Der GitHub-MCP-Server hat sie an Claude weitergeleitet, Claude folgte den Anweisungen und exfiltrierte Daten aus den privaten Repos des gleichen Users. Keine Schwachstelle im Server-Code. Eine Schwachstelle in der Architektur: Tools, die mit User-Input ohne Trust-Boundary arbeiten, sind angreifbar.

Im April 2026 hat The Hacker News eine systemische RCE-Lücke im offiziellen Anthropic MCP SDK veröffentlicht — über alle Sprachen (Python, TypeScript, Java, Rust) und über 150 Millionen kumulierte Downloads. Mehr als 7.000 öffentlich erreichbare MCP Server waren zum Zeitpunkt der Veröffentlichung exponiert.

Unsere klare Position: Wer 2026 MCP Server aus der Public Registry direkt in Produktion nimmt, ohne SAST-Scan, SCA-Check und manuelles Permission-Audit, baut eine meldepflichtige DSGVO-Lücke in Zeitlupe. Das ist kein hypothetisches Risiko — das sind drei dokumentierte Vorfälle in zwölf Monaten. Die Spec hat seit November 2025 zwar PKCE als Pflicht und seit Juni 2025 OAuth Resource Server. Beides löst nur das Authentifizierungsproblem, nicht das Trust-Problem.

Build vs Buy: Wann lohnt sich eine eigene Subregistry?

Lohnt sich eine eigene MCP Subregistry für Ihr Unternehmen? Das hängt an drei harten Kriterien — wir nutzen sie als erstes Filter im Workshop:

Bei Banken und Versicherern fällt die Entscheidung in 95 Prozent der Fälle auf Subregistry — das ist keine Empfehlung, das ist eine regulatorische Konsequenz. Bei Mittelstands-Maschinenbauern (300-1.000 MA) hängt es daran, ob die MCP-Pipeline Konstruktionsdaten oder Kundendaten anfasst. Bei reinen DevTools-Use-Cases (z.B. GitHub-MCP für interne Code-Reviews) reicht ein Allowlist-Mechanismus auf Client-Ebene.

Was wir aktuell nicht empfehlen: Eine eigene Subregistry komplett von Hand auf Basis der offiziellen Registry-Codebase zu bauen. Die Maintainer haben explizit dokumentiert, dass die offizielle Implementierung nicht für Self-Hosting designed ist. Ein Fork ist möglich, kostet aber 4-6 Monate Engineering-Zeit für die Hardening-Arbeit, die Sie eigentlich in Ihren AI-Use-Case stecken wollten.

Praxis: So sieht eine Enterprise Subregistry aus

Drei Komponenten bilden den Mindest-Stack für eine produktionsreife Enterprise Subregistry. Wir setzen sie in der Regel in 4-6 Wochen auf — von der ersten Architektur-Session bis zum ersten freigegebenen MCP Server in Produktion.

Komponente 1: Gateway-Layer. Ein Open-Source-Projekt wie MCPJungle übernimmt die Vermittlung zwischen Clients und kuratierten Servern. Es spricht das MCP-Protokoll auf beiden Seiten und erlaubt zentrale Permission-Checks, Audit-Logs und Rate-Limiting:

# mcpjungle.yaml — minimal config für Enterprise
gateway:
  bind: "0.0.0.0:8443"
  tls: required
  audit_log: /var/log/mcpjungle/audit.jsonl

allowlist:
  - source: io.github.modelcontextprotocol/filesystem
    version: "0.6.2"  # pinned, kein semver-range
    sha256: "a3f7..."
    permissions: [read]
  - source: io.github.modelcontextprotocol/github
    version: "1.2.0"
    sha256: "9d12..."
    permissions: [read]
    require_approval: [create_issue, create_pr, delete_*]

deny_default: true

Komponente 2: Scanning-Pipeline. Vor jeder Aufnahme eines Servers in die Allowlist läuft ein automatisierter Scan: SAST über den Quellcode (Semgrep mit MCP-spezifischen Rules), SCA für die Dependencies (OSV-Scanner gegen die NVD-Datenbank), und ein manuelles Permission-Audit. Letzteres lässt sich nicht automatisieren — jemand muss die runtime_arguments und die exponierten Tools eines Servers gegen die Use-Case-Anforderung prüfen.

Komponente 3: Internal Discovery UI. Eine schlanke Web-Oberfläche (typischerweise Next.js + Postgres) zeigt Entwicklern die freigegebenen Server, ihre Permissions, ihre Verifikations-Geschichte und die Kontaktperson. Klingt trivial — ist aber der Hebel, der die Akzeptanz im Team hochhält. Ohne UI installieren Entwickler im Zweifel doch direkt aus der Public Registry.

# Entwickler-Workflow: MCP Server lokal anbinden
mcpjungle list                              # zeigt freigegebene Server
mcpjungle connect github-readonly --client claude-desktop
mcpjungle audit --server github-readonly    # zeigt eigene Nutzung der letzten 30 Tage

Für Microsoft-Stack-Kunden integriert sich die Subregistry über GitHub Copilot Enterprise und über Azure AI Foundry. Snowflake-Kunden, die schon Cortex Agents nutzen, können auf den Snowflake Managed MCP Servers-Layer aufsetzen — eine kommerziell gemanagte Subregistry mit Konnektoren zu Atlassian, GitHub, Glean, Linear und Salesforce.

Was deutsche Banken und Versicherer 2026 wissen müssen

Wir raten DACH-Kunden in regulierten Branchen aktuell davon ab, MCP Server direkt aus der Public Registry in Produktion zu nehmen — ohne Ausnahme. Das ist nicht übervorsichtig, das ist die ehrliche Konsequenz aus den drei dokumentierten Vorfällen 2025-2026 plus dem aktuellen Regulatorik-Stand.

Das BSI hat bisher kein dediziertes MCP-Statement veröffentlicht. BaFin und BSI haben gemeinsam vor KI-gesteuertem Banken-Betrug gewarnt — ohne MCP explizit zu nennen, aber mit klarer Stoßrichtung. Die DORA-Verordnung verlangt seit Januar 2025 ein nachvollziehbares Drittparteien-Risiko-Management. Ein MCP Server aus der Public Registry ist eine Drittpartei. Ohne Subregistry ist das Risiko nicht dokumentierbar.

Konkret bedeutet das: Bei einer Versicherung, die wir Anfang 2026 begleitet haben, ist die Subregistry nicht als „Sicherheitsmaßnahme“ im Compliance-Bericht aufgetaucht — sondern als dokumentierter Drittparteien-Kontroll-Layer nach DORA Art. 28. Das ist der Framing-Trick, der die Investition für CFO und Compliance-Officer verteidigbar macht.

Was wir in den nächsten zwölf Monaten erwarten: Die Spec wird in MCP 2026 die Role-Based Authorization ergänzen (aktueller Working-Draft-Stand). Das löst einen Teil des Permission-Problems, aber nicht das Trust-Problem. Das BSI wird vermutlich bis Ende 2026 ein Mindestanforderungs-Dokument für MCP Server in regulierten Branchen veröffentlichen — wir sehen Vorarbeiten in den DCSO-Diskussionen. Bis dahin ist eine eigene Subregistry der einzig verteidigbare Weg.

Häufig gestellte Fragen

Was ist die MCP Registry?

Die MCP Registry ist ein zentrales Verzeichnis für Model Context Protocol Server, vergleichbar mit einem App-Store. Sie hostet keine Software, sondern Metadaten — die eigentlichen Pakete liegen in npm, PyPI, Docker Hub oder GitHub Releases. Die offizielle Public Registry läuft unter registry.modelcontextprotocol.io und ist seit September 2025 im Preview verfügbar. Sie wird von Anthropic, GitHub, PulseMCP und Microsoft gemeinsam maintained.

Brauchen wir eine eigene MCP Subregistry?

Kommt auf drei Faktoren an: Anzahl Entwickler mit MCP-Zugriff, regulatorische Auflagen und die Art der Daten in Ihrer MCP-Pipeline. Für Banken, Versicherer und Energieversorger ist eine Subregistry praktisch unausweichlich — DORA, BaFin-MaRisk und NIS2 verlangen ein dokumentiertes Drittparteien-Risiko-Management. Für Mittelstands-Industriekunden mit weniger als 50 Entwicklern reicht oft eine Allowlist auf Client-Ebene.

Was kostet der Betrieb einer Enterprise MCP Subregistry?

Anthropic, GitHub und Snowflake veröffentlichen keine offiziellen Kosten. Aus unseren Pilotprojekten 2025-2026: Setup einer Subregistry mit Open-Source-Stack (MCPJungle, Semgrep, OSV-Scanner, Postgres, eigener Discovery-UI) liegt typisch bei 60-90k EUR Initialaufwand. Laufender Betrieb 1.500-3.500 EUR pro Monat für Hosting, plus 0,5 FTE für Kuratierung und Permission-Audits. Bei Snowflake-Kunden, die Managed MCP nutzen, entfällt der Setup-Aufwand — dafür kommt der Snowflake-Service-Cost dazu.

MCP Registry vs. eigener Code: Wann selbst bauen statt installieren?

Faustregel aus unseren Projekten: Standardprotokolle wie GitHub, Slack, SharePoint, Confluence, PostgreSQL — immer aus der Registry, niemals selbst bauen. Eigene Fachsysteme (SAP-Custom-Module, hauseigenes CRM, branchenspezifische Datenbanken) — immer selbst bauen, weil es entweder keinen Server gibt oder der vorhandene Ihre Permission-Granularität nicht abbildet. Hybrid-Ansatz ist häufig: Public-Registry-Server als Basis, dann ein eigener Wrapper-Server, der die Calls auf Ihren Permission-Layer abbildet.

Wie sicher sind MCP Server aus der Public Registry?

Heterogen. Die offiziellen Anthropic-Server (Filesystem, GitHub, Slack) sind grundsätzlich vertrauenswürdig — hatten aber in 2025-2026 trotzdem CVEs (CVE-2025-6514 in mcp-remote mit CVSS 9.6, RCE-Lücke im SDK über alle Sprachen mit über 150 Mio. betroffenen Downloads). Community-Server schwanken stark in Qualität und Wartung. Eine Practical-DevSecOps-Analyse fand in untersuchten MCP Servern 43 Prozent Command-Injection-Flaws und 30 Prozent unrestricted URL-Fetching. Ohne SAST-Scan, SCA-Check und Permission-Audit gehört kein Server in Produktion — egal ob offiziell oder Community.

Nächster Schritt

Wenn Sie 2026 MCP-Server in Produktion einsetzen wollen — egal ob Public Registry oder mit eigener Subregistry — empfehlen wir einen MCP-Architektur-Workshop als ersten Schritt. Zwei Tage, vor Ort oder remote, mit konkreten Empfehlungen für Ihren Stack und Ihre Compliance-Anforderungen. Wir liefern danach eine dokumentierte Architektur-Entscheidung, die Sie gegenüber Datenschutzbeauftragtem und Compliance-Officer verteidigen können.

Verwandte Themen