Anmerkung der Redaktion: In der neuesten Streamcast-Episode „Ein Konzept für den sicheren Einsatz von Agenten in Unternehmen“ gehen wir von der Theorie direkt zur Praxis über. Sie erfahren genau, wie das Konzept für das sichere agentenbasierte Unternehmen in praktische Kontrollmechanismen für Tools wie Claude Code und Cursor umgesetzt wird.
Ihre KI-Teams können es sich nicht leisten, dass Governance-Lücken die Bereitstellung ausbremsen. Sie müssen KI-Agenten jetzt produktiv einsetzen.
Laut einer Umfrage aus dem Jahr 2026 unter leitenden Technologie-Führungskräften haben 90 % der Unternehmen keine Möglichkeit zu kontrollieren, was Agenten in der Produktion tatsächlich tun. Rund 54 % haben bereits einen Sicherheitsvorfall im Zusammenhang mit einem unerwartet handelnden Agenten erlebt.
Diese Agenten rufen APIs auf, lesen sensible Daten, übertragen Aufgaben an andere Agenten und treffen Entscheidungen, ohne auf menschliche Freigaben zu warten. Die Frage ist nicht, ob in Ihrem Unternehmen bereits Agenten auf diese Weise agieren – die Frage ist, ob Sie überhaupt eine nennenswerte Kontrolle darüber haben, was sie dabei tun. Für die meisten Unternehmen lautet die ehrliche Antwort heute: Nein.
Dass die Antwort „Nein“ lautet, liegt fast immer an einem Problem der Identity Governance. Jeder KI-Agent im Produktivbetrieb läuft entweder über eine kontrollierte Identitätsebene – oder daran vorbei. Die meisten laufen daran vorbei.
Wo Identity Governance jetzt noch weiter reicht
Um zu einem sicheren, agentenbasierten Unternehmen zu werden, benötigen Sie ein Konzept, das Ihnen Antworten auf drei kritische Fragen liefert:
- Wo sind meine Agenten?
- Womit können sie sich verbinden?
- Was können sie tun?
Die in diesem Blog vorgestellten Funktionen sind neue Erweiterungen, die genau bei den letzten beiden Fragen ansetzen und das Konzept für das sichere, agentenbasierte Unternehmen entscheidend voranbringen. Sie helfen KI-Teams dabei, schneller bereitzustellen, während Security-Teams die Richtliniendurchsetzung in Echtzeit, Reaktionskontrollen und die Auditierbarkeit erhalten, die sie brauchen, um grünes Licht zu geben.
Womit können sie sich verbinden?
Irgendwo in Ihrem Unternehmen übergibt in diesem Moment möglicherweise ein KI-Agent im Hintergrund Aufgaben an einen anderen Agenten.
Und genau das ist das Problem: Jede einzelne dieser Übergaben ist ein Zugriffsereignis, das das Unternehmen steuern muss. Doch ohne eine Identity-Ebene haben die meisten Security-Teams keinerlei Einblick darin.
Die meisten Unternehmen entwickeln Multi-Agenten-Workflows auf zwei Arten:
- Vom Nutzenden initiierte Workflows: Ein:e Mitarbeiter:in bittet einen Executive-Assistant-Agenten, eine Präsentation für das vierteljährliche Business-Review zu erstellen. Der Agent orchestriert einen Schwarm von Agenten, die jeweils im Auftrag der Benutzer:in handeln und auf deren zulässigen Zugriffsbereich beschränkt sind. Der Mensch bleibt der Anker, während die Identität fließend an jede Übergabe weitergereicht wird.
- Vom System initiierte Workflows: Ein Monitoring-Dienst erkennt eine Anomalie und stößt einen Diagnose-Agenten an, der wiederum einen Log-Analyse-Agenten mit der tieferen Untersuchung beauftragt. Es gibt keine Benutzersitzung, keinen Menschen im Prozess. Die Berechtigung des Dienstes wird stattdessen durch jeden Agenten in der Kette nach unten weitergegeben.
Beide Muster teilen denselben Governance-Bedarf: Jede einzelne Übergabe ist ein Zugriffsereignis, das autorisiert, im Umfang beschränkt und protokolliert werden muss. Wenn KI-Agenten ohne eine dedizierte Identity-Ebene kommunizieren, laufen Unternehmen Gefahr, die Fähigkeit zu verlieren, die Identität der Akteur:innen hinter jeder Anfrage zu überprüfen, Richtlinien konsistent durchzusetzen oder Aktionen zu ihrer Quelle zurückzuverfolgen.
Agent-to-Agent Connections: Sichern Sie Ihre Multi-Agenten-Workflows
Agent-to-Agent Connections, eine neue Funktion in Okta for AI Agents, schließt diese Lücke. Damit können Sie Verbindungsrichtlinien pro Agent festlegen, welche vorgelagerten Dienste und Agenten diesen Agenten aufrufen können, deren Gültigkeitsbereich und wie lange die Berechtigung gültig ist. Die Identität bleibt bei jeder Übergabe erhalten, sodass jede Verbindung im gesamten Workflow überprüfbar bleibt.
Drei Prinzipien machen dies möglich:
- Explizite Allow-Listen legen fest, welche Agenten welche anderen Agenten aufrufen können.
- Bereichsbezogene Berechtigungen geben jedem nachgelagerten Agenten nur das, was er für seine Aufgabe benötigt.
- Eine überprüfbare Kette wird mit jedem Token mitgeführt, sodass das Audit-Log erfasst, wer was autorisiert hat.
Das bedeutet es, die Verbindungen auf der Agent-zu-Agent-Ebene zu steuern: Es wird genau festgelegt, welche Agenten welche anderen Agenten aufrufen dürfen – unter welchen Bedingungen, mit welchem Berechtigungsumfang und mit lückenlosen Nachweisen, die jedem oder jeder Auditor:in oder Incident-Response-Team bei Bedarf vorgelegt werden können.
Verfügbarkeit: Early Access für Agent-to-Agent Connections ist jetzt verfügbar. Lesen Sie mehr über die Absicherung Ihrer Multi-Agenten-Workflows mit Agent-to-Agent Connections.
Sichern Sie KI-Programmierassistenten wie Claude Code, Microsoft 365 Copilot und Cursor
Agent-to-Agent Connections sind eine Seite des Konnektivitätsproblems. Eine weitere große Lücke sind die nicht verwalteten KI-Tools, die Ihre Entwickler:innen bereits nutzen, um sich mit Ihren Systemen zu verbinden. Dazu gehören KI-Programmierassistenten wie Claude Code, Cursor, Microsoft 365 Copilot, GitHub Copilot und Glean.
Diese Tools sind in tägliche Workflows eingebettet und mit internen Systemen wie Jira, ServiceNow, GitHub und Ihren internen APIs verbunden.
Das Problem ist, wie sie sich Zugang verschaffen. Die meisten dieser Tools wurden nicht für die Authentifizierung über einen Identity-Anbieter entwickelt. Sie erhalten Zugriff über festcodierte Token, Ad-hoc-Anmeldedaten und API-Keys, die in Konfigurationsdateien gespeichert sind. Es gibt keine zentrale Autorisierung. Es gibt keinen Audit-Trail. Security-Teams haben oft keinen Einblick, welche Agenten auf welche Systeme zugegriffen haben, in wessen Auftrag dies geschah oder was sie dort getan haben.
Die MCP Bridge löst dieses Problem, ohne dass Änderungen an den Agenten selbst erforderlich sind. Ein selbst gehosteter, identitätsbasierter Proxy befindet sich zwischen Ihren Agenten und den Model Context Protocol (MCP)-Tools, mit denen sie sich verbinden. Jeder Aufruf verläuft über die Bridge. Jeder Agent authentifiziert sich über Ihren Identity-Anbieter. Jede Aktion wird in Ihrem Audit-Log erfasst. Der Agent muss nicht neu geschrieben werden. Auch Entwickler:innen müssen ihren Workflow nicht ändern.
Die Bridge läuft in der Umgebung der Kund:innen, sodass die Daten innerhalb des Perimeters bleiben. Kein externer Dienst sieht, was durchgeleitet wird. Die Kund:in kontrolliert die Bereitstellung, die Konfiguration und die Daten.
Verfügbarkeit: Die MCP Bridge ist ein Angebot der Professional Services und erfordert ein Statement of Work (SOW).
Was können sie tun?
Die Kontrolle darüber, was Agenten tun können, erfordert, dass die Identity-Ebene über den initialen Zugriff hinausgeht. Ein Access Token verschafft einem Agenten Zutritt; es regelt jedoch nicht, was der Agent danach tut.
Autorisierung von KI-Agenten: Durchsetzung von Laufzeit-Autorisierungen für jede Agenten-Aktion
Die Berechtigungen von Benutzer:innen können sich nach der Ausstellung eines Tokens ändern. Ein:e Auftragnehmer:in kann aus einem Projekt ausscheiden. Ein:e Patient:in kann die Zustimmung widerrufen. Ein:e Manager:in kann in den Urlaub gehen. Statische Rollen und Access-Tokens können mit dieser Dynamik nicht Schritt halten. Statt der Frage: „Hat dieser Benutzende oder Agent Zugriff auf das System?“, stellt die KI-Agenten-Autorisierung eine viel präzisere Frage: „Darf dieser Agent, der im Namen dieses Benutzenden handelt, genau jetzt diese Aktion auf dieser Ressource ausführen?“
Dieser Unterschied ist entscheidend, da sich die Autorisierungsbedingungen ständig ändern. Feingranulare Autorisierung (Fine-Grained Authorization, FGA) ist eine Zugriffskontrolle, die den gesamten Kontext einbezieht, statt nur die Benutzerrolle zu prüfen. Sie überprüft zur Laufzeit, ob der Benutzer, in dessen Namen ein Agent handelt, die erforderliche Beziehung, die aktuellen Attribute und die Richtlinienbedingungen erfüllt, um eine bestimmte Aktion auf einer bestimmten Ressource auszuführen.
Dazu gehören direkte und vererbte Beziehungen, dynamische Attribute wie Sicherheitsfreigaben oder der Bereitschaftsstatus sowie Richtlinienschwellenwerte wie Mengenbegrenzungen, Geldbeträge oder Datenklassifizierungsregeln.
Ein Beschaffungsagent kann beispielsweise Rechnungen bis zu 10.000 $ für den Benutzenden freigeben, in dessen Namen er handelt, jedoch nicht darüber hinaus. FGA prüft zur Laufzeit das Genehmigungslimit der Benutzer:in, nicht nur deren Rolle.
Zu steuern, was Agenten tun können, erfordert mehr als statische Berechtigungen, die bei der Bereitstellung festgelegt werden. Sie verlangt eine kontinuierliche Evaluierung jeder einzelnen Aktion, über jeden Agenten hinweg und in Echtzeit. Nur so lässt sich steuern, was ein Agent tatsächlich tut.
Verfügbarkeit: Dies ist eine Implementierung des Anwendungsfalls für FGA und Okta for AI Agents.
Not-Aus-Schalter: Deaktivieren Sie einen Rogue-Agenten, sobald es erforderlich ist
Eine von Anfang an integrierte Governance verringert die Wahrscheinlichkeit, dass etwas schiefgeht, aber das bedeutet nicht, dass es nicht passieren kann. Agenten sind von Natur aus unberechenbar. Sie treffen Entscheidungen, bewegen sich über Systeme hinweg und können Aktionen ausführen, die niemand vorhergesehen hat. Wenn dies geschieht, müssen Security-Teams sofort reagieren.
Viele Bereitstellungen von KI-Agenten bieten heute keine Möglichkeit, einen Agenten abzuschalten, wenn er sich unerwartet verhält. Wenn der Vorstand nach dem Reaktionsplan fragt, falls ein Agent außer Kontrolle gerät, haben die meisten CISOs keine Antwort.
Das ändert sich mit einem Not-Aus-Schalter. Bei Agenten, die sich über Okta verbinden, sperrt der Widerruf des Zugriffs mit einer einzigen Aktion aus der Okta Admin-Konsole den Zugriff auf alle verbundenen Ressourcen. Sie müssen nicht bestätigen, dass ein Agent kompromittiert ist, um ihn zu verwenden. Eine Fehlkonfiguration, eine Aktion außerhalb des Geltungsbereichs oder ein Verhalten, das Fragen aufwirft. Jeder dieser Punkte ist Grund genug, den Agenten sofort zu deaktivieren, während Sie weiter untersuchen, was passiert ist.
Das Ergebnis: KI-Teams können ihre Lösungen in dem Wissen bereitstellen, dass ein Sicherheitsnetz vorhanden ist. Security-Teams können Bereitstellungen in dem Wissen genehmigen, dass sie reagieren können, falls etwas schiefgeht. Wenn Sie wissen, dass Sie es stoppen können, können Sie es genehmigen.
Verfügbarkeit: Die Not-Aus-Schalter-Funktion ist allgemein verfügbar und in Okta for AI Agents enthalten. Demnächst verfügbar: Eine Erkennungsfunktion, die Risikoindikatoren aus dem gesamten Okta-Ökosystem erfasst, den Risiko-Score des Agenten erhöht und den Not-Aus-Schalter automatisch auslöst.
Jeder Agent benötigt eine Identity-Ebene
Diese Funktionen adressieren verschiedene Aspekte des Agent-Governance-Problems, beruhen jedoch auf einer gemeinsamen Prämisse. Die Identity-Funktionen, die Ihre Mitarbeiter:innen und Anwendungen schützen, müssen auch auf Agenten ausgeweitet werden. Dies umfasst die Steuerung der Verbindungen zwischen ihnen, der von ihnen ausgeführten Aktionen, der von ihnen verwendeten Tools sowie Ihre Fähigkeit, sie aufzuhalten, wenn etwas schiefgeht.
Die Verwaltung von Agenten auf diese Weise erfordert eine maßgebliche Echtzeit-Identity-Ebene, die bereits Ihre Belegschaft und Anwendungen umfasst. Genau auf dieser Ebene setzt Okta an.
Unternehmen, die dies frühzeitig richtig umsetzen, werden nicht nur Sicherheitsvorfälle reduzieren – sie werden schneller vorankommen. Erkennung, Sicherheit und Governance von Anfang an bremsen die KI-Bereitstellung nicht aus. Sie sind das Fundament, das eine Skalierung überhaupt erst möglich macht. Legen Sie jetzt diese Basis, damit Ihr Security-Team bei der Einführung von Agenten vom Compliance-Engpass zum Erfolgsfaktor wird.
Um mehr über diese Updates, einschließlich Demos, zu erfahren, sehen Sie sich das Streamcast-Webinar an.
Dieses Dokument dient nur zu allgemeinen Informationszwecken. Die hier enthaltenen Informationen stellen keine Rechts-, Datenschutz-, Sicherheits-, Compliance- oder Geschäftsberatung dar. Es liegt in Ihrer Verantwortung, sich mit Blick auf die Sicherheit, den Datenschutz, die Compliance und das Business beraten zu lassen. Jegliche Erwähnung zukünftiger Produkte, Funktionen, Funktionalitäten oder Zertifizierungen in diesem Blog dient ausschließlich zu Informationszwecken. Es handelt sich nicht um Zusagen zur Bereitstellung und sollte nicht als Grundlage für Kaufentscheidungen herangezogen werden. © Okta, Inc. und Partner. 2026.
