Die Spezifikation des Model Context Protocol führt Enterprise-Managed Authorization als stabilen Bestandteil. Unternehmen können damit den Zugriff auf MCP-Server zentral über ihren Identity Provider steuern, statt jede Anwendung und jeden Nutzer durch einen eigenen Zustimmungsprozess zu schicken. Das Verfahren soll vor allem zwei betriebliche Probleme lösen: einheitliche Richtlinien für freigegebene Server und nachvollziehbare Identitäten für Zugriffe im Unternehmenskontext.
Die Szene beschreibt das Problem, das die MCP-Community jetzt mit einer Erweiterung des Protokolls angeht. Enterprise-Managed Authorization, kurz EMA, ist vom Vorschlag zur stabilen Erweiterung geworden. Der Ansatz verschiebt die Entscheidung darüber, wer welchen MCP-Server nutzen darf, dorthin, wo Unternehmen ihre Zugriffe ohnehin verwalten: in den Identity Provider.
Ein Vergleich macht den Unterschied greifbar. Bisher bekam jeder Mitarbeiter an jeder Tür einen eigenen Schlüssel, und niemand führte zentral Buch darüber, wer welchen besitzt. Mit EMA gibt es eine zentrale Schließanlage: Der Ausweis wird einmal am Eingang geprüft, und der Pförtner stellt ein Berechtigungspapier aus, das an jeder Tür gegen den passenden Schlüssel getauscht wird.
Warum die klassische MCP-Autorisierung pro Nutzer gedacht ist
Das ursprüngliche Autorisierungsmodell von MCP ist an den Nutzer gebunden und folgt den üblichen interaktiven Konventionen von OAuth. Der Nutzer entscheidet, welche Anwendung auf seine Daten zugreifen darf, und bestätigt das in einem Consent-Dialog. Für Consumer-Szenarien passt das: Wer seine persönlichen Notizen mit einem Assistenten verbindet, soll gefragt werden.
Im Unternehmen funktioniert diese Logik nicht mehr. Jeder Mitarbeiter muss jeden Server einzeln autorisieren, Onboarding besteht aus einer Kette manueller Klicks. Das Sicherheitsteam kann keine einheitliche Policy durchsetzen, weil der Zugriff schlicht das ist, was jeder Einzelne irgendwann angeklickt hat. Und weil keine zentrale Instanz eine Firmenidentität erzwingt, verschwimmen berufliche und private Konten.
Die Werkzeuge und Daten sind da, aber der Aufwand pro Nutzer hält die meisten davon ausgeschaltet. Wo kein gemeinsamer Standard für geteilten Authentifizierungszustand existiert, baut sich jeder sein eigenes Provisorium. Diese Basteleien fallen später beim Audit auf.
Was die Enterprise-Managed Authorization technisch anders macht
EMA macht den Identity Provider zur autoritativen Instanz für den Zugriff auf MCP-Server. Administratoren definieren die Policy einmal, Nutzer authentifizieren sich mit ihrer bestehenden Identität am MCP-Host. Der IdP entscheidet anhand von Gruppenmitgliedschaft, Rolle und Conditional-Access-Regeln, ob ein Server freigegeben wird. Faktoren wie Gerätekonformität, Standort oder abgeschlossene Mehrfaktor-Anmeldung fließen automatisch mit ein, ohne dass der einzelne Server davon etwas wissen muss.
Unter der Haube läuft ein Token-Tausch in zwei Schritten. Beim Single Sign-on stellt der Identity Provider dem Client ein Identity Assertion JWT Authorization Grant aus, kurz ID-JAG. Ein JWT ist ein signiertes, kompaktes Datenpaket, das der IdP unterschreibt; ein Grant ist die Erlaubnis, damit weiterzureichen. Der Client tauscht dieses Paket anschließend beim Autorisierungsserver des jeweiligen MCP-Servers gegen ein Access Token ein.
Entscheidend ist, was dabei nicht passiert: Der Nutzer wird nie durch einen serverspezifischen Consent-Screen geschickt. Er sieht kein Fenster, in dem er für Asana, Figma und Linear nacheinander auf Zulassen klicken muss. Die Zustimmung ist vorab organisatorisch erteilt worden, technisch nachweisbar über eine signierte Aussage des IdP. OAuth ohne per-App-Consent ist damit keine Ausnahme, sondern eine Verlagerung der Entscheidung.
Drei Eigenschaften des Flows
Daraus folgen drei Eigenschaften, die man getrennt betrachten sollte. Die erste ist die Vererbung: Ein Administrator gibt einen Server für die Organisation frei, und Nutzer erhalten ihn automatisch, zugeschnitten auf die Gruppen und Rollen, die sie ohnehin haben. Zentrale Autorisierung spart damit nicht nur Klicks, sie ist die Voraussetzung dafür, dass die Zahl der Server überhaupt skalieren kann.
Die zweite Eigenschaft ist die Zusammenführung von Policy und Audit. Zugriffsentscheidungen leben im Admin-Panel des Identity Providers, und über alle Connectoren hinweg entsteht ein zusammenhängender, prüfbarer Pfad. Wer im Audit erklären muss, weshalb ein Werkzeugzugriff möglich war, schaut in einem System nach statt in acht.
Die dritte Eigenschaft betrifft die Trennung von privat und beruflich. Weil die interaktive Kontoauswahl wegfällt, lässt sich leichter verhindern, dass Daten zwischen privaten und betrieblichen Konten fließen. Das klingt nach einem Detail. In der Praxis führt genau diese Vermischung regelmäßig zu Vorfällen.
Wer die Erweiterung bereits implementiert hat
Der Launch kam aus drei Richtungen gleichzeitig. Auf Seiten der Identity Provider ist Okta der erste unterstützte Anbieter; Organisationen können MCP-Zugriffe über Okta Cross App Access bereitstellen, ein Protokoll, das Identitätsaussagen zwischen Anwendungen austauschbar macht. Weitere IdPs dürften folgen.
Auf Client-Seite hat Anthropic die Erweiterung in der gemeinsamen MCP-Schicht für Claude umgesetzt, sodass Administratoren MCP-Server über Claude, Claude Code und Cowork hinweg freigeben können. Auch Visual Studio Code unterstützt EMA direkt in der IDE. Auf Serverseite nennen die Verantwortlichen Asana, Atlassian, Canva, Figma, Granola, Linear und Supabase; Slack ist nach eigenen Angaben in Umsetzung.
Aaron Parecki, Director of Identity Standards bei Okta, argumentiert, man mache Identität zu einer zentralen Governance-Ebene und gebe Sicherheitsteams strikte Compliance-Kontrolle bei einer gleichzeitig reibungslosen Erfahrung für Nutzer. Devdatta Akhawe von Figma betont, mit Cross App Access ließen sich MCP-Deployments sicher skalieren, ohne Teams auszubremsen. Tom Moor von Linear sagt: Einmal einloggen und alle Connectoren automatisch eingerichtet vorzufinden, fühle sich fast magisch an.
Wo die Grenzen des Ansatzes liegen
Zwei Dinge bleiben trotzdem offen. Erstens wandert die gesamte Autorisierung auf den Identity Provider, und damit dessen Ausfallrisiko. Fällt der IdP aus oder ist er falsch konfiguriert, betrifft das nicht mehr ein System, sondern sämtliche MCP-Zugriffe gleichzeitig. Ein Fehler im Admin-Panel skaliert sofort auf die ganze Belegschaft.
Zweitens ist EMA eine Erweiterung, kein Kernbestandteil des Protokolls. In der Praxis heißt das: eine Kompatibilitätsmatrix, die gepflegt werden muss. Nicht jeder Server unterstützt den Flow, nicht jeder Client, nicht jeder IdP. Und die Qualität des Audit-Trails hängt an der Gruppenhygiene im Verzeichnis. Wer seit Jahren gewachsene, überlappende Gruppen mitschleppt, exportiert dieses Chaos in die neue Welt.
Hinzu kommt: Zentrale Freigabe bedeutet nicht automatisch minimale Rechte. Ein Administrator kann einen Server für alle freigeben, ohne dass die Scopes sauber geschnitten sind. Die Erweiterung nimmt dir die Consent-Klickerei ab, nicht die Denkarbeit über Berechtigungsgranularität.
Was das konkret bedeutet
Für die meisten Unternehmen verschiebt sich der Aufwand an eine andere Stelle im Prozess. Statt Onboarding-Dokumente mit Screenshot-Anleitungen zu pflegen, pflegst du Gruppen, Rollen und Conditional-Access-Regeln. Das ist weniger sichtbar, aber belastbarer, weil es einmal definiert und dann konsistent angewendet wird.
Für Anbieter von MCP-Servern verschiebt sich die erste Frage im Enterprise-Vertrieb. Kunden werden wissen wollen, ob der Zugriff über den eigenen Identity Provider läuft, bevor sie über Features sprechen. Wer das nicht beantworten kann, verkauft an dieser Zielgruppe vorbei.
Und für alle, die MCP im Betrieb einführen, gilt eine Reihenfolge: erst Identity Provider und Verzeichnisstruktur in Ordnung bringen, dann Server freigeben. Die Technik ist da. Wer welche Rechte hat, legst du weiterhin selbst fest.
Quelle: blog.modelcontextprotocol.io
