Entwickler erstellen KI-Agenten in rasantem Tempo, um alles vom Kundensupport bis zum Infrastrukturmanagement zu automatisieren. Diese KI-Agenten sind sehr robust und können E-Mails lesen, Produktionsdatenbanken abfragen und sogar Server bereitstellen. Während sich die Fähigkeiten dieser KI-Systeme weiterentwickelt haben, hat sich die Art und Weise, wie wir sie absichern, nicht verändert.
Die meisten KI-Agenten werden heute mit statischen API-Schlüsseln mit weitreichenden, langlebigen Berechtigungen betrieben. Das bedeutet, dass ein Angreifer in den Besitz von Administrator-Schlüsseln gelangen könnte, wenn er den Agenten über Prompt Injection manipuliert. Dieses Sicherheitsmodell ist veraltet und verletzt die Kernprinzipien von Zero Trust.
Zunächst untersuchen wir, warum KI-Agenten eindeutige Identitäten benötigen, und erläutern anschließend, wie das Model Context Protocol (MCP) implementiert wird, um KI-Agenten Least-Privilege-Zugriff zu gewähren und sicherzustellen, dass sie nur handeln, wenn sie autorisiert sind.
Das „Superuser“-Problem
Wir haben das letzte Jahrzehnt damit verbracht, uns von gemeinsam genutzten Passwörtern für Menschen zu verabschieden, dennoch behandeln wir KI-Agenten oft wie Superuser und gewähren ihnen fest codierte Geheimnisse. Wenn wir ein statisches API-Token direkt in die Umgebungsvariablen eines Agenten einfügen, schaffen wir eine große Angriffsfläche. Diesem Token fehlt der Kontext – das System weiß, dass das API-Token verwendet wurde, aber nicht, warum oder von wem der Agent ausgelöst wurde.
Agenten können halluzinieren oder manipuliert werden; sobald dies geschieht, können sie Aktionen ausführen, die schwer nachzuverfolgen sind, und es kann noch schwieriger sein, den Widerruf des Zugriffs ohne die gesamte Anwendung zu beeinträchtigen. Um dieses Problem zu beheben, sollten wir KI-Agenten mit derselben Identity-First-Denkweise behandeln, die wir bei menschlichen Mitarbeitern anwenden.
Der Albtraum der „Rotation“
Seien wir ehrlich: Niemand rotiert statische Schlüssel so oft, wie man sollte, weil es ein logistischer Albtraum ist.
Wenn wir ein einziges OKTA_API_TOKEN in drei verschiedenen Microservices, einer CI/CD-Pipeline und einer lokalen .env hartcodiert haben Datei zum Testen, das Rotieren dieses Schlüssels ist keine Sicherheitsaufgabe – es ist ein vorprogrammierter Ausfall. Um dies richtig umzusetzen, müssen wir einen neuen Schlüssel generieren, jedes Repository finden, das den alten Schlüssel verwendet, alle Dienste neu bereitstellen und hoffen, dass wir keinen kleinen Cron-Job übersehen haben, der auf irgendeinem Legacy-Server läuft.
Da dieser Prozess so mühsam ist, schieben Teams ihn auf. Ich habe einige Produktionsschlüssel gesehen, die seit Jahren nicht rotiert wurden, weil der ursprüngliche Entwickler, der sie erstellt hat, das Unternehmen verlassen hat und niemand derjenige sein möchte, der den Build durch ihre Änderung beschädigt. Dies schafft ein massives Zeitfenster der Verwundbarkeit: Wenn dieser Schlüssel kompromittiert wird, hat der Angreifer dauerhaften Zugriff, bis Sie ihn notfallmäßig rotieren.
Die Lösung: Der „On-Behalf-Of“-Ablauf
Um diese neue Welle der Automatisierung abzusichern, sollten wir von statischen Schlüsseln zu einem dynamischen Token-Austausch (definiert in RFC 8693) übergehen. In der Identity-Architektur kennen wir dies als den On-Behalf-Of (OBO) -Ablauf. Hier fungiert der Agent als Stellvertreter und nicht als God-Mode-Administrator. Wenn ein Benutzer den Agenten auffordert, eine Aktion auszuführen, authentifiziert sich der Agent selbst, fordert jedoch die Berechtigung an, im Namen dieses bestimmten Benutzers zu handeln.
Dies erfordert zwei Schlüsselkomponenten:
- Ein Standardprotokoll: Wir benötigen eine Möglichkeit für die KI, ihre Anfragen zu standardisieren; hier kommt das Model Context Protocol (MCP) ins Spiel.
- Identity-Assertion: Wir benötigen eine Möglichkeit, die Session des Benutzers gegen ein temporäres, bereichsbezogenes Access Token für den Agenten einzutauschen.
Implementierung des Model Context Protocol (MCP)
Nun sehen wir uns an, wie wir dieses Muster praktisch implementieren können. Hierfür verwenden wir den Open-Source Okta MCP Server, um die Verbindung zwischen unserem LLM (wie Github Copilot oder Claude) und Ihrem Identity-Anbieter (IdP) zu verwalten.
Schritt 1: Statische Secrets entfernen
Zunächst werden wir ein Audit des Codes unseres Agent durchführen. Hierfür sollten Sie alle Umgebungsvariablen identifizieren, die langlebige Geheimnisse speichern, wie z. B. OKTA_API_TOKEN, und diese alle löschen. Die Verwendung statischer Schlüssel für dynamische Agenten ist in puncto Sicherheit gleichbedeutend damit, Ihr Bank-Passwort an einen temporären Auftragnehmer weiterzugeben. Ziel ist es, sicherzustellen, dass der Agent im Leerlauf über keinerlei Berechtigungen verfügt.
Schritt 2: Bereichsbezogene Berechtigungen konfigurieren
Wir empfehlen, diesen Agenten in Ihrem jeweiligen Identity-Anbieter als eigenständige Anwendung zu registrieren. Dies ermöglicht es uns, genau zu definieren, was es tun kann und was nicht. Anstatt Lese-/Schreibzugriff zu gewähren, empfehlen wir, granulare Scopes zu verwenden. Beispielsweise sollte es keine expliziten Berechtigungen wie users.delete haben. In Okta wird dies über Cross-App Access (XAA) abgewickelt, wodurch wir diese spezifischen Berechtigungen an die eindeutige Client-ID des Agenten binden können.
Schritt 3: Der Token-Austausch
Sehen wir uns nun den technischen Ablauf an, wenn ein Benutzer den Agenten auffordert (z. B. „Mein Passwort zurücksetzen“):
- Der Auslöser: Der Benutzer sendet einen Prompt über seine IDE oder Chat-Oberfläche an den Agenten.
- Der Handshake: Der Agent verbindet sich dann über das Standardprotokoll mit dem MCP-Server.
- Der Austausch: Der Server fängt die Anfrage ab und führt eine Identity-Assertion durch. Es teilt dem Identity-Anbieter mit: „Ich bin ein Passwort-Reset-Agent. Benutzer-X hat mich gerade autorisiert. Bitte geben Sie mir ein Token, das fünf Minuten gültig ist.“
- Die Aktion: Der Identity-Anbieter stellt dann ein kurzlebiges Token aus, das nur für diese spezifische Aufgabe der Passwortzurücksetzung gültig ist.
Das Ergebnis: Auditfähige Agenten
Wenn wir diese Architektur implementieren, verwandeln wir unsere vagen Logs in einen klaren Stacktrace.
Anstatt eine generische Systemaktion anzuzeigen, zeigen unsere Logs Folgendes an:
„Passwort-Reset-Agent hat im Namen von Benutzer-X auf die Passwort-API zugegriffen.“
Diese granular Transparenz ermöglicht es Sicherheitsteams, Zugriffsüberprüfungen für KI-Agenten durchzuführen, genau wie bei regulären Mitarbeitern. Wenn sich ein KI-Agent aus irgendeinem Grund verdächtig verhält, können wir seine spezifische Zugriffsrichtlinie sofort widerrufen, ohne die Schlüssel für das gesamte Entwicklungsteam rotieren zu müssen.
Von statischen Schlüsseln zu sicherer Autonomie
Da sich KI-Agenten weiterentwickeln und autonomer werden, können wir es uns nicht leisten, sie mit denselben alten statischen Schlüsseln abzusichern, die wir 2015 für Cron-Jobs verwendet haben.
Sobald wir das Model Context Protocol und die Identity Assertion (XAA) einführen, können wir KI-Agenten einsetzen, die hilfreich, leistungsfähig und vor allem sicher sind.
Sind Sie bereit, mit der Entwicklung zu beginnen? Wir empfehlen Ihnen, sich den Open-Source- Okta MCP Server anzusehen. Diese Referenzimplementierung fungiert als Brücke zwischen Ihrem KI-Agenten und einem beliebigen Identity-Anbieter, um einen sicheren On-Behalf-Of-Token-Austausch zu ermöglichen.
