Digitale Identitäten und Zero Trust für KI-Agenten

Warum das Model Context Protocol den statischen Schlüsseln überlegen ist

Entwickler erstellen in hohem Tempo neue KI-Agenten, um sämtliche Bereiche – vom Kunden-Support bis hin zur Infrastrukturverwaltung – zu automatisieren. Diese KI-Agenten sind äußerst robust und vielseitig: sie können E-Mails lesen, Produktionsdatenbanken abfragen und sogar Server bereitstellen. Während sich die Fähigkeiten dieser KI-Systeme somit stetig weiterentwickelt haben, ist die Art und Weise, wie man sie absichert, jedoch auf der Stelle getreten.

Die meisten KI-Agenten werden mithilfe statischer API-Schlüssel betrieben, die über weitreichende und dauerhafte Berechtigungen verfügen. Dies bedeutet: Gelingt es einem Angreifer, den Agenten mittels Prompt Injection zu manipulieren, könnte er in den Besitz von Administrator-Schlüsseln gelangen. Dieses Sicherheitsmodell ist offensichtlich veraltet und verstößt gegen die grundlegenden Prinzipien des Zero-Trust-Konzepts.

Eine starke Antwort darauf ist das Model Context Protocol (MCP), um KI-Agenten nach dem Prinzip der Geringsten Privilegien (Least Privilege) nur den für sie notwendigen Zugriff zu gewähren und zugleich sicherzustellen, dass sie nur dann tätig werden, wenn sie dazu autorisiert wurden.

Die Superuser-Falle

Ein Jahrzehnt lang haben sich Sicherheitsfachkräfte dafür eingesetzt, geteilte Passwörter für menschliche Nutzer abzuschaffen – und nun werden vielerorts die KI-Agenten häufig wie Superuser behandelt und ihnen der Zugriff auf fest im Code verankerte Geheimnisse gewährt. Wenn man aber ein statisches API-Token direkt in die Umgebungsvariablen eines Agenten einfügt, erschafft man eine große Angriffsfläche, denn diesem Token fehlt der Kontext: Das System weiß somit zwar, dass das API-Token verwendet wurde, jedoch nicht, warum oder von wem der KI-Agent ausgelöst wurde.

KI-Agenten können zudem ‘halluzinieren (Dinge erfinden und somit unseriöse Antworten ausgeben oder Aufgaben unsauber ausführen) oder manipuliert werden. Geschieht dies, dann können ihre Schritte kaum nachvollzogen werden. Noch schwieriger kann es unter diesen Umständen sein, ihren Zugriff zu entziehen, ohne die gesamte Anwendung lahmzulegen. Um nicht in diese Falle zu laufen, oder ihr zu entkommen, müssen KI-Agenten bezüglich des Identitätsmanagements ebenso behandelt werden, wie die digitalen Benutzerkonten von Menschen und Maschinen.

Der Rotations-Alptraum

Bei einer ehrlichen Bestandsaufnahme wird jeder IT-Entscheider festellen: Niemand rotiert statische Schlüssel so häufig, wie man es tun sollte – denn es ist ein logistischer Albtraum.

Ein Beispiel: Wenn man ein einzelnes OKTA_API_TOKEN fest in drei verschiedene Microservices, eine CI/CD-Pipeline und eine lokale .env-Datei für Testzwecke programmiert, dann ist die Rotation dieses Schlüssels keine reine Sicherheitsaufgabe mehr – sie ist vielmehr eine tickende Zeitbombe, die darauf wartet, einen Ausfall verursachen zu dürfen. Um dies korrekt durchzuführen, muss man daher einen neuen Schlüssel generieren, jedes Repository ausfindig machen, das den alten Schlüssel verwendet, sämtliche Dienste erneut ausrollen – und dabei inständig hoffen, dass man nicht einen noch so winzigen Cron-Job übersehen hat, der irgendwo auf einem Legacy-Server läuft.

Da dieser Prozess so mühsam ist, schieben IT-Teams ihn oft auf. Es gibt daher Produktionsschlüssel, die seit Jahren nicht rotiert wurden – schlichtweg, weil der ursprüngliche Entwickler, der sie erstellt hatte, das Unternehmen verlassen hat und niemand derjenige sein möchte, der durch eine Änderung den Build zum Scheitern bringen könnte.

Dieser Umstand schlägt eine große Bresche in die Cyber-Burgmauer jeder betroffenen Firma, denn: Sollte dieser Schlüssel nach außen dringen, hat der Hacker, der ihn ergattert, dauerhaften Zugriff – und zwar so lange, bis man den Schlüssel in einer Panikreaktion hektisch und mit hoher Wahrscheinlichkeit unsauber rotiert.

Die Lösung: Der „Im-Auftrag-von“-Ablauf

Um diese derzeit sich auftürmende Welle der KI-Automatisierung abzusichern, müssen die IT-Entscheider von statischen Schlüsseln auf einen dynamischen Token-Austausch umsteigen (definiert in RFC 8693). Im Kontext der Identitätssicherheit ist dies als „On-Behalf-Of“-Flow (OBO-Flow) bekannt. Hierbei agiert ein KI-Agent als Stellvertreter, nicht als Administrator und somit Superuser. Wenn ein Benutzer einen KI-Agenten also mit einer Aufgabe betraut, authentifiziert sich der KI-Agent zwar selbst, fordert jedoch eine Berechtigung an, um im Namen dieses Benutzers handeln zu dürfen.

Dieses Vorgehen erfordert zwei zentrale Komponenten:

• Ein Standardprotokoll: Man benötigt eine Möglichkeit für die Künstliche Intelligenz, um ihre Anfragen zu standardisieren. Hier kommt das Model Context Protocol (MCP) ins Spiel.
• Identitätsbestätigung: Man benötigt eine Möglichkeit, um die Benutzersitzung gegen ein temporäres, auf einen bestimmten Geltungsbereich beschränktes Zugriffs-Token für den KI-Agenten auszutauschen.

Implementierung des Model Context Protocol (MCP)

Wie sich dieses Muster praktisch umsetzen lässt, kann an folgendem Beispiel erläutert werden. Als Grundlage dient hier der Open-Source-Okta-MCP-Server, um die Verbindung zwischen einem LLM (wie etwa GitHub Copilot oder Claude) und dem Identitätsanbieter (IdP) herzustellen.

Schritt 1: Entfernen statischer Geheimnisse
Zunächst überprüft man den Code des KI-Agenten. Identifiziert werden sollten dabei alle Umgebungsvariablen, die langlebige Geheimnisse speichern – beispielsweise XX_API_TOKEN. Diese müssen vollständig entfernt werden, denn die Verwendung statischer Schlüssel für dynamische Agenten gleicht aus sicherheitstechnischer Sicht dem Teilen des Online-Banking-Passworts mit einem temporären externen Mitarbeiter. Das Ziel besteht also darin, sicherzustellen, dass der KI-Agent keinerlei Berechtigungen besitzt, solange er sich im Ruhezustand befindet.

Schritt 2: Konfiguration bereichsbezogener Berechtigungen (Scoped Permissions)
Nun registriert man diesen KI-Agenten im jeweiligen IdP als eigenständige Anwendung. Dies ermöglicht es, exakt zu definieren, welche Aktionen er ausführen darf oder welche nicht. Anstatt pauschale Lese- und Schreibzugriffe zu gewähren, sollte man auf granulare Berechtigungsbereiche (Scopes) setzen. Der Agent sollte zum Beispiel keine expliziten Einzelberechtigungen wie users.delete erhalten. Das kann über einen Cross-App Access (XAA) bequem geregelt werden. Dieser erlaubt es nämlich, die spezifischen Berechtigungen direkt an die eindeutige Client-ID des Agenten zu koppeln.

Schritt 3: Der Token-Austausch
Nun folgt der Blick auf den technischen Ablauf, wenn ein Benutzer eine Anfrage an den KI-Agenten richtet (z. B.: „Mein Passwort zurücksetzen“):

• Der Auslöser: Der Benutzer sendet eine Anfrage (Prompt) über seine IDE oder ein Chat-Interface an den KI-Agenten.
• Der Handshake: Der KI-Agent stellt daraufhin, unter Verwendung des Standardprotokolls, eine Verbindung zum MCP-Server her.
• Der Austausch: Der Server fängt die Anfrage ab und führt eine Identitätsbestätigung (Identity Assertion) durch. Er übermittelt dem IdP folgende Meldung: „Ich bin ein KI-Agent für die Passwortzurücksetzung. Benutzer X hat mich soeben autorisiert. Bitte stellen Sie mir ein Token aus, das für fünf Minuten gültig ist.“
• Die Ausführung: Der IdP stellt daraufhin ein kurzlebiges Token aus, welches ausschließlich für die spezifische Aufgabe der Passwortzurücksetzung gültig ist.

Das Ergebnis: Für einen Audit bereite KI-Agenten
Durch die Implementierung dieser Architektur wandeln IT-Entscheider ihre unübersichtlichen Protokolle in einen übersichtlichen Stacktrace um. Anstatt einer allgemeinen Systemaktion anzuzeigen, zeigen die Protokolle dann Folgendes an:

„Der Passwort-Reset-Agent hat im Auftrag von Benutzer X auf die Passwort-API zugegriffen.“

Diese detaillierte Transparenz ermöglicht es Sicherheits-Teams, die Zugriffsprüfungen für KI-Agenten so durchzuführen, wie für reguläre Mitarbeiter. Sollte sich ein KI-Agent aus irgendeinem Grund verdächtig verhalten, könnte man seine spezifische Zugriffsrichtlinie sofort widerrufen, ohne die Schlüssel für das gesamte Entwickler-Team austauschen zu müssen.

Von statischen Schlüsseln zu sicherer Autonomie

Da KI-Agenten zunehmend autonom arbeiten können und sollen, darf die IT-Sicherheit nicht stehenbleiben und sie mittels derselben statischen Schlüssel absichern, die bereits vor über zehn Jahren (2015) für Cron-Jobs verwendet wurden. Diese Technik ist veraltet.

Sobald man dagegen das Model Context Protocol (MCP) und Identity Assertion, sowie Cross-App Access (XAA) implementiert hat, können KI-Agenten wesentlich sicherer genutzt und viel einfacher in ihren Tätigkeiten und Zugriffsrechten überwacht werden. Die Zukunft gehört dem Token-Austausch, nicht dem statischen API-Schlüssel – und das Meistern dieser Grundlagen des Identitätsmanagements, hin zu einer umfassenden Identity Security, mit Standards und modernen Methoden, führt erst zum sicheren und vorteilhaften Betrieb von KI-Agenten.