MCP hat eine stabile Spezifikation für „Enterprise-Managed Authorization“ veröffentlicht; die anderen Entwürfe für die Machine-to-Machine-Identität – einschließlich eines OAuth-Client-Credentials-Entwurfs und zweier offener Vorschläge – sind noch unvollständig. Für alle, die versuchen, autonome Agenten mit dem Model Context Protocol auszuführen, bedeutet dies, dass das heutige Protokoll zwar einen menschlichen Benutzer verifizieren kann, aber keine sofort einsatzbereite Möglichkeit bietet, zu beweisen, dass ein unüberwachter Prozess tatsächlich derjenige ist, der er vorgibt zu sein.

Warum die Roadmap wichtig ist

Die Roadmap des Model Context Protocol (MCP) führt Agenten-Identität und Sicherheit als oberste Prioritäten auf. Vier Punkte waren für die Veröffentlichung vorgesehen: ein menschenzentrierter Browser-Flow, ein OAuth-Client-Credentials-Flow für Dienste, ein DPoP-basiertes Token-Binding und ein Mechanismus zur Workload-Identity-Federation. Nur der erste – Enterprise-Managed Authorization – hat den stabilen Status erreicht.

Was die stabile Spezifikation tatsächlich bewirkt

Enterprise-Managed Authorization ermöglicht es IT-Administratoren, den Serverzugriff über eine einzige Konsole zu gewähren, anstatt dass jeder Mitarbeiter jede Verbindung einzeln genehmigen muss. Der Flow nutzt eine Browser-Weiterleitung und einen Benutzer-Login, sodass eine Person an einem Laptop sich authentifizieren kann und der Server anschließend der Sitzung dieses Benutzers vertraut.

Die Einschränkung ist offensichtlich: Der Prozess benötigt einen Menschen an der Tastatur. Ein Agent, der über Nacht läuft, Daten verarbeitet oder auf Alarme reagiert, hat niemanden, der einen Login-Button anklicken kann. Folglich kann jede Bereitstellung, die von unüberwachten Agenten abhängt, nicht die einzige Spezifikation nutzen, die MCP derzeit garantiert.

Die Entwurfsoptionen und ihre Nachteile

Zwei Entwurfs-Erweiterungen zielen darauf ab, Agenten eine eigene Identität zu geben:

  • SEP-1932 (DPoP) – bindet Token an ein Public-Private-Key-Paar, wodurch gestohlene Token nutzlos werden.
  • SEP-1933 (Workload Identity Federation) – ermöglicht es Agenten, Identitäten zu übernehmen, die bereits in Cloud-Plattformen bereitgestellt wurden.

Beide existieren als offene Pull Requests; keiner wurde in die offizielle Spezifikation übernommen. In der Zwischenzeit ist die einzige andere dokumentierte Option ein OAuth-Client-Credentials-Flow, der vorregistrierte Secrets erfordert. Das Speichern dieser Secrets an einem Ort, an dem ein Agent sie lesen kann, schafft eine klassische Angriffsfläche: Wenn das Secret durchsickert, kann jeder Angreifer den Agenten imitieren.

Praktische Schritte für den heutigen Produktivbetrieb

Da das Protokoll noch keine native Agenten-Identität bietet, können Teams Agenten dennoch absichern, indem sie das Identitätsmanagement außerhalb von MCP verlagern:

  1. Verifizierbare Identitäten auf der Workload-Ebene ausstellen. Systeme wie SPIRE generieren kurzlebige Zertifikate, die an die Trust Root des Hosts gebunden sind, wodurch statische Secrets eliminiert werden.
  2. Anmeldedaten an einem Gateway terminieren. Ein Front-End-Service hält den API-Key oder das Token und leitet Anfragen im Namen des Agenten weiter, wodurch das Secret aus der Laufzeitumgebung ferngehalten wird.
  3. Autorisierung basierend auf der verifizierten Identität, nicht auf dem Token-Inhalt. Trennen Sie Authentifizierung (wer ruft auf) von Autorisierung (was sie tun dürfen), damit Richtlinien auch dann durchgesetzt werden können, wenn sich die Authentifizierungsmethode ändert.

Worauf man als Nächstes achten sollte

Die zwei offenen Pull Requests – DPoP-Binding und Workload-Identity-Federation – sind die einzigen Wege zu einem echten Machine-to-Machine-Identitätsstandard innerhalb von MCP. Wenn die Community diese übernimmt, werden Agenten in der Lage sein, den Besitz eines privaten Schlüssels nachzuweisen oder Cloud-ausgestellte Identitäten zu übernehmen, ohne Secrets preiszugeben. Bis dahin muss jede Produktivsetzung auf externe Identitäts-Frameworks vertrauen oder das Risiko statischer Anmeldedaten in Kauf nehmen.

Das Fazit ist klar: MCP kann derzeit die Person hinter einer Anfrage authentifizieren, aber noch nicht die Software, die die Anfrage stellt. Teams, die sichere autonome Agenten benötigen, sollten nicht darauf warten, dass die Spezifikation veröffentlicht wird; sie müssen die Identität bereits heute auf der Workload-Ebene aufbauen und die ausstehenden DPoP- und Federation-Vorschläge im Auge behalten.