Viele Teams, die KI-Agenten einsetzen, sind einen Sicherheitskompromiss eingegangen, für den sie sich nicht bewusst entschieden haben. Sie gaben dem Agenten einen Service-Account, vielleicht einen gemeinsam genutzten API-Schlüssel; etwas mit ausreichendem Zugriff, um seine Aufgabe zu erfüllen, gespeichert in einer Konfigurationsdatei oder einer Umgebungsvariablen. hervorragend funktioniert. Der Agent ruft die richtigen APIs auf, die Demos laufen reibungslos und das Projekt wird ausgeliefert.
Was sie tatsächlich getan haben, ist, das Service-Account-Problem neu zu erschaffen, mit dem Unterschied, dass der Principal nun autonom und mit hoher Geschwindigkeit agiert und sein "Urteilsvermögen" durch jeden beliebigen Text beeinflusst werden kann, den er in einem Prompt liest.
Ich möchte eine bestimmte These aufstellen: Die Verwaltung des Zugriffs von KI-Agenten ist kein neues Problem, das neue Tools erfordert. Die Tools für privilegiertes Zugriffsmanagement (PAM), über die Sie bereits verfügen – Just-in-Time-Zugriff (JIT), Aufzeichnung einer Session, Durchsetzung des Least-Privilege-Prinzips und Audit-Trails –, werden alle wichtiger, nicht weniger wichtig. Stattdessen sollte sich das Identity-Modell weiterentwickeln, und diese Weiterentwicklung hat Auswirkungen darauf, welche PAM-Architekturen der Aufgabe tatsächlich gewachsen sind.
Das Problem, einen Agenten wie einen Service-Account zu behandeln
Ein Service-Account ist eine statische Identity. Es verfügt über Anmeldedaten und Berechtigungen, und wenn etwas schiefgeht, zeigt Ihnen das Audit-Protokoll, welcher Account was getan hat. Die Behebung ist klar: Anmeldedaten rotieren, Berechtigungen einschränken und fortfahren.
Ein KI-Agent ist eine andere Art von Principal. Es gibt einige Gründe, warum es nicht optimal zum Service-Account-Modell passt:
Es agiert im Auftrag eines Menschen
Wenn Ihr Analyst des Security Operations Center (SOC) einen Agenten bittet, einen Produktionsserver zu untersuchen, handelt der Agent nicht nach eigenem Ermessen; er führt eine Anweisung einer bestimmten Person aus. Die Identity dieser Person sollte im Zugriffsprotokoll enthalten sein. Ein Service-Account verfügt nicht über diesen Kontext. "Der Agent hat auf den Server zugegriffen" ist eine schwächere Aussage als "Jasons Agent hat auf den Server zugegriffen, im Anschluss an eine Session, die Jason um 18:51 Uhr nach Abschluss der MFA initiiert hat."
Seine Anweisungen können manipuliert werden.
Ein Service-Account führt das aus, was sein Code ihm vorgibt. Ein KI-Agent verarbeitet natürliche Sprache, was bedeutet, dass ein entsprechend formulierter Prompt fast alles wie einen sinnvollen nächsten Schritt klingen lassen kann. Die Sicherheitsgrenze, die einen Service-Account schützt – der Code selbst –, gilt nicht auf die gleiche Weise. Die Lösung besteht darin, Durchsetzungsebenen um den Agenten hinzuzufügen, die die Absicht nicht bewerten und nicht durch eine manipulierte Eingabe außer Kraft gesetzt werden.
Statische Anmeldedaten stellen in großem Maßstab einen Single Point of Failure dar.
Mit der zunehmenden Verbreitung von Agenten wächst der Schadensradius einer gemeinsam genutzten Anmeldedaten mit jedem Agenten, der sie verwendet. Eine kompromittierte Konfigurationsdatei gefährdet nicht nur einen Dienst; sie gefährdet jedes System, auf das die Anmeldedaten zugreifen, über jeden Agenten hinweg, der sie verwendet.
Die Antwort ist weder ein intelligentes Agent Framework noch eine neue Art von API-Key. Es ist dieselbe Antwort, die PAM für den menschlichen Privileged Access gegeben hat: Es sollten überhaupt keine Standing Credentials ausgestellt werden. Zugriff Just-in-Time erteilen, auf die Session beschränken, aufzeichnen, was passiert ist, und nach Beendigung der Session nichts hinterlassen, was gestohlen werden kann.
Steuerung von KI-Agenten in der Praxis: Ein Anwendungsfall für SOC-Workflows
Anfang dieses Jahres habe ich eine funktionierende Demo eines KI-gestützten SOC-Workflows erstellt, die es einem Sicherheitsanalysten ermöglichte, über eine Chat-Schnittstelle einen Agenten anzuweisen, einen auf unserer Laborinfrastruktur laufenden Produktionsserver zu untersuchen. Der Agent hatte keine Standing Credentials für die Produktionsumgebung.
Wir haben die Session von Anfang bis Ende aufgezeichnet. Als der Analyst die Session initiierte, lief die folgende Abfolge von Events ab:
- Der Analyst authentifizierte sich über Okta mit MFA – eine echte Identity-Assertion, kein Service-Token.
- Der Agent führte einen OAuth 2.0 Token Exchange (RFC 8693) durch, also den Delegierungsschritt, der ein Token erzeugt, das sowohl die Identity des Menschen (sub = firstname.lastname@com.com) als auch die Identity des Agenten (cid = ag_ir_forensic_7f3a2) enthält. Beide vorhanden, keines ausgelassen. Der Mensch musste anwesend sein, damit dieses Token existieren konnte.
- Okta Privileged Access (OPA) hat das Token anhand des konfigurierten Workload-Konnektors und der Richtlinie validiert, um zu bestätigen, dass der Agent autorisiert war, unter diesen Bedingungen auf diese Serverklasse zuzugreifen.
- OPA stellte ein kurzlebiges SSH-Zertifikat über den PAM-Client aus, der eine verschlüsselte Payload empfing, die Verbindung über das OPA-Gateway vermittelte und dort die Entschlüsselung übernahm. Der Agent enthielt nie lesbare Anmeldedaten.
- Der Agent stellte eine Verbindung über das Okta Privileged Access Gateway her, das der einzige Netzwerkpfad in die Produktionsumgebung ist. Die Produktions-Hosts waren von den Compute-Ressourcen des Agents nicht direkt erreichbar; das Gateway war der einzige Zugang, und dies nur für richtlinienkonforme Sessions.
Verstrichene Gesamtzeit vom Browser des Analysten bis zu einer gesicherten Shell auf einem Produktionsserver: 37 Sekunden.
Der Agent fand beim ersten Befehl eine Reverse Shell, führte nc als root aus und stellte eine Rückverbindung zu einer externen IP-Adresse her. Das ist der Anwendungsfall: Schnell, kontrolliert und vollständig auditiert.
Wie JIT-Zugriff Standing Privileges für KI-Agenten eliminiert
Einige Details in diesem Flow sollten genauer betrachtet werden. Zunächst erfolgt der JIT-Zugriff hier auf zwei Ebenen:
- OPA hat ein kurzlebiges SSH-Zertifikat ausgestellt, das auf diese Session beschränkt ist.
- OPA stellte für diese Session außerdem einen lokalen Betriebssystem-Account auf dem Produktions-Host bereit, der am Ende der Session entfernt wurde. Auf dem Host befand sich kein persistentes Account, das darauf wartete, kompromittiert zu werden.
Durchsetzung des Least-Privilege-Prinzips mit Sudo-Richtlinien zur Laufzeit
Die Sudo-Erzwingung zur Laufzeit verdient eine eigene Erwähnung als die Maßnahme, die das adressiert, wovor sich die meisten Menschen bei Agenten in der Produktion tatsächlich fürchten: kursierende Geschichten über Agenten, die außer Kontrolle geraten, Datenbanken löschen und Dateien überschreiben. Diese Szenarien erfordern Schreibzugriff. Unser forensischer Agent benötigte Produktionszugriff, arbeitete jedoch im schreibgeschützten Modus, und die zentral verwaltete sudo-Richtlinie von OPA setzte dies auf OS-Ebene durch – nicht durch einen System-Prompt, nicht durch Anwendungslogik und nicht durch das eigene Ermessen des Agenten darüber, was angemessen ist.
Aber die Richtlinie blockierte nicht nur destruktives Verhalten. Es setzte die spezifische Grenze dessen durch, was dieser Agent hätte tun sollen, was selbst für Leseoperationen von Bedeutung ist. Bei Tests fing die eigene Logik des LLMs Anfragen an den Agenten, /etc/shadow zu lesen, zuverlässig ab; es war offensichtlich genug, dass die weiche Grenze standhielt.
Allerdings war es etwas anderes, den Agenten aufzufordern, die Speicherabbildung eines Prozesses zu analysieren. Da diese Anfrage forensisch plausibel und nicht destruktiv war, erklärte sich die Logikschicht des Agenten nach einigen Versuchen bereit, sie auszuführen. Die sudo-Richtlinie von OPA hat es trotzdem blockiert. Es geht nicht darum, dass das LLM versagt hat; es geht darum, dass die Richtlinie nicht davon abhängt, dass das LLM richtig liegt. Die Person, die das sudo-Bundle erstellt hat, hat sich genau überlegt, worauf ein SOC-Analyst zugreifen sollte und worauf nicht. Diese Entscheidung wird zur Laufzeit durchgesetzt, unabhängig davon, was der Agent für angemessen hält.
Verknüpfung der menschlichen Identity im PAM-Audit-Log
Der Audit-Trail ist hier ebenfalls von Bedeutung. Das Okta System Log enthält sieben Events für diese Session, vom SSO-Login des Analysten bis zum SSH-Login auf dem Produktionsserver. Jedes Event ist verknüpft. Die menschliche Benutzer:in-ID ist in der gesamten Kette vorhanden.
Der WorkloadPrincipal in den PAM-Ereignissen ist nicht einfach nur "ein Agent", er ist opa://pam-fbach/IR-Forensic-Agent/firstname.lastname@com.com (das Team, dem dieser Agent gehört, der Richtlinienkontext, unter dem er ausgeführt wurde, und die Person, die ihn autorisiert hat). Alle drei in einem PAM-Protokollfeld. Die E-Mail-Adresse der Person befindet sich im PAM-Datensatz, da sie im Token enthalten war und aus demselben Identity-System stammte, das den Analysten ursprünglich authentifiziert hat.
Das ist das Thema Verantwortlichkeit. Nicht "ein Agent hat auf den Server zugegriffen", sondern stattdessen: "Firstnames Agent hat auf den Server zugegriffen, hier ist das verwendete Zertifikat, hier ist die Aufzeichnung einer Session, hier ist jedes Token in der Kette, das dies autorisiert hat."
Warum die Identity-Anbieter-Grundlage nicht optional ist
An dieser Stelle möchte ich ein gezielteres Argument für Sicherheitsarchitekten vorbringen, die PAM-Anbieter evaluieren.
Viele Enterprise-PAM-Anbieter unterstützen die Authentifizierung über JSON Web Token (JWT). Viele unterstützen die JWT/OIDC-Authentifizierung und ermöglichen es Ihnen, Claims Richtlinien zuzuordnen. Das funktioniert zwar, aber "das JWT zu akzeptieren" und "die Identity nativ zu verstehen" sind nicht dasselbe.
Wenn der Identity-Anbieter (IdP) und PAM dieselbe Platform sind, unterscheiden sich einige Dinge strukturell:
- Die Registrierung des Agenten befindet sich im Identity-Anbieter: Der Workload-Konnektor von OPA bindet sich an die
ciddes Agenten – nicht an eine Zeichenfolge in einer Richtlinien-Konfigurationsdatei, sondern an eine Live-Referenz auf einen registrierten Principal. Die Deprovisionierung des Agenten in Okta entzieht den Zugriff. - Der Audit-Trail ist ein einziger Datenstrom: Das SSO-Event des Analysten, die Token-Erteilung, die Ausstellung der PAM-Anmeldedaten, der SSH-Login – sie alle befinden sich im Okta System Log und können gemeinsam abgefragt werden. Mit einem separaten PAM-Anbieter führen Sie zwei Audit-Systeme zusammen, um zu rekonstruieren, was passiert ist.
- Die menschliche Identity im PAM-Datensatz ist kein zugeordneter Claim, der eine Übergabe überstanden hat: Es ist dieselbe Identity, die zu Beginn der Kette authentifiziert wurde und die Vertrauensgrenze der Plattform nie verlässt.
Für den privilegierten menschlichen Zugriff war die Identity-Anbieter-PAM-Integration praktisch, da sie SSO in Ihrer PAM-Konsole und möglicherweise die SCIM-Provisionierung ermöglichte. Für den Zugriff von KI-Agenten ist dies jedoch ein Architekturproblem. Die Nachvollziehbarkeit hängt davon ab, dass die menschliche Identity von der Authentifizierung über die Delegierung bis hin zum Zugriff intakt übertragen wird, und jede Vertrauensgrenze, die sie überschreitet, birgt das Risiko, dass sie verloren geht, falsch zugeordnet oder schlichtweg nicht protokolliert wird.
Dieses architektonische Problem gilt nicht nur für den privilegierten Infrastrukturzugriff.
Der oben beschriebene SOC-Workflow ist keine einmalige Integration, da er eine Ausprägung einer umfassenderen Architektur darstellt. Okta for AI Agents beantwortet drei Fragen, vor denen jedes Sicherheitsteam bei der Bereitstellung von Agenten steht: Wo befinden sich meine Agenten? Womit können sie sich verbinden? Was können sie tun?
Okta Privileged Access ist unsere Antwort auf die dritte Frage für die Ziele mit dem höchsten Risiko: Produktionsinfrastruktur, sensible Systeme und überall dort, wo ein kompromittierter oder manipulierter Agent echten Schaden anrichten könnte. Die gleichen Prinzipien, die das Paar (Mensch, Agent) im OPA-Flow steuern – nämlich an jede Aktion gebundener Benutzerkontext, Least-Privilege-Bereiche, kurzlebige Anmeldedaten und ein unveränderlicher Audit-Trail –, erstrecken sich über MCP-Server, SaaS-APIs, Agent-zu-Agent-Aufrufe und authentifizierte Dienstverbindungen. Agentenbasierter Zugriff auf einen Produktionsserver ist genau der Fall, bei dem Fehler am teuersten sind, weshalb die Identity-Anbieter-PAM-Grundlage wichtig ist, bevor die Anzahl der Agenten außer Kontrolle gerät.
Fazit
KI-Agenten sind die neuen privilegierten Prinzipale in der Unternehmensinfrastruktur. Das Bedrohungsmodell ist bekannt: Standing Credentials, überprivilegierte Konten, kein Audit-Trail. Der Unterschied bei Agenten besteht darin, dass diese Probleme schneller auftreten und schwerer zu erkennen sind.
Die Grundprinzipien, auf denen PAM aufbaut – wie JIT-Zugriff, Aufzeichnung einer Session, Anmeldedaten-Vaulting, die Durchsetzung von Richtlinien und Kontrollen zur Rechteausweitung –, werden nicht weniger relevant, wenn der Principal eine KI ist. Sie werden zu dem, was die Bereitstellung von agentenbasiertem Zugriff überhaupt erst sicher macht.
Was sich weiterentwickeln muss, ist das Identity-Modell. Der Principal ist nun ein (Mensch, Agent)-Paar. Beide Identitäten sollten im Datensatz enthalten sein. Die nachträgliche Rekonstruktion der Verantwortlichkeit, wie etwa "wessen Agent war das und wer hat ihn autorisiert?" erfordert, dass die Platform dieses Paar von Anfang an versteht und es nicht aus Logs über zwei Systeme hinweg wieder zusammensetzt.
Wenn Ihre aktuelle PAM-Architektur den Zugriff durch Agenten als ein Service-Account-Problem behandelt, lohnt es sich zu hinterfragen, ob sie für eine Welt konzipiert wurde, in der der Principal zwei Identitäten besitzt, autonom agiert und ein Steuerungssystem benötigt, das sich nicht blind darauf verlässt, was ihm aufgetragen wurde.
Dieses Dokument dient nur zu allgemeinen Informationszwecken. Die hier enthaltenen Informationen stellen keine Rechts-, Datenschutz-, Sicherheits-, Compliance- oder Geschäftsberatung dar. © Okta, Inc. und/oder Partner.
