Die neue MCP-Roadmap benennt eine unbequeme Praxis: Bestehende MCP-Server stützen sich auf eingefügte API-Schlüssel und langlebige Refresh-Token.[1] Die Kernbetreuer David Soria Parra und Den Delimarsky veröffentlichten das Papier am 22. August 2026. Ursache ist die Bauweise des Protokolls, denn dessen Anmeldeverfahren setzt einen Menschen vor einem Browser voraus.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Das Wichtigste in Kürze
- Die MCP-Roadmap vom 22. August 2026 setzt fünf Schwerpunkte für die kommenden sechs bis zwölf Monate.
- Als Schwachstelle benennen die Kernbetreuer eingefügte API-Schlüssel und langlebige Refresh-Token in bestehenden Servern.
- Als Gegenmittel gelten Demonstrating Proof of Possession nach RFC 9449 sowie eine föderierte Identität für Agenten-Workloads.
- Die Arbeitsgruppe für Agenten-Identität bildet sich erst; ein zentraler Baustein liegt bislang nur als IETF-Entwurf vor.
Warum reicht die bisherige MCP-Anmeldung nicht?
Das Anmeldeverfahren von MCP verlangt eine Zustimmung im Browser, die ein KI-Agent ohne Nutzer davor nicht einholen kann. MCP verbindet KI-Anwendungen mit fremden Datenquellen und Werkzeugen. Ein Agent läuft dabei als Cloud-Last mit eigener Identität, oft für einen Menschen, der gerade nicht am Rechner sitzt. Hinzu kommt, dass ein Hauptagent engere Rechte an seine Unteragenten weiterreicht. Für beide Muster bietet die Spezifikation bisher keinen Weg, weshalb Betreiber zum langlebigen Token greifen.[2]
Ein Inhaber-Token verschafft jedem Zugriff, der ihn vorlegt; aus einer Protokolldatei oder einem gekaperten Dienst abgegriffen, dient er einem Angreifer genauso wie dem rechtmäßigen Client. Demonstrating Proof of Possession bindet den Token dagegen an ein Schlüsselpaar des Clients und macht den Gebrauch durch Dritte erkennbar. Die IETF verabschiedete das Verfahren bereits im September 2023 als RFC 9449.[3] Welchen Schaden gültige Freigaben ohne diese Bindung anrichten, zeigte der Diebstahl von Salesforce-Daten ohne eine einzige Sicherheitslücke.
Wie weit ist die Absicherung im Unternehmenseinsatz?
Für angemeldete Beschäftigte existiert die Lösung bereits, für den Agenten ohne Mensch dahinter nicht. Seit dem 18. Juni 2026 gilt die Erweiterung Enterprise-Managed Authorization als stabil: Der Client holt beim Single Sign-on ein Identity Assertion JWT Authorization Grant vom Identitätsanbieter und tauscht dieses beim Autorisierungsserver des MCP-Servers gegen ein Zugriffstoken.[4] Okta ist der erste unterstützte Identitätsanbieter, Anthropic und Microsoft haben die Erweiterung in ihre Clients eingebaut.
Der entscheidende Baustein ist allerdings noch keine Norm. Der Entwurf des Identity Assertion JWT Authorization Grant liegt bei der IETF-Arbeitsgruppe OAuth in Fassung 04 vom 21. Mai 2026 vor und läuft am 22. November 2026 ab.[5] Die Arbeitsgruppe für Agenten-Identität bildet sich innerhalb dieses Roadmap-Zeitraums überhaupt erst.[2] Denselben Weg ging das Protokoll schon beim Transport: Seit der Spezifikation vom 28. Juli 2026 verhält sich ein entfernter MCP-Server wie eine gewöhnliche HTTP-Last.
Zahlen zum Umfeld
Ein eingefügter API-Schlüssel ist ein Generalschlüssel mit unbegrenzter Laufzeit. Solange MCP-Server damit auskommen müssen, hängt das Risiko an der Sorgfalt des einzelnen Betreibers.
— Michael Dobler, Herausgeber Dr. Web
Was sollten Unternehmen im DACH-Raum jetzt prüfen?
Die Haftung für ein abgeflossenes Agenten-Token liegt beim Betreiber, nicht beim Protokoll. Artikel 32 DSGVO verpflichtet Verantwortliche auf den Stand der Technik; sobald ein an ein Schlüsselpaar gebundenes Token breit verfügbar ist, verschiebt sich dieser Maßstab. Das BSI weist auf seiner Seite zu NIS-2-regulierten Unternehmen zudem darauf hin, dass die gesetzliche Registrierungsfrist nach Paragraf 33 Absatz 6 BSIG bereits abgelaufen ist.[6]
Zwei Prüffragen lohnen vor dem nächsten Anschluss eines MCP-Servers: Welche Token gibt der eigene Dienst aus? Lässt sich ein einzelnes davon zurückziehen? Hinzu kommt der Werkzeugkatalog, denn ein Server mit hundert Werkzeugen kostet das Modell schon Kontext, bevor der Nutzer die erste Frage stellt.[1] Wie schnell solche Anschlüsse im Alltag entstehen, zeigt der Notizdienst Granola mit seinen Meeting-Protokollen.
FAQ: MCP-Roadmap und die Identität von KI-Agenten
Was ist das Model Context Protocol?
Das Model Context Protocol, kurz MCP, ist ein offener Standard, über den KI-Anwendungen auf fremde Datenquellen und Werkzeuge zugreifen. Statt für jede Anwendung eine eigene Anbindung zu bauen, stellt ein Anbieter einen MCP-Server bereit, den jeder unterstützte Client anspricht. Anthropic hat das Protokoll im November 2024 veröffentlicht.
Was bedeutet Demonstrating Proof of Possession?
Demonstrating Proof of Possession, kurz DPoP, bindet ein OAuth-Zugriffstoken an ein Schlüsselpaar des Clients. Der Client muss bei jeder Anfrage nachweisen, dass er den privaten Schlüssel besitzt, sodass ein gestohlenes Token allein nichts nützt. Die IETF hat das Verfahren im September 2023 als RFC 9449 im Standards Track verabschiedet.
Unter welchem Dach wird MCP weiterentwickelt?
Die Kernbetreuer gemeinsam mit den Arbeitsgruppen, geleitet vom Vorschlagsverfahren SEP. Seit dem 9. Dezember 2025 liegt das Projekt bei der Agentic AI Foundation, einem gebundenen Fonds unter dem Dach der Linux Foundation. Die technische Richtung bleibt bei den Betreuern, die Stiftung liefert den neutralen Rahmen.
Was ist Enterprise-Managed Authorization?
Eine seit dem 18. Juni 2026 stabile MCP-Erweiterung, mit der eine Organisation den Zugriff auf MCP-Server zentral über ihren Identitätsanbieter vergibt. Beschäftigte geben dann nicht mehr jeden Server einzeln frei; die Zugriffsentscheidung fällt anhand von Gruppen und Rollen im Identitätsanbieter.
Wann erscheint die nächste MCP-Spezifikation?
Die Roadmap nennt kein Datum, sondern einen Zeitraum von sechs bis zwölf Monaten. Die Vorhaben verteilen sich auf die nächste Spezifikation und die Zeit danach. Die bislang letzte Fassung stammt vom 28. Juli 2026.
Quellen
[1] Model Context Protocol Blog: „The New MCP Roadmap“ vom 22. August 2026
[2] Model Context Protocol: Roadmap, Schwerpunkt „Agent Identity and Enterprise-Ready Security“
[3] IETF: RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP)
[4] Model Context Protocol Blog: „Enterprise-Managed Authorization: Zero-touch OAuth for MCP“ vom 18. Juni 2026
[5] IETF: draft-ietf-oauth-identity-assertion-authz-grant-04 (Identity Assertion JWT Authorization Grant)
[6] Bundesamt für Sicherheit in der Informationstechnik: NIS-2-regulierte Unternehmen
Mehr Newshunger?
- Agent Plugins: OpenAI, Microsoft und Amazon einigen sich auf ein Format für KI-Agenten
- Die Zukunft der Website: vom Schaufenster zum MCP-Server für Agenten
- KI-Agenten brauchen einen Notausgang für den Ernstfall
- Atlassian Rovo: Eine versteckte Anweisung genügt für den Datenabfluss aus Jira und Confluence
- Blinder Fleck KI-Agent: Fortinet kauft den Sicherheitsanbieter Virtue AI
- KI-Agenten erledigen die Aufgabe, aber nicht den Job
