Okta AI-Agentensicherheit nimmt die Verwirrung in Unternehmen ins Visier

Okta hat für seinen Vorstoß in die AI-Agentensicherheit einen ungewöhnlichen Gegner ausgemacht: Kundenverwirrung, nicht einen weiteren Sicherheitsanbieter. Präsident und COO Eric Kelleher vertrat diese Ansicht auf der Goldman Sachs Communacopia + Technology Conference am 9. September 2026.

Das Argument spiegelt einen Markt wider, in dem Unternehmen autonome Software wollen, aber Schwierigkeiten haben zu definieren, was abgesichert werden muss. Ein Agent könnte E-Mails zusammenfassen, einen Vertriebsdatensatz aktualisieren, eine Rückerstattung genehmigen oder einen gesamten Finanzworkflow steuern. Jede Rolle bringt unterschiedliche Berechtigungen, Risiken und Anforderungen an die Rechenschaftspflicht mit sich.

Okta möchte, dass Identität zur ordnenden Ebene für dieses Durcheinander wird. Sein Framework stellt drei Fragen: Wo befinden sich die Agenten, womit können sie sich verbinden und was dürfen sie tun? Microsoft verfolgt mit Entra Agent ID und Agent 365 ähnliche Ziele, wodurch die Verbreitung in Unternehmen ebenso wichtig wird wie das Sicherheitsdesign.

Dieser Wettbewerb verändert die Bedeutung von Oktas Botschaft. Verwirrung kann einen Markt für einen unabhängigen Identitätsanbieter eröffnen, sie kann Käufe aber auch verzögern und gebündelte Plattformen begünstigen. Okta muss ein dringliches Sicherheitsnarrativ in wiederholbare Implementierungen, messbare Akzeptanz und Standards verwandeln, die Kunden über verschiedene Anbieter hinweg nutzen können.

Okta AI-Agentensicherheit beginnt mit drei Fragen

Oktas unmittelbarer Ansatz besteht darin, ein weitläufiges Sicherheitsproblem auf Agentenerkennung, Verbindungssteuerung und Autorisierung zu reduzieren.

Während der September-Konferenz beschrieb Kelleher Kunden, die Okta nach beunruhigenden Berichten über autonome Agenten um Hilfe baten. Diese Käufer verstehen, dass Agenten Risiken einführen, doch ihnen fehlt häufig ein gemeinsames Modell zur Bewertung dieser Risiken.

Oktas Antwort ist sein Blueprint for the Secure Agentic Enterprise. Das Unternehmen führte das Framework im März ein und machte Okta for AI Agents am 30. April 2026 allgemein verfügbar. Das Produkt erweitert bekannte Identitätskontrollen auf autonome und teilautonome Software.

Die erste Frage, „Wo sind meine Agenten?“, betrifft Inventarisierung und Verantwortlichkeit. Mitarbeitende können Tools ohne formalen Bereitstellungsprozess aktivieren, während Entwickler Agenten auf zahlreichen Cloud-Plattformen erstellen können. Sicherheitsteams können keinen Agenten steuern, den sie nicht identifizieren können.

Oktas Funktion Agent Discovery soll diese verborgenen Bereitstellungen sichtbar machen. Laut den Details zur Agentenerkennung erkennt sie OAuth-Zustimmungsaktivitäten und identifiziert Verbindungen mit nicht genehmigten Agentenplattformen.

OAuth-Zustimmung erteilt einer Anwendung die Berechtigung, auf einen anderen Dienst zuzugreifen, ohne das Passwort des Nutzers zu erhalten. Dieser Komfort wird riskant, wenn ein Mitarbeitender einem unbekannten Agenten Zugriff auf E-Mails, Dateien, Kalender oder Kundendaten gewährt.

Okta zufolge können Browsersignale die Client-Anwendung, die verbundene Ressource und die angeforderten Berechtigungsbereiche offenlegen. Administratoren können den Agenten dann registrieren, einen menschlichen Verantwortlichen zuweisen und Basisrichtlinien anwenden.

Die zweite Frage, „Womit können sich Agenten verbinden?“, verlagert den Fokus von der Inventarisierung auf Zugriffswege. Ein Agent kann mit Anwendungen, APIs, Datenbanken, Tools oder Model Context Protocol-Servern interagieren. MCP ist eine Standardschnittstelle, über die KI-Systeme auf externe Tools und Informationen zugreifen können.

Oktas Blueprint umfasst ein Gateway zur Vermittlung dieser Verbindungen, eine Verwaltung von Zugangsdaten und API-Zugriffsmanagement. Diese Kontrollen sollen weitreichende, dauerhafte Zugangsdaten durch engere Entscheidungen ersetzen, die auf Identität, Kontext und Risiko beruhen.

Die dritte Frage, „Was dürfen Agenten tun?“, betrifft die schwierigste Ebene. Zu wissen, dass ein Agent ein System betreten kann, sagt nichts darüber aus, ob er Informationen lesen, schreiben, übertragen, genehmigen oder löschen kann.

Okta schlägt vor, einzelne Tool-Aufrufe und Autorisierungsentscheidungen zu protokollieren. Das Unternehmen bewirbt außerdem Universal Logout als Notausschalter, der die Zugriffstokens eines Agenten über verbundene Systeme hinweg widerruft.

Diese Einordnung ist wichtig, weil ein Agent nicht bloß ein weiteres Mitarbeiterkonto ist. Er kann viele Aktionen schnell ausführen, Informationen systemübergreifend kombinieren und sein Verhalten verändern, wenn sich der umgebende Kontext ändert.

Er unterscheidet sich auch von einem herkömmlichen Servicekonto, das üblicherweise eine vorhersehbare automatisierte Aufgabe erledigt. Ein KI-Agent kann Tools auswählen, Zwischenpläne erstellen und über von einem Nutzer delegierte Berechtigungen handeln.

Oktas drei Fragen schaffen daher eine hilfreiche Struktur für Beschaffungsentscheidungen. Sie beweisen nicht, dass jede zugrunde liegende Kontrolle über jede Agentenplattform hinweg funktioniert. Sie geben Sicherheitsverantwortlichen eine gemeinsame Sprache, um zu entscheiden, was getestet werden muss.

Dieser Wortschatz bildet die Grundlage der Unternehmensstrategie. Okta möchte, dass Unternehmen Agentensicherheit als Erweiterung der Identitätsgovernance sehen, nicht als isolierte Kategorie der KI-Überwachung.

Verwirrung schafft sowohl Nachfrage als auch Verzögerungen

Dieselbe Unsicherheit, die Kunden zu Okta bringt, kann Evaluierungen auch verlängern und verhindern, dass Agentensicherheit zu einem planbaren Geschäft wird.

Kelleher bezeichnete Verwirrung als den derzeit größten Wettbewerber des Unternehmens im Bereich agentischer Identität. Käufer sehen sich konkurrierenden Behauptungen von Sicherheitsanbietern, Cloud-Anbietern, KI-Entwicklern und Governance-Plattformen gegenüber. Viele Produkte verwenden eine ähnliche Sprache, schützen jedoch unterschiedliche Ebenen.

Ein Anbieter könnte Prompts auf bösartige Anweisungen prüfen. Ein anderer könnte Maschinenidentitäten oder offengelegte Zugangsdaten erkennen. Ein dritter könnte den Netzwerkverkehr steuern, während ein Identitätsanbieter festlegt, welcher Agent auf eine bestimmte Anwendung zugreifen darf.

Diese Funktionen können sich ergänzen, Unternehmen müssen jedoch weiterhin Verantwortlichkeiten festlegen. Das Sicherheitsteam könnte Zugriffsrichtlinien steuern, während Entwickler den Agenten verantworten und Geschäftsbereiche akzeptable Aktionen definieren.

Die Beschaffung wird schwieriger, wenn eine Organisation grundlegende Fragen zu ihrer Bereitstellung nicht beantworten kann. Ein Unternehmen weiß möglicherweise, dass Mitarbeitende KI-Assistenten nutzen, ohne zu wissen, welche dieser Assistenten dauerhafte Anwendungsberechtigungen besitzen.

Auch die Definitionen von Agenten bleiben uneinheitlich. Einige Systeme sind Chat-Schnittstellen, die Maßnahmen empfehlen. Andere führen Workflows nach menschlicher Genehmigung aus, während autonome Agenten handeln können, ohne jeden Schritt überprüfen zu lassen.

Diese Unklarheit beeinflusst Lizenzierung und Produktmessung. Kelleher sagte, dass Okta sein agentisches Angebot derzeit als Aufpreis auf eine nutzerbasierte Preisgestaltung berechnet. Er räumte ein, dass dieses Modell für Agentenarchitekturen nicht ideal sei, beschrieb es jedoch als für Kunden leicht zu erwerben.

Die meisten frühen Transaktionen sind seinen Aussagen auf der Konferenz zufolge Einjahresverträge. Okta erwartet, dass beide Seiten vor Verlängerungen bessere Informationen über Agentennutzung und Betriebskosten gewinnen werden.

Dieser Ansatz senkt die unmittelbare Kaufhürde. Er zeigt jedoch auch, wie früh der Markt noch ist. Eine reife Sicherheitskategorie verfügt gewöhnlich über klarere Einheiten wie Nutzer, Geräte, Workloads, Transaktionen oder geschütztes Datenvolumen.

Agentenaktivität kann sich über all diese Einheiten erstrecken. Ein Mitarbeitender kann mehrere Agenten nutzen, während ein Agent temporäre Worker erzeugen oder Tausende Tool-Aufrufe ausführen kann. Ein nutzerbasiertes Modell könnte sich von der abzusichernden Arbeitslast entkoppeln.

Oktas Vorteil liegt in den bestehenden Beziehungen zu Identitätsteams in Unternehmen. Kelleher sagte, dass bereits mehr als 20.000 Unternehmen Okta ihre menschlichen und nicht menschlichen Identitäten anvertrauen. Diese installierte Basis bietet einen direkten Weg in Sicherheitsgespräche.

Vertrauen beseitigt jedoch nicht die Implementierungsarbeit. Kunden müssen Agenten erkennen, ihre Zwecke klassifizieren, Verantwortliche identifizieren, übermäßige Berechtigungen reduzieren und relevante Anwendungen mit Durchsetzungspunkten verbinden.

Sicherheitsverantwortliche müssen außerdem entscheiden, welche Aktionen menschliche Genehmigung erfordern. Ein Agent zur Zusammenfassung und ein Quote-to-Cash-Agent sollten nicht identische Kontrollen erhalten, selbst wenn beide dieselbe Identitätsplattform nutzen.

Letzterer könnte Preisgestaltung, Verträge, Abrechnungssysteme und Umsatzdaten berühren. Ein Fehler könnte zu einem Finanz- oder Compliance-Vorfall werden und nicht bloß zu einer unbequemen Antwort.

Diese Unterscheidung verwandelt Verwirrung nur dann in eine Produktchance, wenn Okta die Implementierung anleiten kann. Ein Blueprint hilft Kunden, bessere Fragen zu stellen, doch operative Vorlagen und Integrationen müssen die Antworten liefern.

Diese Anforderung erhöht den Druck auf Oktas Vertriebs- und Professional-Services-Modell. Käufer werden erwarten, dass das Unternehmen ein abstraktes Identitätsframework in Kontrollen für tatsächliche Workflows übersetzt.

Entwickler stehen vor einer verwandten Herausforderung. Sie benötigen sichere Zugriffsmuster, die nicht erfordern, jeden Agenten für das Identitätssystem jedes Kunden neu zu entwickeln. Deshalb steht Oktas Standardsstrategie im Zentrum seines Produktarguments.

Cross App Access ist Oktas Angebot für eine offene Kontrollebene

Okta setzt darauf, dass ein offener Autorisierungsstandard den Zugriff von Agenten portabel machen kann, während Identitätsanbieter als zentrale Durchsetzer von Richtlinien erhalten bleiben.

Cross App Access, kurz XAA, ist Oktas vorgeschlagene Methode, um Agenten über standardisierte Autorisierung mit Anwendungen zu verbinden. Sie erweitert Konzepte aus OAuth und arbeitet mit MCP zusammen, das Agenten einen gemeinsamen Weg bietet, Tools zu entdecken und aufzurufen.

Die Unterscheidung ist wichtig. MCP kann ein verfügbares Tool beschreiben und die Interaktion unterstützen, Unternehmen müssen jedoch weiterhin entscheiden, ob ein bestimmter Agent es nutzen darf. XAA soll Identitäts- und Autorisierungskontext in diese Verbindung übertragen.

Kelleher sagte, Okta habe Cross App Access als offenen Standard und nicht als proprietäres Okta-Format vorgeschlagen. Er sagte außerdem, der Standard sei als Erweiterung von MCP angenommen worden und ziehe breites Brancheninteresse auf sich.

Okta machte Agent SSO im August 2026 allgemein verfügbar. Agent SSO ermöglicht es einem Administrator, einen Agenten als Workload Principal zu registrieren, also als unabhängig verwaltete nicht menschliche Identität.

Wenn sich ein unterstützter Agent mit einer Anwendung verbindet, kann Okta ihn neben anderen verwalteten Identitäten im Universal Directory platzieren. Administratoren können dann Eigentümerschaft, Verbindungen und geltende Richtlinien über bestehende Identitätsprozesse einsehen.

Der Ansatz versucht, eine wiederkehrende Schwäche bei Agentenbereitstellungen zu beheben. Viele frühe Agenten übernehmen das Zugriffstoken eines Nutzers oder verlassen sich auf statische Zugangsdaten, die in einem Workflow gespeichert sind.

Übernommene Zugriffe können die Zuordnung unklar machen. Wenn ein Agent einen Datensatz unter der Identität eines Mitarbeitenden ändert, kann ein Auditprotokoll möglicherweise nicht zwischen einer Softwareaktion und einer direkten menschlichen Handlung unterscheiden.

Statische Zugangsdaten schaffen ein weiteres Problem. Sie können länger als erforderlich aktiv bleiben und in Konfigurationsdateien, Protokollen oder Entwicklungsumgebungen auftauchen. Ein offengelegtes Geheimnis kann einem Angreifer dauerhaften Zugriff verschaffen.

Eine dedizierte Agentenidentität trennt den Akteur von seinem Auftraggeber. Der geschäftliche Verantwortliche bleibt rechenschaftspflichtig, das Sicherheitssystem kann jedoch unterschiedliche Richtlinien auf den Agenten und die Person anwenden.

Diese Trennung unterstützt das Prinzip der minimalen Berechtigung, das eine Identität auf den für ihre zugewiesene Aufgabe notwendigen Mindestzugriff beschränkt. Sie kann auch kürzerlebige Tokens und eine klarere Stilllegung unterstützen, wenn ein Agent außer Betrieb genommen wird.

Okta zufolge kann Auth0 for AI Agents Entwicklern dabei helfen, Agenten zu erstellen, die mit XAA funktionieren. Diese Agenten können Zugangsdaten bei unterschiedlichen Identitätsanbietern speichern, statt eine reine Okta-Umgebung vorauszusetzen.

Offenheit stärkt Oktas Argument gegenüber Kunden, die sich Sorgen über Plattformbindung machen. Ein Unternehmen kann Agenten von Microsoft, Google, Salesforce, eigenen Entwicklungsteams und kleineren Anbietern innerhalb derselben Umgebung einsetzen.

Eine portable Autorisierungsebene würde es diesen Agenten ermöglichen, auf konsistente Zugriffsentscheidungen zu treffen. Sie könnte zudem den Aufwand für individuelle Integrationen für Entwickler verringern, die an Unternehmen mit unterschiedlichen Identitätssystemen verkaufen.

Doch ein veröffentlichter Standard schafft nicht automatisch Interoperabilität. Anwendungen müssen ihn implementieren, Agenten-Frameworks müssen den erforderlichen Kontext mitführen, und Identitätsanbieter müssen Anfragen einheitlich interpretieren.

Sicherheitsteams müssen außerdem den Metadaten vertrauen können, die jeder Entscheidung zugrunde liegen. Ein Agent kann über eine gültige Identität verfügen und dennoch manipulierte Anweisungen erhalten oder eine unsichere Aktion auswählen.

Identität beantwortet, wer oder was Zugriff anfordert. Sie bestimmt nicht eigenständig, ob ein generierter Plan korrekt, ethisch oder mit der Geschäftsabsicht vereinbar ist.

Oktas Mechanismus ist daher bedeutsam, aber begrenzt. XAA kann Autorisierung expliziter und auditierbar machen. Es kann jedoch weder Schutzmaßnahmen für Modelle, Data Governance, Netzwerkkontrollen noch eine Validierung auf Anwendungsebene ersetzen.

Das Unternehmen profitiert, wenn XAA zu einem neutralen Verbindungsstandard wird. Es gerät stärker unter Druck, wenn Agentenplattformen die Durchsetzung von Identitätsregeln in ihren eigenen gebündelten Kontrollumgebungen behalten.

Dieser Druck zeigt sich bereits in Microsofts wachsendem Stack für Agentenidentitäten.

Microsoft macht Identitätssicherheit zu einem Vertriebswettbewerb

Oktas wichtigste Wettbewerbsherausforderung ist Microsofts Fähigkeit, Agentenidentität mit den Anwendungen, Cloud-Diensten und Verwaltungstools zu bündeln, die Unternehmen bereits nutzen.

Microsoft Entra Agent ID wurde im April 2026 allgemein verfügbar. Es bietet Identitätskonstrukte, Authentifizierung, Autorisierung, Governance und Sicherheitskontrollen, die für KI-Agenten ausgelegt sind.

Das zugrunde liegende Argument ähnelt stark dem von Okta. Agenten sollten identifizierbare Verantwortliche, verwaltete Lebenszyklen, begrenzte Zugriffsrechte und auditierbare Aktivitäten haben. Microsoft unterstützt ebenfalls OAuth, MCP und Agent-zu-Agent-Protokolle.

Der Unterschied liegt im Vertrieb. Microsoft kontrolliert eine große Sammlung von Geschäftsanwendungen, Entwicklerdiensten, Cloud-Infrastruktur, Datenplattformen und Sicherheitsprodukten.

Agent 365 dient als einheitlicher Katalog und Verwaltungsebene des Unternehmens. Entra stellt laut Microsofts Dokumentation zu Agentenidentitäten das darunterliegende Identitätsfundament bereit.

Microsoft kann eine Agentenidentität mit Conditional Access, Identity Protection, Microsoft Graph und seiner umfassenderen Governance-Umgebung verbinden. Kunden, die bereits innerhalb dieses Stacks arbeiten, bevorzugen möglicherweise eine konsolidierte Verwaltungserfahrung.

Ein praktisches Beispiel zeigt sich in Microsofts Dataverse-Integration. Ein Vertriebsentwicklungsagent kann eine eigene Identität und eine begrenzte Rolle erhalten, um Leads zu lesen, Kontaktaufnahmen zu erfassen und zulässige Datensätze zu aktualisieren.

Administratoren können nicht relevante Tabellen oder sensible Felder ausschließen. Aktionen bleiben dem Agenten zuordenbar, statt unter einem gemeinsamen Mitarbeiter- oder Anwendungskonto zu erscheinen.

Dieses Szenario verdeutlicht das strategische Risiko für Okta. Microsoft muss Agentenidentität nicht als eigene Kategorie verkaufen, wenn es Governance in die Anwendung einbetten kann, in der die Arbeit stattfindet.

Oktas Antwort ist Unabhängigkeit. Sein Wert steigt, wenn ein Unternehmen mehrere Clouds, Agenten-Builder und Software-Ökosysteme nutzt. Eine neutrale Identitätsebene kann über diese Grenzen hinweg konsistente Richtlinien bieten.

Kelleher betonte, dass agentische Identität Eigenschaften menschlicher und nicht menschlicher Identität vereint. Okta verwaltet bereits beide Kategorien und verfügt damit über Erfahrung mit Lifecycle-Governance, Anwendungszugriff und Sicherheitssignalen.

Auch sein Integrationskatalog verschafft dem Unternehmen einen erheblichen Ausgangspunkt. Okta erklärte im März, sein Netzwerk umfasse mehr als 8.200 Integrationen; die Unterstützung für Agenten beziehe Boomi, DataRobot und Google Vertex AI ein.

Diese Breite ist nur dann relevant, wenn Integrationen eine substanzielle Durchsetzung ermöglichen. Ein Katalogeintrag, der einen Agenten registriert, unterscheidet sich von einem, der einzelne Tool-Aufrufe autorisiert und einen schnellen Entzug von Zugriffsrechten unterstützt.

Microsoft steht innerhalb seines Ökosystems vor derselben Prüfung. Zentralisierte Identität kann Berechtigungen beschreiben, doch Anwendungen müssen diese Berechtigungen während schneller, mehrstufiger Workflows korrekt durchsetzen.

Weitere Sicherheitsanbieter fügen eine zusätzliche Wettbewerbsebene hinzu. Anbieter für privilegierten Zugriff können sensible Anmeldedaten verwalten, während Anbieter für Endpunkt- und Cloud-Sicherheit das Verhalten rund um einen Agenten analysieren können.

Spezialisten für KI-Sicherheit könnten sich auf Prompt Injection, unsichere Tool-Auswahl, Datenabfluss und Modellverhalten konzentrieren. Diese Bedrohungen verschwinden nicht, nachdem der Agent eine eigene Identität erhalten hat.

Die wahrscheinliche Unternehmensarchitektur wird mehrere Kontrollebenen umfassen. Die umkämpfte Frage ist, welche Plattform zum zentralen Ort für Verantwortlichkeit, Richtlinien und Untersuchungen wird.

Okta möchte, dass dieser Ort das Identitätssicherheitsgeflecht ist. Microsoft möchte, dass Agent 365 und Entra eine einheitliche Kontrollumgebung bereitstellen, insbesondere über Microsoft-Anwendungen hinweg.

Kunden werden diese Behauptungen in gemischten Umgebungen bewerten. Eine Plattform, die nur ihre eigenen nativen Agenten steuert, hinterlässt Sicherheitsteams fragmentierte Bestände und Richtlinien.

Oktas Unabhängigkeit bietet eine glaubwürdige Antwort auf Fragmentierung. Microsofts Integrationstiefe bietet eine glaubwürdige Antwort auf operative Komplexität.

Dies ist der Hauptwettstreit des Artikels: eine neutrale Identitätsebene gegen eine gebündelte Kontrollumgebung für Anwendungen und Cloud. Verwirrung hilft Okta dabei, das Gespräch zu beginnen, doch Interoperabilität wird bestimmen, wer es kontrolliert.

Identitätskontrollen können die Absicht eines Agenten nicht beurteilen

Okta kann einschränken, worauf ein Agent zugreifen darf, doch gültige Anmeldedaten garantieren weder sicheres Schlussfolgern noch korrektes Handeln.

Ein Agent kann sich erfolgreich authentifizieren und innerhalb eines genehmigten Berechtigungsumfangs bleiben, während er dennoch Schaden anrichtet. Er kann eine Anfrage falsch interpretieren, einer böswilligen Anweisung folgen oder zulässige Aktionen zu einem unbeabsichtigten Ergebnis kombinieren.

Prompt Injection verdeutlicht diese Lücke. Ein Angreifer kann verdeckte oder irreführende Anweisungen in Inhalte einfügen, die ein Agent liest. Der Agent könnte diese Anweisungen als Teil seiner Aufgabe behandeln.

Identitätskontrollen können den daraus resultierenden Schadensradius begrenzen. Sie können jedoch nicht immer erkennen, dass der Entscheidungsprozess des Agenten manipuliert wurde.

Dieselbe Einschränkung gilt für fehlerhafte Planung. Ein autorisierter Finanzagent könnte das falsche Konto auswählen, eine Aktion duplizieren oder eine Genehmigungsregel auf die falsche Transaktion anwenden.

Ein Notausschalter wird wertvoll, nachdem verdächtiges Verhalten erkannt wurde. Autonome Agenten können jedoch viele Aktionen ausführen, bevor ein Mensch das Muster erkennt und den Zugriff widerruft.

Laufzeitautorisierung versucht, dieses Zeitfenster einzugrenzen. Statt weitreichenden dauerhaften Zugriff zu gewähren, bewertet ein System einzelne Anfragen anhand von Identität, Kontext, Risiko und beabsichtigter Aktion.

Die Qualität dieser Bewertung hängt von zuverlässigem Kontext ab. Richtlinien müssen gewöhnliche Abweichungen von unsicherem Verhalten unterscheiden, ohne legitime Workflows zu blockieren.

Organisationen benötigen zudem vertrauenswürdige Protokolle. Die Aufzeichnung der Tool-Aufrufe eines Agenten hilft Ermittlern bei der Rekonstruktion von Ereignissen, doch Protokolle müssen Agent, menschlichen Sponsor, Anweisung, Autorisierungsentscheidung und resultierende Änderung miteinander verknüpfen.

Ein Eintrag, der nur einen erfolgreichen API-Aufruf zeigt, bietet begrenzte Rechenschaftspflicht. Sicherheitsteams müssen wissen, warum der Agent die API aufgerufen hat und welche Daten seine Entscheidung geprägt haben.

Oktas System-Log- und Governance-Funktionen decken Teile dieser Kette ab. Das Unternehmen erklärt, dass Tool-Aufrufe, Zugriffsversuche und Autorisierungsentscheidungen in Systeme für Sicherheitsinformationen und Ereignismanagement fließen können.

Diese Fähigkeiten bleiben Unternehmensbehauptungen, bis Kunden sie über verschiedene Agenten-Frameworks und Anwendungen hinweg testen. Oktas eigene Ankündigung warnt zudem, dass unveröffentlichte Funktionen verspätet oder gar nicht verfügbar werden könnten.

Unabhängige Belege bleiben begrenzt, weil Unternehmensbereitstellungen von Agenten noch jung sind. Die akademische Forschung hat begonnen, Identitätsmanagement für agentische Systeme zu untersuchen, doch Produktions-Benchmarks entwickeln sich noch.

Ein weiteres Problem ist die Qualität der Verantwortlichkeit. Die Zuweisung eines menschlichen Sponsors schafft auf dem Papier Rechenschaftspflicht, doch diese Person muss die Daten, Berechtigungen, Abhängigkeiten und Ausmusterungsbedingungen des Agenten verstehen.

Verantwortlichkeit kann zu einer bloßen Formalität werden, wenn Organisationen Agenten schneller bereitstellen, als Manager sie prüfen können. Zugriffsrezertifizierungen drohen dann zu einer weiteren Genehmigungswarteschlange mit unzureichendem Kontext zu werden.

Die Ausbreitung von Agenten verschärft das Problem. Ein primärer Agent kann temporäre Subagenten für Recherche, Analyse oder Ausführung erstellen. Sicherheitsrichtlinien müssen festlegen, ob diese temporären Identitäten Berechtigungen erben.

Eine weitreichende Vererbung ist leicht zu verwalten, erhöht jedoch die Angriffsfläche. Für jeden kurzlebigen Agenten eine separate Genehmigung zu verlangen, kann die Geschwindigkeit untergraben, die agentische Workflows attraktiv macht.

Dies ist der zentrale Zielkonflikt bei Oktas KI-Agentensicherheit. Unternehmen möchten, dass Agenten schnell über Systeme hinweg arbeiten, während Sicherheitsteams sicherstellen müssen, dass jede Aktion begrenzt, zuordenbar und rückgängig zu machen bleibt.

Zu wenig Kontrolle schafft inakzeptable Risiken. Zu viel Reibung verwandelt einen autonomen Workflow wieder in eine langsame Abfolge menschlicher Genehmigungen.

Die stärksten Bereitstellungen beginnen mit eng abgegrenzten Aufgaben und expliziten Datengrenzen. Ein Support-Agent könnte Tickets klassifizieren, bevor er die Berechtigung erhält, Gutschriften auszustellen oder Kundendaten zu ändern.

Teams sollten Fehlerpfade testen, nicht nur erfolgreiche Demonstrationen. Sie benötigen Belege dafür, wie das System mit abgelaufener Verantwortlichkeit, manipulierten Eingaben, übermäßigen Berechtigungen und nicht verfügbaren Durchsetzungsdiensten umgeht.

Eine durchsuchbare Wissensdatenbank kann Teams dabei helfen, Verantwortliche, Richtlinien und Entscheidungen zu Vorfällen zu dokumentieren. Sie ersetzt keine Zugriffskontrolle, bewahrt jedoch den Kontext, den Prüfer benötigen.

Oktas Strategie wird überzeugender, wenn Kunden Identitätsentscheidungen mit geringeren Berechtigungen und einer schnelleren Eindämmung von Vorfällen verknüpfen können. Produktankündigungen allein können dieses Ergebnis nicht belegen.

Drei Signale werden zeigen, ob Oktas Vorstoß funktioniert

Standardadoption, Kundenausbau und plattformübergreifende Durchsetzung werden bestimmen, ob Okta Verwirrung in eine dauerhafte Kategorie für Identitätssicherheit verwandelt.

Das erste Signal ist die Einführung von Cross App Access über Oktas eigene Produkte hinaus. Agentenentwickler, Anwendungsanbieter und konkurrierende Identitätsanbieter müssen das Protokoll implementieren, damit es zu sinnvoller Infrastruktur wird.

Okta erklärte auf der September-Konferenz, dass umfassendere Ankündigungen bevorstünden. Das wichtige Detail wird nicht die Zahl der genannten Partner sein. Käufer sollten prüfen, welche Aktionen diese Integrationen tatsächlich autorisieren können.

Unterstützung für die Registrierung schafft Bestandstransparenz. Unterstützung für bereichsbezogene, kontextuelle Autorisierung schafft Kontrolle. Unterstützung für schnellen Widerruf sorgt für Eindämmung, wenn ein Agent von seiner vorgesehenen Rolle abweicht.

Eine wachsende Zahl funktionierender Integrationen würde Oktas Argument einer neutralen Plattform stärken. Begrenzte Einführung würde XAA als nützliche Funktion innerhalb der Okta-Umgebung belassen, statt als branchenweite Kontrollebene.

Das zweite Signal ist die Form von Kundenverlängerungen und -ausweitungen. Kelleher sagte, die meisten frühen agentischen Transaktionen hätten Laufzeiten von einem Jahr, wodurch Kunden und Okta Zeit erhielten, die Nutzung zu verstehen.

Diese Verlängerungen werden zeigen, ob Unternehmen über die Evaluierung hinausgehen. Käufer sollten nach Bereitstellungen suchen, die Produktionsagenten über mehrere Geschäftsprozesse hinweg steuern, nicht nach isolierten Demonstrationen.

Eine Ausweitung auf zusätzliche Agentenplattformen würde die Behauptung stützen, dass Identität eine gemeinsame Kontrollumgebung bietet. Wachstum, das ausschließlich an experimentelle Projekte gebunden ist, würde darauf hindeuten, dass Verwirrung weiterhin eine Vertriebshürde bleibt.

Die Preisgestaltung wird einen weiteren Hinweis liefern. Oktas Aufschlag pro Nutzer vereinfacht Erstkäufe, doch Agentenvolumen und -aktivität folgen nicht zwangsläufig der Zahl der Mitarbeiter.

Das Modell könnte sich in Richtung geschützter Agenten, Verbindungen, Transaktionen oder Autorisierungsereignisse entwickeln. Jede Änderung wird zeigen, was Kunden wertschätzen und welche Betriebskosten am wichtigsten sind.

Ein stabiles, verständliches Modell würde der Kategorie helfen, zu reifen. Komplexe nutzungsbasierte Preise könnten die Unsicherheit wieder einführen, die Okta mit seinem Blueprint beseitigen will.

Das dritte Signal ist die Reaktion von Microsoft und anderen Identitätsanbietern im Wettbewerb. Das Agent 365 model von Microsoft kombiniert bereits ein einheitliches Inventar mit Entra-gestützter Identität und Governance.

Wenn Microsoft die einfache Governance für Drittanbieter-Agenten ausbaut, wird Otkas Anspruch auf Unabhängigkeit direkt auf die Probe gestellt. Bleibt Microsoft vor allem innerhalb seiner eigenen Umgebung stark, gewinnt Okta Spielraum in heterogenen Unternehmen.

Kunden sollten die Durchsetzung über Microsoft 365, Google Workspace, Salesforce, Cloud-Plattformen und kundenspezifische Anwendungen hinweg vergleichen. Der Gewinner wird mehr als eine zentrale Agentenliste benötigen.

Er muss die Agentenidentität über Anwendungsgrenzen hinweg bewahren, Least Privilege anwenden, Verantwortlichkeiten offenlegen und Zugriffe konsistent beenden. Außerdem muss er Nachweise liefern, die Sicherheitsteams bei Untersuchungen und Audits verwenden können.

Die Unterstützung gemeinsamer Standards durch Wettbewerber würde Otkas umfassendere These bestätigen, selbst wenn sie die Produktdifferenzierung verringert. Proprietäre Ansätze würden die Agentenidentität zu einer weiteren Plattformgrenze machen.

Oktas Botschaft auf der Konferenz verdient Aufmerksamkeit, weil sie die Sicherheit von KI-Agenten nicht als einzelne Erkennungsfunktion behandelt. Das Unternehmen rahmt das Problem über Verantwortlichkeit und Zugriff über den gesamten Lebenszyklus eines Agenten hinweg.

Diese Einordnung entspricht der operativen Herausforderung. Ein Unternehmen muss wissen, wer einen Agenten erstellt hat, warum er existiert, auf welche Ressourcen er zugreifen kann und wie er gestoppt werden kann.

Identität ist jedoch nur eine von mehreren Steuerungsebenen. Schutzmechanismen für Modelle, Anwendungsvalidierung, Netzwerküberwachung, Data Governance und menschliche Überprüfung bleiben erforderlich.

Sicherheitsverantwortliche sollten Otkas Blueprint daher als Testframework betrachten. Sie können jeden Anbieter auffordern, Discovery, Autorisierung, Verantwortlichkeit, Protokollierung und Widerruf entlang eines realen Workflows nachzuweisen.

Der beste Beleg wird aus einer bewusst eingeschränkten Produktivbereitstellung kommen. Teams können mit einem Agenten beginnen, der begrenzte Informationen liest und Maßnahmen zur menschlichen Genehmigung vorschlägt.

Anschließend können sie übermäßige Berechtigungsanfragen, Richtlinienablehnungen, Untersuchungsdauer und die Genauigkeit der Außerbetriebnahme messen. Diese Ergebnisse sagen mehr aus als eine ausgefeilte Demonstration autonomer Funktionen.

Okta AI agent security ist letztlich eine Wette darauf, dass Unternehmen autonome Software nicht über verstreute Zugangsdaten und isolierte Kontrollen verwalten werden. Der Markt bewegt sich hin zu dedizierten Identitäten, klarer Verantwortlichkeit und kontinuierlicher Autorisierung.

Die offene Frage ist, wer diese Ebene über gemischte Umgebungen hinweg bereitstellen wird. Beobachten Sie zuerst XAA-Integrationen, dann Verlängerungen im Produktivbetrieb und anschließend die Reichweite von Microsoft bei Drittanbietern.

Wenn Okta bei allen drei Punkten Fortschritte macht, wird aus Verwirrung eine nachhaltige Chance im Bereich Identität. Bleibt die Einführung fragmentiert, behalten gebündelte Plattformen den Vorteil.

Für Unternehmensteams ist der nächste Schritt praktisch: Wählen Sie einen Agenten aus, erfassen Sie jede Verbindung und dokumentieren Sie jede erlaubte Aktion. Fragen Sie dann, ob Ihr aktuelles Identitätssystem diesen Agenten ohne kundenspezifische Anpassungen erkennen, einschränken, auditieren und den Zugriff widerrufen kann.