Neue Forschungsergebnisse von Software Analyst Cyber Research (SACR) und der Stanford Graduate School of Business machen deutlich: Die Einführung von KI-Agenten hat die Sicherheitsarchitekturen überholt, die zu ihrer Eindämmung entwickelt wurden, insbesondere bei KI-Programmen in Unternehmen.
Die Dynamik ist real. Da weltweit über 3 Millionen Agenten im Einsatz sind und Unternehmen jede Woche Tausende neue in Betrieb nehmen, hat sich die Herausforderung im Bereich Sicherheit von der Frage, ob Agenten eingesetzt werden sollen, hin zu der Frage verlagert, wie sie zur Laufzeit gesichert werden können – genau in dem Moment, in dem ein Agent beschließt zu handeln, ein Tool aufruft und auf Unternehmensdaten zugreift.
Der Umfang macht eine manuelle Überwachung unmöglich. Unternehmen nutzen mittlerweile rund 144 nicht-menschliche Identitäten für jeden menschlichen Benutzer:in. Wenn Schatten-Agenten und kurzlebige Instanzen einbezogen werden, kann die Zahl der aktiven Identitäten pro Team in KI-Systemen und -Diensten in die Tausende gehen.
Dennoch waren die Identitätssysteme, die sie verwalten, nie dafür ausgelegt. Wie die Forscher:innen schlussfolgern: „Herkömmliche Identity and Access Management (IAM)-Systeme wurden für zwei Hauptakteure entwickelt: Menschen und deterministische Maschinenidentitäten. KI-Agenten lassen sich keinem der beiden Modelle eindeutig zuordnen“.
Bei der Zusammenarbeit mit Tausenden von Organisationen, die KI-Agenten einsetzen, haben wir festgestellt, dass es bei der richtigen Umsetzung auf drei Fragen ankommt:
- Wo sind meine KI-Agenten?
- Womit können sie sich verbinden?
- Was können sie tun?
Dies sind die wichtigsten Fragen, die Sie mit dem Okta-Konzept für das sichere agentische Unternehmen beantworten können. Organizations, die in die Beantwortung aller drei Fragen investiert haben, sind deutlich besser aufgestellt, um jene Fehler zu erkennen, auf sie zu reagieren und sie einzudämmen, die bei einer Skalierung unvermeidlich sind.
1. Wo sind meine KI-Agenten?
Sie müssen in der Lage sein, Agenten zu entdecken, unabhängig davon, wo sie entwickelt oder bereitgestellt wurden – über SaaS-Plattformen, Browser, Endpoints und aufkommende agentische KI-Ökosysteme hinweg.
Was tatsächlich passiert:
- Organizations entdecken bei ersten Scans Tausende bisher unbekannte Agenten
- Die am schnellsten wachsende Kategorie, Browser-basierte und lokale Entwickler-Agenten (Claude Code, Cursor, Windsurf), ist in den KI-Workflows von Unternehmen am wenigsten sichtbar
- Die Transparenz ist über SaaS-Plattformen, Endpoints und aufkommende Agenten-Ökosysteme hinweg fragmentiert
Dies ist keine Lücke bei den Sicherheitstools. Es ist architektonischer Natur.
Hintergrund
Agenten werden nicht wie herkömmliche Software bereitgestellt. Sie werden überall, von allen und zu jeder Zeit erstellt. Transparenz ist kein einmaliges Inventarisierungsproblem; sie ist ein kontinuierliches Erkennungsproblem.
Was führende Teams anders machen:
- Signale über Browser-, Endpoint-, SaaS-, Netzwerk-, Gateway- und MCP-Ebenen hinweg aggregieren
- Registrieren Sie Agenten bei der Erstellung als vollwertige Identitäten – nicht erst im Nachhinein
- Kontinuierliche Überprüfung des Sicherheitsstatus von Agenten, nicht nur deren Vorhandensein
Die meisten Organisationen haben kein Agenteninventar.
Führende Teams verfügen über eine kontinuierliche Agentenerkennung.
2. Womit können sie sich verbinden?
Sobald ein Agent existiert, wird sein Risiko nicht dadurch definiert, was er ist– es wird durch alles definiert, worauf er zugreifen kann.
Agenten agieren nicht isoliert. Sie verbinden sich mit SaaS-Anwendungen, APIs, Datenbanken, MCP-Servern und anderen Agenten, oft gleichzeitig und in Maschinengeschwindigkeit über KI-Systeme hinweg.
Was tatsächlich passiert:
- Verbindungen, nicht Identitäten, bestimmen den wahren Explosionsradius
- Das MCP (Model Context Protocol) entwickelt sich rasant zur Ausführungs-Ebene für Agenten, und laut den Untersuchungen von SACR ist das Ökosystem derzeit unausgereift: Anmeldedaten im Klartext sind weit verbreitet, die Verbreitung von OAuth bleibt begrenzt und Tool-Poisoning-Angriffe sind hochwirksam
- Viele Organisationen verfügen nicht einmal über eine grundlegende Bestandsaufnahme, welche MCP-Server und -Tools im Einsatz sind
Diese Sicherheitsrisiken sind keine Ausnahmefälle. Dies ist die Ausgangsbasis.
Hintergrund
Ein kompromittierter Agent fällt nicht kontrolliert aus. Es bewegt sich lateral über Systeme hinweg, verkettet Zugriffe über SaaS-Anwendungen, APIs, und Datenspeicher und agiert mit Maschinengeschwindigkeit. Der Explosionsradius ist nicht theoretisch; er ist unmittelbar.
Was führende Teams anders machen:
- Durchsetzung des Least-Privilege-Prinzips für jeden Verbindungspfad (MCP, SaaS, APIs)
- Ersetzen Sie statische Anmeldedaten durch zweckgebundene, kurzlebige und personengebundene Zugriffsrechte
- Sichern Sie Agent-zu-Agent-Interaktionen mit starker Identitätsüberprüfung genauso streng ab wie den Benutzerzugriff
- Protokollieren Sie jede Verbindung in zentralisierten Überwachungs- und Erkennungssystemen
Die meisten Organisationen verwalten den Zugriff.
Führende Teams kontrollieren Verbindungswege.
3. Was können sie tun?
Hier scheitert das Modell bei den meisten Organisationen.
Zu wissen, wo sich Agenten befinden und womit sie sich verbinden können, reicht nicht aus – denn Agenten verhalten sich nicht wie herkömmliche Systeme. Wie Lawrence Pingree, Distinguished Analyst at SACR, anmerkt: „Ein Agent kann innerhalb seiner zulässigen Zugriffsgrenzen bleiben und dennoch etwas Unerwartetes, Schädliches oder von seiner ursprünglichen Absicht Abweichendes tun.“
Sie sind nicht deterministisch, adaptiv und in der Lage, auf eine Weise zu handeln, die nicht explizit vordefiniert wurde.
Was tatsächlich passiert:
- Agenten verhalten sich nichtdeterministisch und passen sich basierend auf Eingaben, Kontext, Tools und KI-Fähigkeiten an
- Dieselbe Aktion kann in einem Kontext sicher und in einem anderen gefährlich sein
- Sicherheitsentscheidungen werden immer noch bei der Zugriffsgewährung getroffen, nicht bei der Ausführung
Dies ist die eigentliche Schwachstelle – und sie macht eine Sicherheitsarchitektur für KI-Agenten erforderlich.
Hintergrund
Herkömmliche Sicherheit fragt: „Ist diese Person autorisiert, diesen Code auszuführen?“ Die Laufzeit-Identitätssicherheit für Agenten wirft eine schwierigere Frage auf: „Sollte dieser Code ausgeführt werden, selbst wenn dieser Agent autorisiert ist?“
Der Übergang von der Zugriffskontrolle zur Absichtsbewertung und Verhaltensanalyse macht die alleinige deterministische Governance unzureichend.
Was führende Teams anders machen:
- Durchsetzung einer kontextbezogenen Echtzeit-Autorisierung bei der Ausführung
- Bewerten Sie Absicht, Abfolge und Verhaltensmuster – nicht nur Berechtigungen
- Führen Sie Human-in-the-Loop-Genehmigungen für sensible Aktionen ein.
- Überwachen Sie kontinuierlich Verhaltensabweichungen und Anomalien
- Implementieren Sie Not-Aus-Schalter und dynamische Eskalation, um riskante Aktionen sofort zu stoppen
Die meisten Organisationen setzen Berechtigungen durch.
Führende Teams steuern das Verhalten in Echtzeit.
Was CISOs jetzt tun sollten
Die Untersuchung von SACR bietet klare Leitlinien für Sicherheitsverantwortliche, die ihren Ansatz zur Sicherheit von agentischer KI bewerten:
- Beginnen Sie mit deterministischer Governance – aber belassen Sie es nicht dabei. Richtlinienbasierte Zugriffskontrolle ist die Grundlage, aber sie reicht nicht aus. Arbeiten Sie auf verhaltensbasierte Transparenz und dynamische Durchsetzung hin.
- Investieren Sie in Beobachtbarkeit vor nicht-deterministischer Governance. Die Qualität Ihrer Sicherheitsentscheidungen hängt von der Qualität Ihrer Daten ab. Sie können keine guten Autorisierungsentscheidungen zur Laufzeit treffen, ohne zu verstehen, was Agenten tatsächlich tun.
- Treffen Sie eine explizite Entscheidung über nicht-deterministische Governance. Absichtsbasierte Autorisierung und dynamische Steuerung sind keine standardmäßigen nächsten Schritte – sie erfordern Investitionen in die Architektur. Entscheiden Sie jetzt, ob Sie darauf hinarbeiten oder das Risiko statischer Kontrollen in Kauf nehmen.
- Bewerten Sie Ihre Agenten-Archetypen, bevor Sie einen Anbieter auswählen. Selbst entwickelte Agenten, in SaaS-Lösungen integrierte Agenten und lokal auf der Entwicklungsseite genutzte Agenten haben grundlegend unterschiedliche Sicherheitsanforderungen. Analysieren Sie Ihren eigenen Mix, bevor Sie sich für eine Plattform entscheiden.
- Behandeln Sie die MCP-Sicherheit als eigenständige Anforderung. MCP wird zur Ausführungsebene für Agenten, nicht nur zu einem Integrationsstandard, sondern zu einer Live-Steuerungsoberfläche für das Agentenverhalten. Wenn Ihr Anbieter keinen Plan zur Absicherung des MCP-Datenverkehrs hat, haben Sie eine Sicherheitslücke.
Oktas Ansatz zur Sicherheit von KI-Agenten
Die Untersuchung von SACR bestätigt, dass Okta eine grundlegend andere Ausgangsposition hat als andere Anbieter in diesem Bereich: Als Identity-Anbieter, dem bereits 19.000 Organisationen vertrauen, wird die Agentensicherheit zu einer Erweiterung der bestehenden Infrastruktur für Enterprise-KI und nicht zu einer neuen Einzellösung.
Der Ansatz von Okta lässt sich direkt auf die drei Fragen abgleichen:
- Wo sind meine Agenten? Identity Security Posture Management (ISPM), das ab sofort allgemein verfügbar ist, kombiniert mit dem Secure Access Monitor-Plugin (im Early Access verfügbar), welches OAuth-Berechtigungen im Browser, Aktivitäten von Claude Code sowie Aufrufe von MCP-Servern erfasst.
- Womit können sie sich verbinden? Der Identity Assertion Grant (ID-JAG) – ein offener Standard, den Okta mitentwickelt hat – bindet Agentenberechtigungen an die bestehenden Zugriffsrechte der jeweiligen Benutzer:in, mit einer dreistufigen Autorisierung, die den Benutzerkontext, OAuth-Scopes und eine fein abgestimmte Richtlinie über fga.dev umfasst.
- Was können sie tun? CIBA-basierte Human-in-the-Loop-Genehmigungs-Workflows, globaler Token-Widerruf, vollständige Audit-Trails und kommende Hard-Stop-Funktionen pro Agent.
Wie der Bericht schlussfolgert, ist das stärkste Unterscheidungsmerkmal von Okta die Konsolidierung– eine zentrale Steuerungsebene, die den Tool-Wildwuchs über verschiedene Identitätstypen hinweg beseitigt und das gesamte Spektrum von Agenten mit API-Zugriff im Unternehmen bis hin zu MCP-Clients auf Entwickler-Workstations abdeckt.
Die Unternehmen, die dies frühzeitig erkennen, setzen nicht nur Agenten ein. Sie entwickeln die Systeme, um:
- Entdecken Sie sie
- Kontrollieren Sie ihre Reichweite
- Und in ihr Verhalten eingreifen
Denn im großen Maßstab lautet die Frage nicht, ob Agenten Zugriff haben. Es kommt darauf an, ob Sie sehen können, was sie tun – und es stoppen können, wenn es darauf ankommt.
Weitere Ressourcen:
