MCP hat jetzt einen spezifizierten Weg, wie sich ein Agent ohne Menschen in der Schleife authentifiziert. SEP-1046 ergänzt das Model Context Protocol um den OAuth-Grant client_credentials als offizielle Erweiterung, mit private_key_jwt (JWT Client Assertions nach RFC 7523) als empfohlener Methode zur Client-Authentifizierung und einfachen Client Secrets aus Kompatibilitätsgründen. Der Vorschlag wurde im Oktober 2025 angenommen und ist in den vergangenen Monaten im TypeScript-, im Python- und nun auch im Ruby-SDK gelandet. Wer Agenten im Unternehmen betreibt, hat genau auf dieses Puzzleteil gewartet, ob er die SEP-Nummer kannte oder nicht.

Ein Geständnis vor der Substanz: Dieser Beitrag wäre fast nicht geschrieben worden. Der Agentic-AI-Bereich bewegt sich schnell genug, dass das Schreiben darüber selbst zum Terminproblem wird; SEP-1046 lag in meinem Entwurfsordner, während drei andere Dinge live gingen, und ich habe erst jetzt Zeit gefunden, weil Brad Webbs Synopsis zu Enterprise-MCP-Autorisierungsmustern in meiner Leseliste landete und das Bild vollständig genug machte, um deine Zeit wert zu sein. Lies auch seinen Text. Dieser hier ist meine kürzere, meinungsstärkere Sicht darauf, was für Enterprise-Teams tatsächlich zählt.

Wie aus einem GitHub-Issue eine Sicherheitsschicht wird

Am 24. Juli 2025 öffnete Darin McAdams Issue #1046 im Spezifikations-Repo von MCP. Die Herkunft zählt hier: McAdams verbrachte fast 26 Jahre bei Amazon, zuletzt als Senior Principal Software Engineer, und schrieb diesen Vorschlag in seinen letzten Wochen dort, bevor er als Architect zum Identity-Security-Unternehmen Defakto Security wechselte. Der Vorschlag ist kurz und chirurgisch: Die ursprüngliche MCP-Authorization-Spec erwähnte den Client-Credentials-Flow, spätere Revisionen strichen ihn, und am Ende schwieg die Spec ausgerechnet zum häufigsten Enterprise-Szenario, einem Workload, der einen MCP-Server aufrufen muss, wenn kein Endnutzer anwesend ist, der sich durch einen interaktiven Consent-Screen klickt.

Der Vorschlag wurde als SEP-1046 angenommen und am 30. Oktober 2025 finalisiert, ausgeliefert als MCP-Erweiterung io.modelcontextprotocol/oauth-client-credentials statt als Änderung an der Kern-Spec. Dann folgten die Implementierungen: PrivateKeyJwtProvider im TypeScript-SDK, PrivateKeyJWTOAuthProvider im Python-SDK und zuletzt ein Commit von Koichi ITO (koic, bekannt durch RuboCop), der private_key_jwt-Support ins offizielle Ruby-SDK bringt, samt Conformance-Szenario. Diese Abfolge, vom Vorschlag zur akzeptierten SEP zu unabhängigen Implementierungen, die eine gemeinsame Conformance-Suite bestehen, ist das, was ein erwachsen werdendes Protokoll ausmacht. Vor zwei Jahren bedeutete "MCP-Auth" ein Bearer-Token in einer Umgebungsvariable und ein Stoßgebet.

Warum Client Credentials zählen: Agenten haben keinen Browser

Der OAuth Authorization Code Flow, auf dem die MCP-Basis-Spec aufbaut, setzt einen Menschen voraus. Jemand sieht einen Consent-Screen, authentifiziert sich beim Identity Provider und delegiert einen Teil seiner Befugnisse an den Client. Dieses Modell passt zu Claude Desktop, das sich mit deinem CRM verbindet. Es passt nicht zu den Workloads, die Unternehmen tatsächlich betreiben: ein nächtlicher Abgleichs-Agent, eine CI-Pipeline, die einen internen MCP-Server abfragt, ein Supervisor-Agent, der um 3 Uhr morgens Aufgaben an Spezialisten-Agenten verteilt. Niemand ist wach, um auf "Erlauben" zu klicken.

Client Credentials ist das Dienstkonto-Muster aus jedem Enterprise-IAM-Playbook, angewandt auf MCP. Der Workload hat eine eigene Identität, vorab in deiner Identity-Plattform registriert, und authentifiziert sich als er selbst. Keine geliehene User-Session, keine Headless-Browser-Automatisierung, die einen Menschen vortäuscht, kein langlebiges Personal Access Token, das notdürftig in einen Secrets Manager geklebt wurde. Der Agent ist ein vollwertiger Principal mit eigenen Berechtigungen, eigenem Audit-Trail und eigenem Lebenszyklus. Wenn dein Security-Team MCP-Rollouts blockiert hat, weil "die Agenten sich als Dave authentifizieren", ist das die Antwort, die du ihm geben kannst.

private_key_jwt: der richtige Default und sein Preis

SEP-1046 beschränkt die Client-Authentifizierung bewusst auf zwei Optionen. Client Secrets über HTTP Basic sind erlaubt, weil jeder Identity Provider der Welt sie heute unterstützt. Die empfohlene Methode ist aber private_key_jwt: Der Client signiert eine kurzlebige JWT-Assertion mit einem Private Key und legt diese statt eines Secrets vor. Die Design-Details in den SDK-Implementierungen lohnen die Lektüre, weil sie echtes Sicherheitsurteilsvermögen kodieren:

  • Die Assertion trägt iss und sub gesetzt auf die Client-ID, aud gesetzt auf den Issuer Identifier des Authorization Servers, ein exp von 300 Sekunden und eine eindeutige jti. Gestohlene Assertions verfallen nach fünf Minuten und lassen sich nicht wiederholen.
  • Der Private Key verlässt nie den Client und wird nie in den Token-Speicher geschrieben. Es liegt kein Shared Secret in der Datenbank des Authorization Servers, das auf seinen Dump wartet.
  • Die client_id fehlt im Request-Body vollständig; die Identität reist innerhalb der signierten Assertion. Der Token-Request trägt außerdem den resource-Parameter nach RFC 8707, sodass das zurückkommende Token an genau einen MCP-Server gebunden ist, statt gegen alles nutzbar zu sein, was den Issuer akzeptiert.

Der Preis ist Schlüsselverwaltung. Asymmetrische Schlüssel brauchen Erzeugung, Verteilung, Rotation und Widerruf, und SEP-1046 spezifiziert absichtlich noch nicht, wie ein Server das JWKS des Clients findet, um Assertions zu validieren; das wartet auf die WIMSE-Arbeit zu Headless JWT und den reifenden Client-ID-Metadata-Draft bei der IETF. In der Praxis heißt das: Die meisten Teams starten mit Client Secrets und migrieren zu JWT-Assertions, sobald das Tooling ihrer Identity-Plattform nachzieht. Das ist in Ordnung. Heute die kompatible Option mit spezifiziertem Upgrade-Pfad zu wählen ist etwas anderes, als gar keinen Pfad zu haben.

Eine bewusste Auslassung sorgte im Issue-Thread für Debatte: mTLS. Mehrere Kommentatoren wollten Client-Zertifikate nach RFC 8705 im Scope haben, und der Einwand dagegen erklärt, warum sie es nicht sind: In realen Deployments terminiert TLS am CDN oder Load Balancer, mehrere Hops vor der Anwendungsschicht, in der MCP tatsächlich läuft, sodass der Server das Client-Zertifikat ohne Infrastruktur-Verrenkungen nie zu sehen bekommt. Unternehmen mit funktionierender interner PKI können weiterhin mTLS zwischen ihren eigenen Services fahren; die Spec weigert sich nur, allen anderen diese Annahme aufzubürden.

Die Muster, die den Kontakt mit einem Unternehmen überleben

Webbs Artikel rahmt die Entscheidung besser als jede Protokoll-Vergleichstabelle: Beginne dort, wo die Befugnis des Agenten herkommt, nicht bei einem Menü aus OAuth-Flows. Alles Weitere ergibt sich aus dieser Frage. Drei Muster decken fast jeden Enterprise-Fall ab:

  • Delegierte Nutzerbefugnis für interaktive Tools: Die Berechtigungen des Menschen fließen über den Authorization Code Flow zum Agenten. Die Falle hier ist Token-Pass-Through, das direkte Weiterreichen des Tokens vom vorgelagerten Identity Provider an den MCP-Server. Das funktioniert in der Demo und koppelt deine Agenten-Plattform in Produktion an ein fremdes Token-Format und Vertrauensmodell. Tausche das Token gegen ein kurzlebiges, das für den konkreten MCP-Server ausgestellt wird, mit erzwungener Audience-Validierung. Die Resource-Indicator-Pflicht der Spec nach RFC 8707 existiert genau dafür, dass das Durchreichen generischer Tokens fehlschlägt.
  • Maschinenidentität für unbeaufsichtigte Workloads: SEP-1046 Client Credentials, bevorzugt private_key_jwt, ein registrierter Client pro Agent-Workload, nicht ein geteilter "Agents"-Client für die ganze Plattform. Der Schadensradius folgt der Registrierungsgranularität.
  • Duale Identität für die interessante Mitte: ein Agent, der im Auftrag eines Nutzers handelt, aber unbeaufsichtigt läuft. Das Token sollte sowohl den Actor (den Agenten) als auch das Subject (den Nutzer) abbilden, was Token Exchange unterstützt und die meisten Authorization Server inzwischen ausdrücken können. Dieses Muster hält die Frage "welcher Mensch ist für diese Aktion verantwortlich" im Audit beantwortbar, und genau diese Frage wird dein Compliance-Team stellen.

Zur Registrierung selbst: SEP-991 machte OAuth Client ID Metadata Documents zum bevorzugten Muster für Clients und Server ohne bestehende Beziehung, eine HTTPS-URL als Client Identifier. Elegant für das offene Ökosystem; für ein geschlossenes Unternehmen bleibt die Vorab-Registrierung über die eigene Corporate-Identity-Plattform der stärkere Default, weil sie Ownership, Allow-Listing und Lifecycle-Kontrolle liefert und eine ganze Klasse von SSRF-Risiken beim Metadata-Fetch aus dem Threat Model entfernt.

SEP-1046 ist eine Spur, nicht die ganze Straße

Wer eine Stunde im auth-Label des Spec-Repos verbringt, merkt schnell: Mit einem einzelnen SEP ist es nicht getan. Es gibt eine ständige Auth-Arbeitsgruppe mit festem Meeting-Rhythmus und eine Warteschlange von Vorschlägen, die skizziert, wohin sich Enterprise-MCP-Autorisierung als Nächstes bewegt. SEP-1488 ergänzt securitySchemes in den Tool-Metadaten für Mixed-Auth-Server, ein Server mit öffentlichen Tools neben OAuth-geschützten. SEP-1489 standardisiert den Fehler, mit dem ein Tool mitten in einer Session einen OAuth-Flow auslöst, also Step-up-Autorisierung in Agentenbegriffen. SEP-2742 will, dass Remote-Server ihre Authentifizierungsmethoden vorab deklarieren, damit ein Client vor dem Verbinden weiß, worauf er sich einlässt. HTTP Message Signing ist als PR #2752 zurück, nachdem SEP-1415 eingeschlafen war. Und die Härtung landet laufend zwischen den großen SEPs: verpflichtende RFC 9207 Issuer-Validierung gegen Mix-up-Angriffe (#1721), Rich Authorization Requests nach RFC 9396 (#1670), Weiterleitung von Refresh Tokens für Offline-Zugriff (#1735) und ein offener Anlauf, die Autorisierungs-Spec zu verschlanken, indem sie an die zugrunde liegenden OAuth-RFCs delegiert (#3054). Wer in einem Unternehmen Agentensicherheit verantwortet, hat mit dieser Issue-Queue seine Roadmap. Lies sie wie dein eigenes Backlog.

Was du am Montag damit anfängst

Konkret, für ein Platform- oder Security-Team, das MCP in einer Organisation ausrollt:

  • Inventarisiere jede MCP-Integration und klassifiziere sie: interaktiv, unbeaufsichtigt oder handelnd im Auftrag eines Nutzers. Der Flow folgt der Klasse, nie umgekehrt.
  • Gib jedem unbeaufsichtigten Agenten einen eigenen registrierten Client in deinem Identity Provider. Starte mit Client Secrets, wenn dein Tooling es verlangt, aber setze private_key_jwt jetzt auf die Roadmap und prüfe, ob dein SDK es schon unterstützt. TypeScript, Python und Ruby tun es.
  • Erzwinge Audience-Validierung auf jedem MCP-Server, den du betreibst. Ein Token, das für einen Server ausgestellt wurde, muss auf einem anderen fehlschlagen. Das ist die billigste Kontrolle im ganzen Stack und die am häufigsten übersprungene.
  • Verbiete Token-Pass-Through im Code Review, genauso wie du zusammengebautes SQL aus Strings verbietest. Es ist die SQL-Injection der Agentenidentität: bequem, überall und falsch.
  • Halte Agenten-Berechtigungen standardmäßig read-only und sichere jeden mutierenden Pfad einzeln ab, dieselbe Haltung, die ich auf der Infrastrukturebene im Agents-on-Call-Beitrag zum Gateway vertreten habe. Authentifizierung sagt dir, wer der Agent ist; sie sagt nichts darüber, was er tun dürfen sollte.

Der größere Punkt: Jeden Monat löst sich ein weiteres Stück von "Unternehmen können keine Agenten einführen, weil X" still in irgendeinem GitHub-Issue auf. Auth war das größte X. Vor einem Jahr war die ehrliche Antwort auf "wie authentifizieren sich unsere unbeaufsichtigten Agenten gegenüber MCP-Servern" ein Achselzucken. Jetzt ist sie eine SEP-Nummer, zwei Client-Authentifizierungsmethoden und Conformance-Tests in drei SDKs. Wir alle lernen jede Woche ein Stück mehr darüber, was wir bauen können und wie. Die Teams, die diese Nahtstellen beim Schließen beobachten, liefern ein Jahr vor den Teams, die auf ein fertiges Lehrbuch warten, denn das wird es nicht geben.

Lies das als Nächstes

Identität ist nur die Hälfte der Agenten-Sicherheit. IAM for LLM Apps: Least Privilege When the Caller Is a Model behandelt die Autorisierungshälfte auf AWS. Auf der Schwesterseite zeigt Agent Toolkit for AWS: The Docs Have a New Reader, was passiert, wenn der Agent, der deine Infrastruktur konsumiert, zugleich derjenige ist, der das Handbuch liest, und ercanermis.com hat die komplette Karte, was ich wo schreibe.

Referenzen