10.05.2026 AI Engineering 5 Minuten Lesezeit

MCP im Unternehmenseinsatz: Registry und Gateways

Die offizielle MCP-Registry macht Server auffindbar, Streamable HTTP mit OAuth 2.1 macht sie remote. Daraus entstand ein Markt für Gateways mit zentraler Authentifizierung, Autorisierung je Werkzeug und Audit. Der Artikel zeigt, was die Registry garantiert, warum das Protokoll ein Gateway nahelegt, welche Risiken bleiben und wie ein minimaler Rollout im Unternehmen aussieht.

Warum MCP zum Infrastrukturthema wurde

MCP begann als lokales Integrationsformat. Ein Client startete einen Server über stdio und übernahm dessen Fähigkeiten. Dieses Modell hält dem Kontakt mit einer Organisation nicht stand. Sobald einige hundert Entwickler einige Dutzend Server an Produktionssysteme anbinden, lautet die Frage nicht mehr, wie ein Werkzeug beschrieben ist. Sie lautet, wer es aufrufen darf, unter welcher Identität und wo der Nachweis dieses Aufrufs landet.

Zwei Entwicklungen haben daraus eine Infrastrukturfrage gemacht statt einer Client-Frage: eine öffentliche Registry, die Server im großen Maßstab auffindbar macht, und ein Remote-Transport mit verbindlichem Autorisierungsmodell. Der Gateway-Markt, der sich in den Jahren 2025 und 2026 gebildet hat, folgt unmittelbar aus 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.

Ehrlich ist erst die rechte Spalte. Ein Gateway ist eine Identitäts- und Richtlinienschicht. Es interpretiert nicht, was ein Werkzeug zurückgibt, und es macht aus einem nicht vertrauenswürdigen Server keinen vertrauenswürdigen. Es fügt zudem einen Single Point of Failure und einen Hop hinzu, den jedes Latenzbudget verkraften muss.

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 betrifft die Messung. Deny by Default ist leicht geschrieben und schwer aktuell zu halten, während die Kataloge wachsen. Wer erfasst, welche Werkzeuge tatsächlich aufgerufen werden, von wem und mit welchem Ergebnis, kann seine Scopes belegbar verkleinern. Wer das nicht tut, behält die Wildcard und nennt sie Governance.