Die Entwicklung agentischer KI-Systeme, bei denen große Sprachmodelle (Large Language Models, LLMs) autonome, zielgerichtete Handlungen ausführen, verändert die Art und Weise, wie Autorisierung und Zugriffskontrolle in der digitalen Welt gehandhabt werden. Diese Systeme können heute Datenbanken auslesen, API-Aufrufe anstoßen und Anwendungen über verschiedene Plattformen hinweg miteinander verbinden – oft ohne direkte menschliche Eingriffe. Vor diesem Hintergrund stellt sich die fundamentale Frage: Wie lassen sich Identität und Zugriffsrechte sicher verwalten, wenn kein Mensch im Autorisierungsvorgang involviert ist? Eine vielversprechende Antwort auf diese Herausforderung bietet das Model Context Protocol (MCP), das ursprünglich von Anthropic entwickelt wurde und als standardisierte Schnittstelle dafür dient, wie agentische KI-Systeme mit externen Tools, Prompts und Ressourcen interagieren können.
Mit der zunehmenden Leistungsfähigkeit und Autonomie dieser Agenten wächst zwar das Potenzial für Innovationen, gleichzeitig steigen aber auch die Risiken – von fehlerhaften Aktionen bis hin zu böswilligen Zugriffen. Da Agenten oft verwirrende Mischung aus delegierter Benutzerautorität und eigenständigem Handeln zeigen, wird eine robuste, flexible und vor allem sichere Autorisierungslösung unabdingbar. Das jüngst veröffentlichte MCP-Authorization-Specification-Dokument setzt genau hier an. Es schlägt eine auf OAuth 2. 1 und PKCE (Proof Key for Code Exchange) basierende Methode zur Tokenbeschaffung für den Zugriff auf geschützte Ressourcen vor. OAuth 2. 1 selbst ist der neueste Standard im Bereich der Autorisierung und konsolidiert die Erfahrungen sowie Sicherheitsverbesserungen aus der Vorgängerversion OAuth 2. 0.
Die Einbindung von PKCE spielt dabei eine entscheidende Rolle: Sie schützt den Token-Austausch selbst unter Bedingungen, in denen herkömmliche Client-Authentifizierungen nur schwer umzusetzen sind. Agentische KI-Systeme bringen eine Reihe spezifischer Herausforderungen mit sich, die traditionelle Web- und Mobile-Authorization-Modelle überfordern. Dazu gehören die dynamische Verhaltensweise der Agenten, die Abwesenheit eines menschlichen Users als Autorisierer, sowie komplexe Anforderungen an die Nachvollziehbarkeit und Verantwortlichkeit. Agenten entscheiden beispielsweise erst zur Laufzeit, welche Werkzeuge sie nutzen, und agieren oft mit lang anhaltenden, zustandslosen Sessions in Cloud-nativen Umgebungen. Das MCP-Authorization-Framework setzt deshalb auf einen modularen, standardisierten Weg: Eine MCP-Client-Anfrage wird zunächst vom Server mit einem HTTP-Status 401 „Unauthorized“ und einem Link zu einer „Protected Resource Metadata“ (PRM) beantwortet.
Diese PRM-Datei ist ein JSON-Dokument, das Auskunft darüber gibt, wo und wie ein Zugriffstoken zu beziehen ist, und welche Gültigkeit und Berechtigungen es haben muss. So können Agenten flexibel, ohne feste Codierung von Zugriffspunkten oder Berechtigungen, sicher auf Ressourcen zugreifen. Ein zentraler Fortschritt ist dabei der Verzicht auf die zuvor bei OAuth 2. 0 erlaubte „Implicit Flow“ und die Einführung von PKCE als obligatorische Maßnahme auch für „confidential clients“. PKCE sorgt dafür, dass der Austausch eines Autorisierungscodes gegen einen Access Token nur funktioniert, wenn der Client mittels eines zuvor generierten Geheimnisses (Code Verifier) nachweist, berechtigt zu sein. Dadurch wird das Risiko verringert, dass ein Angreifer durch Abfangen des Codes Zugriff erhält. Gerade in Umgebungen, in denen Clients keine sicheren Geheimnisse speichern können – wie Container oder serverlose Funktionen – ist PKCE eine wichtige Sicherheitsschicht.
Der in der MCP-Spezifikation beschriebene Autorisierungsablauf sieht vor, dass die KI-Agenten die PRM-Informationen abrufen, die Autorisierung über einen OAuth 2. 1-kompatiblen Server initiieren, den PKCE-Code-Challenge-Mechanismus verwenden und nach erfolgreicher Authentifizierung und Token-Ausgabe die ursprüngliche Anfrage mit dem Access Token erneut absenden. Wichtig ist jedoch, dass die Spezifikation bewusst offen lässt, wie Agenten selbst gegenüber dem Autorisierungsserver authentifiziert werden. Während traditionell Menschen über Single Sign-On (SSO) oder Multi-Faktor-Authentifizierung (MFA) legitimiert werden, fehlt für autonome Agenten eine solche direkte Identitätsprüfung. Hier kommt die Idee der „infrastructure-asserted identity“ ins Spiel – ein Konzept, bei dem die Identität eines Workloads oder einer Instanz von der Infrastruktur selbst bestätigt wird.
Beispiele hierfür sind AWS IAM-Rollen für serverlose Funktionen, Azure Instance Metadata oder Kubernetes Service Account Tokens, die innerhalb eines Pods projektiert werden. Diese Methoden erlauben es dem Autorisierungsserver, die Herkunft, Umgebung und den Kontext des anfragenden Agenten zu überprüfen und auf Basis dessen Zugriffsberechtigungen gezielt zu vergeben oder zu verweigern. Die Kombination aus starker agentischer Identitätsüberprüfung und kontextbasierten Zugriffskontrollen (conditional access) eröffnet die Möglichkeit, nicht nur stur Berechtigungen zu vergeben, sondern dynamisch Sicherheitsebenen einzufügen, die beispielsweise den Sicherheitsstatus des Host-Systems, Umgebungsfaktoren oder Zeitbedingungen berücksichtigen. Dies erlaubt die Ausgabe von kurzzeitigen, genau beschränkten Token, was das Risiko bei kompromittierten Zugangsdaten deutlich reduziert. Für Entwickler und Sicherheitsexperten bedeutet das, dass eine stringente Nutzung von PRM-Dokumenten unverzichtbar ist.
Hardcodierte Endpunkte und Permissions sind nicht nur inflexibel, sie erhöhen auch Sicherheitsrisiken. Der universelle Einsatz von OAuth 2. 1 mit PKCE ist eine Best Practice, die auch von vertrauenswürdigen Clients verlangt wird, um maximale Sicherheit zu gewährleisten. Die Integration von kurzlebigen, scopespezifischen Token sowie der Einsatz von Infrastruktur-basierten Authentifizierungsmethoden bildet die Grundlage für sichere, skalierbare agentische Systeme. Parallel dazu sollte umfangreiches Logging und Monitoring implementiert sein, um sowohl die Token-Ausgabe als auch Agent-Tool-Interaktionen nachvollziehen zu können. So wird die verantwortliche Nachverfolgbarkeit gewährleistet und die Grundlage für Audits geschaffen. Obwohl das MCP-Authorization-Spec eine solide Basis für die sichere Agentenautorisierung darstellt, wird deutlich, dass Autorisierung nur ein Teil der gesamten Sicherheitsarchitektur in agentischen KI-Landschaften ist.
Die Identität der Agenten und Workloads ist der kritische Ausgangspunkt, an dem Vertrauen beginnt. Ohne robuste und automatisierte Authentifizierungsverfahren, die für nicht-menschliche Akteure geeignet sind, bleibt das Sicherheitspotenzial begrenzt. Innovationen in der Cloud- und Container-Infrastruktur geben Hoffnung, dass sich hier in den kommenden Jahren Standards etablieren. Die Verlagerung weg von statischen Anmeldeinformationen hin zu dynamisch belastbaren, kontextabhängigen Identitäten ist ein entscheidender Schritt, um das volle Potenzial autonomer KI-Agenten sicher auszuschöpfen. Insgesamt zwingt die zunehmende Verbreitung von agentischen KI-Systemen Unternehmen, Plattformanbieter und Sicherheitsexperten, enger zusammenzuarbeiten. Nur mit einem klaren, gemeinsamen Verständnis von Identitäts- und Zugriffsmanagement kann das Vertrauen in komplexe KI-Ökosysteme geschaffen werden.
Das MCP-Authorization-Spec stellt ein bedeutsames Fundament dar, um diesen Weg strukturiert zu beschreiten. Die Integration von OAuth 2. 1, PKCE und Infrastruktur-gestützter Identität ist das Gerüst, auf dem zukunftsfähige, sichere KI-Plattformen aufbauen können. Für alle, die an der Spitze dieser Entwicklung stehen – von Softwarearchitekten bis zu DevSecOps-Teams – heißt es heute, diese Sicherheitsprinzipien frühzeitig zu übernehmen und weiterzuentwickeln. Die Zukunft der KI-Autorisierung ist dynamisch, kontextsensitiv und vertrauensbasiert. Nur so können agentische Systeme ihr volles Potenzial entfalten, ohne dass Sicherheit, Kontrolle und Verantwortlichkeit auf der Strecke bleiben.
