Ein MCP-Gateway gilt als Integrationsprojekt. Sind die Agenten erst einmal an Slack, GitHub, Salesforce und das Data Warehouse angeschlossen, wirkt der Rest wie Fleißarbeit. Der Feldbericht, den Mihai Parparita von Sierra am 22. Juli 2026 veröffentlicht hat, zeigt etwas anderes. Die Verbindungen waren nicht das Hindernis, sondern die Voraussetzung. Aufgehalten hat die unternehmensweite Ausrollung die Frage, ob man das Ganze gefahrlos einschalten kann. Der Text beschreibt eine interne Agenten-Plattform von innen und ist nützlich für jedes Team, das gerade ein Gateway aufsetzt.
Die Auswertung stammt von Maria Paktiti vom Auth-Anbieter WorkOS (11. September 2026), also von einem Team, das selbst eine interne Agenten-Plattform mit eigener gemeinsamer MCP-Oberfläche betreibt und nach eigener Aussage an derselben Stelle hängengeblieben ist. Das ist keine Außenperspektive auf ein fremdes Problem, sondern eine Beschreibung aus eigener Erfahrung. Wer den Bericht liest, liest deshalb zwei Dinge gleichzeitig: was bei Sierra passiert ist und warum dieselben Muster auch anderswo auftauchen.
Der Eisberg: Was oben schwimmt und was darunter liegt
Die Spitze des Eisbergs lässt sich gut demonstrieren: 89 Prozent der Sierra-Mitarbeiter verbinden laut dem Bericht ihre Agenten über eine einzige Seite mit 45 verschiedenen Diensten. Die Masse darunter ist Authentifizierung. Der Autor schreibt, MCP sei nach Maßstäben der KI-Branche „uralt“ – das Verbinden von Agenten mit internen Systemen hätte also geradlinig sein müssen. Geworden ist daraus, in seinen Worten, „ein weiterer Eisberg“.
Er geht anschließend sieben Lektionen durch. Je weiter man liest, desto deutlicher wird ein Muster: Die teuren Lektionen handeln kaum noch von MCP. Sie handeln von Identität, Berechtigungs-Scopes, Einwilligung und Audit. An diesen vier Themen arbeitet Unternehmenssoftware seit rund zwanzig Jahren. Agenten machen alle vier gleichzeitig wieder dringend, und die alten Antworten lassen sich nicht sauber übertragen. Eine Sitzung, die ein Mensch öffnet und wieder schließt, ist etwas anderes als ein Agent, der zwischen zwei Werkzeugaufrufen hin und her springt. Ein Dienstkonto mit festen Rechten ist etwas anderes als ein Modell, das selbst entscheidet, welches Werkzeug es als Nächstes anfasst.
Die Spezifikation lässt das Gateway offen – jedes Unternehmen füllt die Lücke selbst
Schon im März 2026 hatte dasselbe Team die Roadmap von MCP durchgesehen und Gateway- sowie Proxy-Muster als offenes Feld markiert. Damals waren drei Dinge schlicht nicht spezifiziert: wie sich eine Autorisierung durch eine Kette von Aufrufen fortpflanzt, was eine Sitzung in diesem Zusammenhang überhaupt bedeutet und wo die Grenzen der Sichtbarkeit verlaufen. Die Schlussfolgerung damals lautete, dass ohne Vorgaben auf Spezifikationsebene jedes Unternehmen sein eigenes Gateway-Verhalten erfindet.
Der Sierra-Bericht zeigt, wie das von innen aussieht, und zwar bei einem Haus, das es gut gemacht hat. Er widerlegt die Lücke nicht, er beschreibt sie. Auch der Integrationsteil ist lesenswert, weil er zeigt, wie viel Arbeit nichts mit Protokolldesign zu tun hatte: Dutzende Werkzeuge pro offiziellem MCP-Server passten nicht dazu, wie Mitarbeiter tatsächlich arbeiten. Es brauchte einen REST-Erweiterungsmechanismus, Sidecar-Prozesse und eine Service-Instanz pro Region. Keines dieser Probleme hat die Ausrollung ausgebremst.
Ausgebremst hat sie die Frage nach dem sicheren Einschalten. Sierra schreibt, dass das Zugriffskontroll- und Audit-System unterhalb des Gateways das Gateway erst möglich gemacht habe, und dass es Rechtsabteilung und Compliance die Sicherheit gab, die Ausrollung auf das ganze Unternehmen zu verantworten. Darum geht es in dem Bericht. Das Gateway war ein Feature. Das Autorisierungsmodell war das Produkt.
„Ein Agent kann nicht missbrauchen, was er nie sieht“ – Berechtigungen pro Werkzeug
Die dritte Lektion ist der stärkste Abschnitt im Text. Sie beginnt mit der richtigen Prämisse: Der sicherste Weg zu verhindern, dass ein Agent mit sensiblen Daten etwas Unerwartetes tut, ist, ihm die Daten gar nicht erst zu geben. Das Schreckensszenario heißt Cross-Customer-Bleed – ein Agent liest die internen Arbeitsanweisungen des einen Kunden und verwendet sie hilfsbereit für einen anderen.
Schwierig war nicht die Trennung selbst. Die Produktivsysteme von Sierra waren längst nach Kundenidentität getrennt. Das Problem des Gateways waren die Grauzonen: Slack-Kanäle, interne Dokumente, spontane Auswertungen, also Quellen, die keine Sensitivitäts- oder Herkunftsmetadaten tragen. Deshalb entstand ein mehrstufiger Klassifikator. Eine deterministische Phase schlägt Kandidatenkunden vor, ein schnelles Modell verengt die Liste, ein langsameres Modell entscheidet, um welchen Kunden es in den Daten geht und wie sensibel sie sind. All das speist ein Audit-Log, das verhindert, dass in einer Sitzung die sensiblen Daten zweier Kunden berührt werden. Zugriffe über Kundengrenzen hinweg bleiben für Incident-Arbeit möglich, aber außerhalb des regulären Weges, ausdrücklich genehmigt und protokolliert.
Der Klassifikator ist echte Eigenarbeit. Aus unstrukturierten internen Daten die Mandantenzugehörigkeit abzuleiten, ist ein Datenklassifikationsproblem, und das verkauft niemand fertig für den eigenen Slack. Alles, was darum herum liegt, ist dagegen Standardausrüstung: Identität, die bis in jeden Werkzeugaufruf reicht, Berechtigungen pro Werkzeug statt pro Server, nach Organisation gefilterte Abfragen und ein Audit-Event bei jedem relevanten Aufruf. In der Praxis sieht das so aus, dass eine Funktion wie getSession() dem Werkzeug die Nutzer-ID, die Organisation, die Rolle und die Berechtigungen übergibt, während ein Aufruf wie workos.auditLogs.createEvent() festhält, was berührt wurde. Ein Demo-Server von Cloudflare sperrt ein einzelnes Werkzeug hinter eine einzelne benannte Berechtigung, die zentral zugewiesen wird – fehlt sie in der Rolle des Aufrufers, verschwindet das Werkzeug sichtbar aus der Liste des Agenten. Das ist der Satz „ein Agent kann nicht missbrauchen, was er nie sieht“, umgesetzt als Rechteprüfung statt als Richtliniendokument.
Dass solche Audit-Events etwas anderes sind als eine Logzeile, hat einen einfachen Grund. Für die Leistungsüberwachung kann man ein Prozent der Anfragen sammeln und den Rest verwerfen. Für eine Wirtschaftsprüferin kann man nicht ein Prozent der Agentenaktionen sammeln. Berechtigungen für KI-Agenten stellen hier andere Anforderungen als die klassische Anwendungsüberwachung.
Eigene Identität für KI-Agenten – und was passiert, wenn niemand anwesend ist
Sierras Faustregel zur Identität lautet: Interaktive Arbeit läuft als der Nutzer, geplante oder geteilte Workflows laufen als Dienstkonten, die ausschließlich die Rechte halten, die sie brauchen. Die Begründung sollte man jedem vorlesen, der Agenten noch mit einem persönlichen API-Schlüssel ausliefert. Eine wiederkehrende Automatisierung, die den breiten Zugriff eines einzelnen Mitarbeiters erbt, bricht entweder, sobald diese Person die Rolle wechselt, oder sie läuft still mit deren alten Rechten weiter. Für Automatisierungen mit Kundenbezug ging Sierra noch weiter und ließ Workflows im Voraus deklarieren, auf welche Kunden und Werkzeuge sie zugreifen dürfen.
Das ist die Spezifikation für Agenten-Identität, die eine Autorisierungsplattform heute abbilden muss. Ein Agent bekommt eine eigene registrierte Identität, statt sich die eines Menschen zu leihen. Man legt fest, ob unbeanspruchte Agenten überhaupt existieren dürfen oder ob sie sich erst an einen Nutzer binden müssen, bevor sie handeln. Ein unbeanspruchter Agent läuft nur lesend, bis ein Mensch für ihn bürgt – dann erst werden volle Rechte freigeschaltet. Wenn jemand bürgt, trägt das zurückgegebene Credential einen act-Claim mit dem Namen der autorisierenden Person. Jeder nachgelagerte Aufruf ist dadurch einem echten Menschen zuordenbar statt einem geteilten Bot-Konto, das man mitten im Incident mühsam zurückverfolgen muss. Das Token selbst enthält sub, org_id und act, sodass die eigene API nie dem Agenten glauben muss, in wessen Namen er unterwegs ist.
Die zweite Hälfte der Regel ist die schwierigere. Ein nächtlicher Job läuft um sechs Uhr morgens, wenn es keine Sitzung gibt, keinen Browser und niemanden, der zustimmen könnte. Das Muster dafür ist ein dauerhaft verbundenes Konto statt einer Sitzung: Die Autorisierung des Nutzers überlebt jeden Login, der Worker zieht sich ein Credential pro Verbindung allein mit einem API-Schlüssel und der Nutzer-ID, für die er handelt, und jeder Abruf erzeugt ein Audit-Event mit actor.type: 'agent'. Den Kompromiss sollte man offen benennen, weil der Bericht das auch tut: Die Scopes dort sind das, was der Anbieter beim Verbinden gewährt hat, nicht das, was eine einzelne Aufgabe braucht. Ist der Drive-Scope weit, liest ein verwirrter Agent weit. Genau diese Lücke schließt sitzungsgebundene Autorisierung – weshalb die beiden Modelle einander ergänzen und nicht ersetzen.
Auch die Discovery-Seite ist inzwischen genormt. Ein unauthentifizierter Aufruf liefert einen WWW-Authenticate-Header, der auf Metadaten der geschützten Ressource zeigt, und die wiederum auf die Metadaten des Autorisierungsservers mit den Endpunkten für Agentenregistrierung und Claims. Dazu gibt es eine generierte auth.md: eine Onboarding-Anleitung, geschrieben für einen Agenten statt für einen Menschen, inklusive der curl-Befehle für die eigene Umgebung.
„Don’t fight the weights“: Warum CLI-Umwege neue Credential-Flächen schaffen
An der sechsten Lektion zeigt sich, wo die Gateway-Abstraktion Risse bekommt, und Sierra benennt das offen. Der vollständige MCP-Server von GitHub ließ Agenten Kontext damit verbrennen, hunderte Werkzeuge zu entdecken, und an großen Antworten ersticken. Also bekamen die Agenten die gh-Kommandozeile, weil die Modelle sie ohnehin kennen. Für AWS fiel dieselbe Entscheidung, dort zugunsten von aws statt eines Proxys.
Der eigentliche Punkt liegt in dem, was danach nötig war. Sierra wollte jeden schreibenden und jeden destruktiven Vorgang an Nutzerintention und Freigabe binden. Der Kompromiss bestand darin, ein separates GitHub-Token zu prägen, begrenzt auf Lesezugriff auf bestimmte Repositories, und es dem Agenten für seine CLI-Aufrufe zu geben. Das ist ein Autorisierungsserver, der eng begrenzte Credentials an ein nicht-menschliches Subjekt ausgibt – und die Kontrollen landen zwangsläufig dort, wo der Proxy nicht mehr hinkommt.
Die vierte Lektion drückt in dieselbe Richtung. 80 Prozent eines Workflows runden auf 0 Prozent des Nutzens herunter, deshalb musste das Gateway über REST-Erweiterungen, Sidecars und regionale Instanzen auf 100 Prozent Abdeckung kommen. Jede dieser Notluken ist eine zusätzliche Credential-Fläche, und jede selbst gebaute Erweiterung ist ein neuer Ort, an dem ein langlebiges Secret enden kann. Wer MCP-Server-Sicherheit nur am Gateway selbst verankert, übersieht genau diese Stellen.
Was das konkret bedeutet: Die unter Wasser liegende Hälfte einkaufen
Es gibt einen wachsenden Markt für MCP-Gateway-Produkte, und das Versprechen ist meistens Konsolidierung: eine Stelle, an der Agenten mit allem verbunden werden. Der Sierra-Bericht zeigt, dass Konsolidierung die leichte Hälfte ist. Die schwere Hälfte ist eine Liste, die jedes Identity-Team in einem Unternehmen wiedererkennt.
| Was Sierra gebaut hat | Die dahinterliegende Primitive |
|---|---|
| Ein Agent kann nicht missbrauchen, was er nie sieht | Berechtigungen pro Werkzeug und organisationsgefilterte Abfragen, damit Identität jeden Aufruf erreicht |
| Mehrstufiger Audit von Kundendatenzugriffen | Audit-Events bei jedem relevanten Werkzeugaufruf |
| Ausnahmen mit Genehmigung außerhalb des regulären Weges | Sitzungsgebundene Autorisierung: zeitlich begrenzt, nicht erneuerbar, menschlich genehmigt |
| Interaktive Arbeit läuft als der Nutzer | Agenten-Credentials mit act-Claim zurück auf die autorisierende Person |
| Geplante Arbeit läuft als Dienstkonto mit minimalen Rechten | Registrierte Agentenidentitäten oder dauerhaft verbundene Konten, wenn es keine Sitzung gibt |
| Vorautorisierte Workflows deklarieren ihre Reichweite | Benannte, zentral zugewiesene Berechtigungen, pro Werkzeug geprüft |
| Agenten kommen aus beliebigen Clients | Client ID Metadata Documents, damit sich Clients ohne Handarbeit registrieren |
Die letzte Zeile stand früher für Dynamic Client Registration. Warum nicht mehr: Die MCP-Spezifikation in der Fassung vom 28. Juli 2026 hat DCR zugunsten von Client ID Metadata Documents abgekündigt und behält DCR nur aus Rückwärtskompatibilität bei. Eine CIMD-Client-ID ist eine selbst gehostete HTTPS-URL, die jeder Autorisierungsserver auflösen kann – DCR-Credentials dagegen sind an den Server gebunden, der sie ausgegeben hat. Wer im dritten Quartal 2026 die Client-Identitätsschicht eines Gateways baut, sollte die Variante wählen, in deren Richtung sich die Spezifikation bewegt.
Sierra hatte recht, ein Gateway zu bauen statt sieben, und recht mit der Annahme, dass Rechtevergabe, Audit und rechtliche Prüfung einmal passieren sollten statt einmal pro Team. Offen bleibt, wie groß dieses „einmal“ ist. Sierra hat es einmal für Sierra gelöst. Der Rest der Branche löst es parallel, pro Unternehmen, von vorn – und dort entsteht der Aufwand, der in keinem Demo-Video sichtbar ist. Am Ende des Berichts ist das Gateway Plumbing geworden, und die Komplexität bleibt unter der Wasserlinie, solange man nicht selbst der ist, der sie baut. Das gilt für die Authentifizierung genauso. Während einer Störung will niemand über Token-Austausch nachdenken. Der Unterschied liegt darin, wer die Rohre wartet.
Für die Praxis heißt das: Wer heute eine MCP-Gateway-Authentifizierung für Unternehmen plant, sollte nicht bei den Konnektoren anfangen, sondern bei Identität, Scopes, Consent und Audit. Konnektoren lassen sich nachreichen. Ein Autorisierungsmodell, das man nachträglich unter eine gewachsene Agentenlandschaft schiebt, ist ungleich teurer. Und die unter Wasser liegende Hälfte muss man nicht selbst gießen – man kann sie einkaufen und sich auf das konzentrieren, was wirklich nur das eigene Haus weiß: welche Daten im eigenen Slack welche Kunden betreffen.
Quelle: workos.com
