Was der stateless Core und die Managed Auth von MCP für Integrationsteams bedeuten
Die Governance der Linux Foundation, der stateless HTTP-Transport sowie die von Identitätsanbietern verwaltete Autorisierung machen MCP für Unternehmensintegrationen geeignet. Hier sind die Änderungen.
Das Model Context Protocol standardisiert die Art und Weise, wie KI-Agenten auf die umgebenden Systeme zugreifen, ähnlich wie APIs einst standardisierten, wie Anwendungen miteinander kommunizieren konnten. Für Fachleute im Bereich Integration und IT-Operationen war es in den letzten zwei Jahren etwas, das man aus der Ferne beobachtete: vielversprechend, immer weiter an Bedeutung gewinnend – und eher wie Entwicklerwerkzeuge denn als etwas, das ein Architekturbeirat genehmigen würde. Diese Distanz hat sich verringert. In acht Monaten hat MCP drei Meilensteine überschritten, die insgesamt an die Anfänge der API-Verwaltung um das Jahr 2010 erinnern und sich nun für KI-Agenten wiederholen.
Drei Veränderungen in acht Monaten
Neutraler Governance-Ansatz. Anthropic übergab MCP im Dezember 2025 an die Agentic AI Foundation. Es handelt sich um einen geförderten Fonds innerhalb der Linux Foundation, der von Anthropic, Block und OpenAI ins Leben gerufen wurde und von Google, Microsoft, AWS, Cloudflare sowie Bloomberg unterstützt wird. Dadurch folgt MCP nicht mehr den Plänen eines einzelnen Anbieters, sondern unterliegt einer unparteiischen Verwaltung, wie sie bereits Kubernetes und Node.js kennengelernt haben.
Zentralisierte Autorisierung. Am 18. Juni 2026 erreichte die Erweiterung Enterprise-Managed Authorization (EMA) Stabilität. Sie ersetzt die einzelnen Server-basierten Zustimmungsschirme durch ein vom Identitätsanbieter gesteuertes Modell, wobei Anthropic, Microsoft und Okta zu den ersten Adoptierern gehörten.
Ein zustandsloser Kern. Die Veröffentlichung vom 28. Juli 2026 stellte die größte Spezifikationsänderung seit Erscheinen des Protokolls dar und ersetzt ein zustandsbasiertes, sessionsgebundenes Design durch eines, das auf reinem HTTP basiert.
Es handelt sich dabei nicht um kosmetische Änderungen. Jede dieser Änderungen beseitigt einen bestimmten Grund, warum MCP bisher nicht in ernsthaften Produktionsumgebungen eingesetzt wurde, und sie sind besonders wichtig für diejenigen, die ihren Beruf darin sehen, Systeme miteinander zu verbinden, anstatt nur KI-Demos zu entwickeln.
Kurze Definition
MCP ist ein offener Standard dafür, wie eine KI-Anwendung – beispielsweise ein auf LLMs basierender Agent – externe Tools findet und aufruft, externe Ressourcen liest sowie mit Systemen außerhalb des Modells Kontext austauscht. Eine einheitliche Schnittstelle ersetzt die notwendige individuelle Integration für jede Datenquelle.
Eine grobe Vergleich: MCP übernimmt für Verbindungen von KI zu Systemen die Rolle, die REST und OpenAPI einst zwischen Anwendungen einnahmen. Die integrierten Systeme bleiben unverändert. Standardisiert wird lediglich der Vertrag zwischen dem KI-Client und dem, was der MCP-Server bereitstellt – sei es ein Ticketsystem, eine CMDB, eine Überwachungsplattform oder eine interne Datenbank.
Änderung 1: Keine Sessions mehr
In seinen ersten zwei Jahren funktionierte MCP über HTTP wie viele Echtzeitprotokolle. Ein Client verband sich, führte eine Initialisierungsabfrage durch und erhielt eine Session-ID, die in jeder nachfolgenden Anfrage enthalten sein musste. Die Session band den Client an diejenige Serverinstanz, die sie erstellt hatte. Jeder, der bereits einen WebSocket-Service hinter einem Load Balancer betrieben hat, kennt die damit verbundenen Herausforderungen. Für eine Skalierung war sticky Routing, ein gemeinsamer Session-Speicher oder ein Gateway erforderlich, das den Datenverkehr prüfte, um die Instanz zu finden, die die Verbindung hielt.
Die Spezifikation vom 28.07.2026 beseitigt all das. Es gibt weder ein Initialisierungs- noch ein Initialisiert-Handshake sowie keinen Mcp-Session-Id-Header. Stattdessen enthält jede Anfrage ihre eigene Protokollversion, Klientenidentität und Fähigkeiten. Infolgedessen kann jede Serverinstanz auf jede Anfrage antworten, wodurch sticky Sessions und gemeinsame Session-Speicher nicht mehr von dem Protokoll gefordert werden. Serverlose, mehrinstanzige Clustern sowie Edge-Routing funktionieren daher genauso wie bei herkömmlichen HTTP-APIs, denn strukturell ist das genau das, was aus MCP geworden ist.
Ohne Protokollsessionen werden Anwendungen nicht zustandslos. Wenn ein Server tatsächlich etwas zwischen den Aufrufen speichern muss, wie beispielsweise einen laufenden Export oder eine umfangreiche Behebungsaktion, folgt er der alten REST-Praxis: Er erstellt eine explizite Kennung, die der Client beim nächsten Mal als gewöhnliches Argument zurückgibt. Ingenieure, die mit Paginierung und Endpunkten für Job-Status vertraut sind, werden dies erkennen – es handelt sich dabei um eine überlegte Entscheidung, die sich gut für Load Balancer eignet, und nicht um einen Patch.
Die gleiche Version hat die Sicherheit im Zusammenhang mit der neuen Struktur verschärft. Kunden müssen den Aussteller in den Autorisierungsantworten überprüfen, was ein Session-Hijacking über mehrere Server verhindert. Zudem müssen sie angeben, für welchen Server ein Token bestimmt ist, wodurch eine Delegationslücke geschlossen wird, die Sicherheitsteams in multi-tenantigen Umgebungen als echtes Risiko eingestuft hatten. Außerdem verfügt MCP nun erstmals über eine formelle Veraltungsrichtlinie, sodass brisante Änderungen einem echten Lebenszyklus folgen und nicht willkürlich entfernt werden.
Änderung 2: Zugriff durch den Identitätsanbieter gesteuert
Die zweite Änderung betrifft weniger den Transport als vielmehr die täglichen Herausforderungen bei der Bereitstellung von Agenten in einem Unternehmen. Bei dem Ansatz der ersten Generation musste jeder Mitarbeiter für jeden MCP-Server, den sein KI-Klient nutzte, eigenständig einen OAuth-Zustimmungsschritt durchführen. Bei hundert Mitarbeitern und sechs oder sieben internen Tools wird die Einrichtung nicht mehr skalierbar. Zudem verlieren die Sicherheitsteams eine zentrale Übersicht darüber, wer mit was verbunden ist, und es gibt keine einfache Möglichkeit, Zugriffe zu sperren, wenn jemand wechselt oder das Unternehmen verlässt.
Die EMA überträgt die Entscheidung zur Autorisierung an den Identitätsanbieter des Unternehmens. Ein Administrator legt einmal im IdP fest, welche MCP-Server eine Gruppe von Mitarbeitern nutzen darf. Später wird der Zugriff beim ersten Mal, wenn eine Person über einen unterstützten Client einloggt, automatisch gewährt – ohne weitere Zustimmungsanfragen oder Einrichtungen.
Okta war der erste unter den Identitätsanbietern, der dies unterstützte, wobei es sein Produkt Cross App Access als Grundlage nutzte. Die Erweiterung basiert auf der Identity Assertion JWT Authorization Grant, einer offenen IETF-Spezifikation, die nicht ausschließlich von Anthropic stammt. Anthropic integrierte sie in Claude, Claude Code und Cowork über eine gemeinsame MCP-Schicht, während Microsoft die Unterstützung direkt in Visual Studio Code einbaute. Zu den Servern, die dies bereits unterstützen, gehören Asana, Atlassian, Canva, Figma, Granola, Linear und Supabase – und die Liste wächst weiter.
Sobald der Identitätsanbieter die Autorisierungsstimmung ausgestellt hat, ist seine Aufgabe erledigt. Dieser Vorgang findet nicht im Toolaufruf selbst statt – ein Aspekt, der bei Sicherheitsüberprüfungen von Bedeutung ist: Der IdP leitet nicht jeden Datenfluss von KI zu Systemen weiter und entscheidet lediglich, wer Zugangsdaten erhält. Da der Zugriff zentralisiert ist, gilt das auch für die Widerrufung. Das Deaktivieren des Kontos einer Person beendet sofort den Zugriff auf alle mit EMA verbundenen Servern, sodass niemand sieben separate Integrationen manuell zurückrufen und widerrufen muss.
Auch der Single Sign-On für das SaaS-Ökosystem eines Unternehmens funktioniert auf dieselbe Weise, was dieses Konzept vertraut erscheinen lässt – und das ist beabsichtigt. Die Sicherheitsteams müssen kein neues Governance-Modell für Agenten entwickeln; sie nutzen einfach das bereits vorhandene.
Was dies für Teams mit benutzerdefinierten Schnittstellen bedeutet
Viele Integrationsteams und Plattformteams warteten nicht ab, bis MCP ausgereift war. Als sie gebeten wurden, einem internen KI-Assistenten die Möglichkeit zu geben, Jira zu lesen, in Slack zu posten oder ein Überwachungstool abzufragen, schrieben sie ihren eigenen „Glue Code“: einen maßgeschneiderten Wrapper für jede API, einen selbst entwickelten Authentifizierungsablauf sowie manuelle Sitzungsbearbeitung, da es keine Standardlösungen gab. Das funktionierte zwar, doch jedes neue Tool wurde zu einer separaten Einzelanfertigung, die Authentifizierung musste für jedes System neu entwickelt werden, und dieser Ansatz brach zusammen, sobald ein weiteres Team dieselbe Funktionalität haben wollte.
Die neu erreichte Reife adressiert dieses Problem auf drei Arten:
- Weniger manuell erstellte Komponenten pro Integration. Ein stabiler, zustandsloser Transport über reines HTTP bedeutet, dass Teams aufhören müssen, ihre eigene Verbindungsverwaltung zu schreiben, und einen MCP-Server wie jede andere REST-API hinter einer API-Gateway-Plattform verwalten können.
Die Integration selbst verschwindet nicht. Der Datentransfer zwischen einem Ticketing-Schema und einem Monitoring-Schema sowie die Transformation auf Feldebene, die Entduplizierung und die über Systeme hinweg wirkende Geschäftslogik erfordern weiterhin echten Ingenieursaufwand – unabhängig davon, welches Protokoll die Anfragen überträgt. Was abnimmt, sind die dazugehörigen Infrastrukturelemente: der Transport, die Sitzungsbearbeitung und der Authentifizierungsablauf. Dadurch entfällt ein erheblicher Teil der ununterschiedlichen Arbeit, allerdings nicht die gesamte Aufgabe.
Eine alte Geschichte mit neuem Etikett
Wenn man die KI-Aspekte beiseite lässt, handelt es sich um etwas Vertrautes. Seit etwa zwei Jahrzehnten entwickeln und kaufen Unternehmen Integrationssysteme, um die Infrastruktur für API-zu-API-Verbindungen zu bereitstellen: standardisierte Authentifizierung, zentral gesteuertes Datenmapping und -transformieren, ein wachsendes Transaktionsvolumen ohne speziellen Code für jedes neue Systempaar sowie einen Ort, an dem Sicherheitsteams sehen und kontrollieren können, was verbunden ist.
MCP scheint denselben Ansatz für Verbindungen zu KI-Agenten zu verfolgen, nur schneller. Ein zustandsloser Kern über reines HTTP ermöglicht es einem MCP-Server, sich wie jeder andere Backend-Dienst zu verhalten und skalieren zu lassen. Die durch den IdP gesteuerte Autorisierung macht die Gewährung sowie Überwachung des Zugangs zu KI-Tools zu einer alltäglichen Aufgabe im Bereich der Unternehmenszugriffskontrolle. Zudem sorgt die neutrale Verwaltung durch die Linux Foundation dafür, dass die Adaption des Protokolls eher der Wahl von Kubernetes ähnelt als dem Roadmap eines einzelnen Unternehmens.
Für Integrationsteams bedeutet das nicht, dass Agenten ein völlig neues Vorgehensmodell erfordern. Die bereits vorhandenen Methoden zur zuverlässigen, sicheren und skalierbaren Verbindung von Systemen gelten nun auch direkt für Agenten. Die Protokollschicht integriert sich in die Infrastruktur, die die Mitarbeiter bereits kennen, und was Teams unterscheidet, liegt auf höherer Ebene – bei der Datenkartei, der Durchsetzung von Richtlinien sowie dem Change Management in allen Systemen beider Endpunkte, was stets der schwierigere Teil war.