10.05.2026 AI Engineering5 Minuten Lesezeit

MCP im Unternehmenseinsatz: Registry und Gateways

Die offizielle MCP-Registry macht Server auffindbar; Streamable HTTP und OAuth 2.1 machen sie aus der Ferne nutzbar. Damit entsteht Bedarf an Gateways für zentrale Authentifizierung, Autorisierung je Werkzeug und Audit. Wir klären, was die Registry tatsächlich garantiert, warum die Architektur ein Gateway nahelegt, welche Risiken offenbleiben und wie ein minimaler Enterprise-Rollout aussieht.

Warum MCP zum Infrastrukturthema wurde

MCP begann als lokales Integrationsformat: Ein Client startete einen Server über stdio und übernahm dessen Fähigkeiten. Auf Organisationsebene skaliert dieses Modell jedoch nicht. Sobald einige hundert Entwickler einige Dutzend Server an Produktionssysteme anbinden, geht es nicht mehr nur darum, wie ein Werkzeug beschrieben ist, sondern darum, wer es unter welcher Identität aufrufen darf und wo der Nachweis dieses Aufrufs landet.

Zwei Entwicklungen verlagerten das Thema vom einzelnen Client in die Infrastruktur: eine öffentliche Registry, die Server im großen Maßstab auffindbar macht, und ein Remote-Transport mit verbindlichem Autorisierungsmodell. Der Gateway-Markt der Jahre 2025 und 2026 ist keine zufällige Zusatzschicht, sondern die unmittelbare Folge dieser beiden Entwicklungen.

Ein Agent erreicht seine Tools über MCP — eine Standard-Schnittstelle. 1/4

Was die offizielle Registry wirklich garantiert

Die offizielle MCP-Registry ging am 8. September 2025 unter registry.modelcontextprotocol.io als Preview an den Start, getragen von Maintainern aus Anthropic, GitHub, Microsoft, Block und PulseMCP. Server werden in einem server.json-Schema beschrieben: ein Reverse-DNS-Name wie io.github.user/server, das Paket oder der Remote-Endpunkt, der ihn bereitstellt, und Konfigurationshinweise. Namensräume werden über GitHub-Konto, DNS-Eintrag oder HTTP-Challenge nachgewiesen. Eine unabhängige Abfrage der API am 11. März 2026 zählte 3.012 eindeutige Server in 8.074 Versionsdatensätzen.

Die Garantie ist enger, als viele annehmen. Die Registry authentifiziert Namensräume und hostet Metadaten. Den Code-Scan delegiert sie an npm, PyPI und Docker Hub sowie an nachgelagerte Aggregatoren. Private Server nimmt sie bewusst nicht auf und verweist Betreiber auf selbst gehostete Registries mit derselben OpenAPI-Schnittstelle. Sie ist ein Namenssystem, kein Trust Store. Acht Monate nach dem Start trägt sie weiterhin den Status Preview.

Remote-Server und OAuth 2.1 als Standardfall

Streamable HTTP kam mit der Spezifikationsrevision 2025-03-26 und ersetzte die ältere Kombination aus HTTP und SSE. Das Autorisierungskapitel, zuletzt am 25. November 2025 überarbeitet, benennt die Struktur unmissverständlich. Ein geschützter MCP-Server ist ein OAuth-2.1-Resource-Server. Er muss Protected Resource Metadata nach RFC 9728 veröffentlichen, unauthentifizierte Aufrufe mit 401 und einem WWW-Authenticate-Header beantworten und prüfen, dass jedes Bearer-Token ihn als Audience nennt.

Clients müssen den resource-Parameter nach RFC 8707 in Autorisierungs- und Token-Anfragen mitsenden und PKCE mit S256 verwenden. Token-Passthrough ist ausdrücklich verboten: Ein Server darf kein Token akzeptieren, das für etwas anderes ausgestellt wurde, und das Token des Clients nicht an eine vorgelagerte API weiterreichen. Die Novemberrevision bevorzugt außerdem Client ID Metadata Documents gegenüber der dynamischen Client-Registrierung, die nun vor allem der Abwärtskompatibilität dient.

Die Praxis hinkt der Spezifikation hinterher. In der Stichprobe vom März 2026 stellte rund ein Drittel der registrierten Server einen Remote-Endpunkt bereit, nur 8,5 Prozent nutzten überhaupt OAuth, und 53 Prozent verließen sich auf langlebige statische Geheimnisse. Der Standardfall auf dem Papier und der Regelfall im Feld sind weiterhin zwei verschiedene Dinge.

Warum das Protokoll ein Gateway nahelegt

Drei Eigenschaften machen das Abfangen naheliegend. Der Transport ist gewöhnliches HTTP mit einem Bearer-Token, ein Reverse Proxy sieht also ohnehin jeden Aufruf. Fähigkeiten werden zur Laufzeit über tools/list ermittelt, ein Proxy kann also einen gefilterten Katalog ausliefern, ohne dass eine der beiden Seiten es bemerkt. Und die Ressourcenidentität ist eine URL, ein Endpunkt kann also vor vielen Servern stehen und bleibt dabei eine gültige OAuth-Audience.

Darauf beruht der gesamte Gateway-Markt. Ein Gateway beendet den OAuth-Flow des Clients gegen den unternehmenseigenen Identity Provider, hält eigene Zugangsdaten für die vorgelagerten Systeme und veröffentlicht einen kuratierten Werkzeugsatz unter einer kanonischen URI. Die Spezifikation verbietet das nicht. Das Verbot des Token-Passthrough legt es sogar nahe, denn die Grenze zwischen Client-Credential und Upstream-Credential muss irgendwo verlaufen.

Was ein Gateway leistet und was nicht

Bis Anfang 2026 hatte sich der Funktionsumfang über Open-Source-Produkte und kommerzielle Produkte hinweg angeglichen. Vier Funktionen wiederholen sich: eine einzige an das Unternehmens-SSO gebundene OAuth-2.1-Eingangstür, Autorisierung auf Ebene des einzelnen Werkzeugs statt des Servers, ein Auditeintrag pro Werkzeugaufruf mit Aufruferidentität und Argumenten sowie netzseitige Erkennung von MCP-Endpunkten, die niemand registriert hat.

Für die Bewertung ist vor allem die rechte Spalte entscheidend. Ein Gateway bleibt eine Identitäts- und Richtlinienschicht: Es interpretiert keine Werkzeugausgaben und verwandelt einen nicht vertrauenswürdigen Server nicht in einen vertrauenswürdigen. Gleichzeitig schafft es einen Single Point of Failure und einen zusätzlichen Hop, den Verfügbarkeits- und Latenzbudgets ausdrücklich berücksichtigen müssen.

Aspekt	Am Gateway durchsetzbar	Bleibt an anderer Stelle
Aufrufer-Identität	OAuth 2.1 gegen das Unternehmens-IdP	Session-Bindung im Server
Werkzeug-Autorisierung	Erlauben oder verweigern pro Werkzeug und Rolle	Prüfung der Argumente im Werkzeug
Zugangsdaten	Upstream-Secrets erreichen den Client nie	Rotation im Zielsystem
Audit	Ein Datensatz pro Werkzeugaufruf	Korrelation mit Logs des Zielsystems
Werkzeugausgabe	Nur Größen- und Musterfilter	Vertrauensentscheidung von Modell und Client

Risiken jenseits der Control Plane

Drei Risiken gelten als kanonisch, und keines davon wird durch Zentralisierung geschlossen. Prompt Injection über Werkzeugergebnisse steht an erster Stelle. Eine Werkzeugbeschreibung oder ein zurückgegebenes Dokument kann Anweisungen enthalten, und das Modell liest beides als Kontext. Die OWASP führt das als MCP03:2025 Tool Poisoning; öffentliche Proof-of-Concept-Angriffe gibt es seit April 2025. Ein Gateway kann die Nutzlast protokollieren. Entscheiden, was das Modell ignorieren soll, kann es nicht.

Token-Diebstahl folgt an zweiter Stelle. Zentralisierte Zugangsdaten bündeln Wert: Ein kompromittiertes Gateway ist ein kompromittierter Bestand, und kurze Token-Laufzeiten wiegen hier schwerer als anderswo. Zu weit gefasste Berechtigungen stehen an dritter Stelle. Die Spezifikation selbst nennt Wildcard- und Sammelscopes als typischen Fehler und verlangt eine schrittweise Erhöhung über insufficient_scope-Challenges. Die meisten Installationen vergeben den vollen Katalog weiterhin einmalig beim Verbindungsaufbau und prüfen ihn nie wieder.

Ein minimaler Rollout im Unternehmen

Wir setzen das in vier Schritten um und widerstehen dem fünften. Beginnen Sie mit der Inventur. Durchsuchen Sie den ausgehenden Verkehr nach MCP-Endpunkten, bevor Sie eine Richtlinie schreiben, denn der nicht genehmigte Bestand ist meist größer als der genehmigte. Eine Befragung von 750 Technologieverantwortlichen aus den USA und Großbritannien im Februar 2026 ergab, dass 47 Prozent von rund drei Millionen eingesetzten Agenten nicht aktiv überwacht wurden und 88 Prozent der Unternehmen im Vorjahr einen agentenbezogenen Vorfall hatten oder vermuteten.

Danach ein Eingang: Jeder Client spricht mit genau einer Gateway-URL und mit nichts sonst. Danach ein Werkzeugkatalog nach dem Prinzip Deny by Default, abgebildet auf bereits vorhandene Rollen und pro Werkzeug freigegeben statt pro Server. Danach ein Auditstrom, der Aufrufer, Werkzeug, Argumente und Ergebnis in dasselbe SIEM schreibt wie alles andere. Menschliche Freigaben bleiben dort, wo der Schaden real wird.

Wohin sich das entwickelt

Die Registry trägt weiterhin den Status Preview. Spiegeln Sie sie, statt von ihr abzuhängen: Versionen pinnen, Namensräume prüfen, einen internen Katalog führen, der einen Datenreset im Upstream übersteht. Die spannende Arbeit des kommenden Jahres verlagert sich aus unserer Sicht vom Zugriff zur Herkunft: signierte Server-Metadaten, Attestierung des Pakets hinter einem Registry-Eintrag und Richtlinien, die die Attestierung lesen statt eines Hostnamens.

Die zweite Verschiebung führt von statischen Regeln zu messbarer Nutzung. Deny by Default ist schnell formuliert, aber mit wachsenden Katalogen schwer aktuell zu halten. Wer erfasst, welche Werkzeuge tatsächlich von wem und mit welchem Ergebnis aufgerufen werden, kann Scopes anhand von Evidenz verkleinern. Ohne diese Messung bleibt die Wildcard bestehen — nur unter dem Etikett Governance.