Am 24. August 2026 hat Okta Agent SSO in die allgemeine Verfügbarkeit überführt. Die Funktion bringt den offenen Standard Cross App Access in das Identitätsprodukt, das von über 20.000 Kunden genutzt wird, laut der offiziellen Ankündigung[1].
Agent SSO etabliert ein erstklassiges Identitätsmodell für KI-Agenten am Verbindungspunkt.
Die Funktion ist kostenfrei in den Okta-SSO-Kernplänen enthalten. Das ist ein klares Preissignal: Okta behandelt die Agentenidentität als Basiskomponente, der wirtschaftliche Wert verschiebt sich in den Tier Okta for AI Agents. Dieser übergeordnete Tier entdeckt, onboardet, schützt und regelt jeden Agenten im Unternehmen.
Die Agent Identity Gap, die Okta beschreibt
Unternehmen deployen KI-Agenten schneller, als sie diese regeln können. 34 % der Organisationen wenden auf KI-Agenten dieselben Sicherheitskontrollen an wie auf menschliche Mitarbeiter, so der Bericht Okta AI Agents at Work 2026, zitiert von SecurityBrief[2]. Das bedeutet, dass zwei Drittel der Organisationen dies nicht tun. Diese Agenten operieren außerhalb des für Menschen definierten Policy-Perimeters.
Die meisten Agenten greifen auf Unternehmensdaten über statische API-Schlüssel, isolierte OAuth-Grants und anwendungsweise erstellte Custom-Integrationen zu. Sie agieren als anonymer Traffic: ohne Owner, ohne Policy, ohne Audit Trail. Das ist die technische Schuld, die entsteht, wenn die Produktionseinführung der Absicherung vorausgeht. Ohne Audit Trail lässt sich ein Vorfall im Nachhinein nicht rekonstruieren: Es fehlt das Register, das eine Aktion mit einer Identität verknüpft.
Das Problem multipliziert sich mit dem Wachstum der Agentenpopulationen. Unternehmen müssen drei Populationen gleichzeitig verwalten: intern entwickelte Agenten, in zugekaufte Software eingebettete Agenten und von Mitarbeitern ohne zentrale Genehmigung deployte Agenten. Jede Population hat einen anderen Owner. Die dritte, jene ohne zentrale Genehmigung, ist am schwierigsten zu inventarisieren, da sie ohne Durchlaufen des Governance-Layers entsteht.
Wie Agent SSO auf technischer Ebene funktioniert
Agent SSO gilt für Agenten, die Cross App Access unterstützen. Wenn sich ein Agent mit einer Unternehmensanwendung verbindet, registriert Okta ihn als erstklassige Identität im Universal Directory – neben den menschlichen Mitarbeitern.
Anstelle gespeicherter Zugangsdaten stellt das System kurzlebige, identitätsgesteuerte Token aus. Administratoren weisen die Policy des Agenten zu, überwachen und aktualisieren sie über dieselbe Konsole, die sie für Mitarbeiter verwenden. Die einheitliche Konsole senkt den Betriebsaufwand: Es ist kein zweites Tool für die Agentenpopulation erforderlich.
Das von Okta genannte Beispiel betrifft Claude von Anthropic: Sicherheitsteams regeln dessen Zugriff auf native Weise. Mitarbeiter müssen keine statischen Zugangsdaten teilen oder wiederholten Zustimmungen zustimmen.
Der Risikomechanismus, den dies schließt
Statische API-Schlüssel sind der Angriffsvektor. Ein gestohlener Schlüssel gewährt dauerhaften, ablauflosen und schwer gezielt revozierbaren Zugriff. Kurzlebige Token reduzieren diese Angriffsfläche, weil sie ablaufen und an eine nachverfolgbare Identität gebunden sind. Das Ablaufen begrenzt das Ausnützungsfenster. Die Bindung an die Identität macht die Revokation selektiv.
Ein Risiko bleibt, das Agent SSO offen lässt: Prompt Injection. Ein aus einem Retrieval-System abgerufenes Dokument ist ein Angriffsvektor mit denselben Berechtigungen wie der Benutzer.
Governed Identity beantwortet die Frage, wer der Agent ist. Die Validierung abgerufener Eingaben ist ein eigenständiges architekturales Problem, das auf Ebene der RAG-Pipeline angegangen werden muss. Die meisten RAG-Architekturen in der Produktion behandeln Dokumente als vertrauenswürdige Eingabe. Das ist falsch. Ein kurzlebiges Token ändert dieses Ergebnis nicht: Der authentifizierte Agent führt dennoch die im Dokument enthaltene feindliche Anweisung aus – mit seinen eigenen legitimen Zugangsdaten.
Standardisierung als eigentlicher Moat
Meine Position bleibt unverändert: Die Standardisierung von Protokollen wird im agentischen KI-Bereich der Wettbewerbsmoat sein – mehr als die Modellleistung. Wer die Kommunikationsschicht zwischen Agenten kontrolliert, kontrolliert die Architektur.
Cross App Access ist ein offener Standard, das zählt. Ein Standard, der aus der Sphäre eines einzelnen Anbieters heraustritt, reduziert das Risiko eines architekturalen Lock-ins. Die Spezifikation ist ein Standard, den man übernehmen kann, mehr als ein Anbieterprodukt, das man evaluiert.
Okta gewinnt dennoch an Position: Das Unternehmen besitzt die Referenzimplementierung und das Directory. Die offene Governance des Standards begrenzt die Macht dieser Position. Die Begrenzung gilt, solange die Spezifikation außerhalb des Anbieters geregelt bleibt. Wenn die Referenzimplementierung dem Standard vorauseilt, kehrt der Vorteil zu Okta zurück.
Drei Fragen für das Enterprise-KI-Team
Vor der Neuverhandlung eines Vertrags muss das Team das eigene Exposure kartieren. Drei Fragen definieren den operativen Scope.
- Wie viele Agenten in der Produktion authentifizieren sich heute mit statischen API-Schlüsseln ohne Owner?
- Welche Agenten unterstützen Cross App Access und welche bleiben außerhalb des Standards?
- Behandelt die RAG-Pipeline abgerufene Dokumente als vertrauenswürdige oder als feindliche Eingabe?
Die Antworten bestimmen, wie nah Sie dem von Okta beschriebenen Modell sind. Eine Population anonymer Agenten zeigt technische Schuld an, die schnell reift. Die erste Frage misst die zu migrierende Angriffsfläche. Die dritte misst ein Risiko, das dieses Release nicht abdeckt.
Beschaffungsentscheidungen für den nächsten Planungszyklus
Entscheidungen für CTO und Head of Engineering im nächsten Planungszyklus: Bewerten Sie, inwieweit Ihr Identitätsanbieter Cross App Access nativ unterstützt. Ein Anbieter, der auf Custom-Integrationen setzt, erbt die technische Schuld, die dieser Standard beseitigt.
Für den CFO ändert sich die Rechnung. Agent SSO ist kostenfrei enthalten und senkt die Einstiegshürde; die tatsächlichen Kosten liegen im Tier Okta for AI Agents und in der Migrationsarbeit. Der kostenfreie Teil ist das Token, nicht das Projekt: Die Migration von statischen Schlüsseln bleibt interne Arbeit, die geschätzt werden muss.
Für das Technology Procurement Committee geht es um Neuverhandlung. Ein vor der Agenten-Ära abgeschlossener Identitätsvertrag verdient eine Klausel zur Unterstützung offener Standards.
Okta for AI Agents deckt auch Agenten außerhalb des Standards ab, laut TechNode[3]. Diese Abdeckung ist der Hebel, der den Wert vom kostenlosen in den kostenpflichtigen Tier verschiebt.
Das Urteil
Agent SSO ist produktionsreif für Agenten, die Cross App Access unterstützen. Für alles andere liegt die Governance im kostenpflichtigen Tier – diese Unterscheidung hat Gewicht im Budget.
Die Architektur wird zum Wettbewerbsvorteil, wenn der Standard offen und außerhalb des einzelnen Anbieters geregelt bleibt. Sie wird zur Falle, wenn die Referenzimplementierung die Bedingungen der Kommunikationsschicht diktiert.
Das Stabilitätssignal der allgemeinen Verfügbarkeit ist real, die Härtungsarbeit verbleibt beim Unternehmen. Behandeln Sie dieses Release als Grundlage – der Großteil der Arbeit an der KI-Agentenidentität bleibt intern.
Dieser Artikel wurde von einem redaktionellen KI-Autor unter menschlicher Aufsicht verfasst, in Übereinstimmung mit den Transparenzpflichten der Verordnung (EU) 2024/1689 (KI-Verordnung, Art. 50). Die Quellen sind im Text verlinkt.
Article by LEON
Quellen
- der offiziellen Ankündigung (okta.com)
- SecurityBrief (securitybrief.com.au)
- TechNode (technode.global)