Absicherung des agentischen Unternehmens: Der Blueprint in der Praxis

Agenten sind leistungsstark. Sie sind auch eine Angriffsfläche.

Ein KI-Agent ist nur so nützlich wie die Systeme, auf die Sie ihm Zugriff gewähren. Die nützlichen sind im Einsatz, um Rückerstattungen zu genehmigen, Transaktionen zu buchen und Kundendatensätze in den Systemen zu ändern, die Sie am sorgfältigsten schützen und die über SaaS-Konnektoren, Model Context Protocol (MCP)-Server und APIs erreicht werden. 

Um handeln zu können, muss ein Agent das Vertrauen von Systemen genießen, mit denen er noch nie zuvor interagiert hat, im Auftrag eines anderen, ohne dass ein Mensch in dem Moment zuschaut, in dem er entscheidet. Ein einzelner Agent unter Aufsicht ist leicht zu verstehen und zu steuern (Abbildung 1). 

Die Probleme beginnen, wenn Agenten von der Pilotphase in die Produktion übergehen und die Nutzung im gesamten Unternehmen skaliert. Eine überwachte Verbindung wird zu Tausenden unüberwachten Verbindungen. Die jedem gewährte Berechtigung wird einmalig und weit gefasst festgelegt, was zu einem Zugriffschaos führt (Abbildung 2).

Ein Agent. Viele Tools und Ressourcen.

Jeder Link führt zu Ihren Kundendaten, Ihrer IP und den operativen Systemen, die Ihr Unternehmen am Laufen halten.

Benutzer × Agenten × Konversationen × Tools = Zugriffschaos

Jeder Link ist eine Angriffsfläche. Die Autorisierung muss jeden einzelnen bei jedem Aufruf in Maschinengeschwindigkeit kontrollieren.

Dieses Chaos sieht aus wie eine Sicherheitsbedrohung, aber es tritt nicht so in Erscheinung, wie eine solche es normalerweise tut. Aber KI-Agenten brechen nicht ein. Sie werden erstellt, verbunden oder erhalten Zugriff, und bis der Datenverkehr eine Firewall erreicht, befindet sich der Agent bereits im Inneren.

Die eigentliche Frage ist, was als Nächstes passiert: 

• Welcher Agent ist das?
• Wer hat es autorisiert?
• Was kann es erreichen? 
• Was kann es für diese Aufgabe tun? 
• Wie widerrufen wir seinen Zugriff?

Dies sind Fragen der Identity und Autorisierung, und obwohl grobe Scopes im Voraus festgelegt werden können, lassen sie sich nicht vorab beantworten; aufgabenspezifische Entscheidungen müssen zur Laufzeit getroffen werden. Die Berechtigung eines Agenten sollte zum Zeitpunkt der Handlung basierend auf den Identitäten von Mensch und Agent bestimmt werden. Dies stellt sicher, dass die Autorisierung präzise auf die Aufgabe zugeschnitten ist und die verantwortliche Person mit jeder Anfrage verknüpft ist. Dieses Kernprinzip dient als Grundlage für die gesamte Architektur.

Das Sicherheitskonzept existiert. Das Budget nicht.

Der Wandel ist an der Spitze bereits sichtbar. Uber hat kürzlich einen detaillierten Bericht darüber veröffentlicht, wie das Unternehmen KI-Agenten eine echte Identität gegeben hat. Die Lösung basiert auf kryptografischer Agenten-Identität und einem Per-Hop Token-Austausch, der die gesamte Akteurskette vom Menschen bis hin zum ausgeführten Tool lückenlos transportiert. Es ist eine starke Bestätigung dafür, dass das Problem real und die Architektur erfassbar ist. Dafür war auch eine intern aufgebaute und betriebene Engineering-Organisation erforderlich, die die meisten Unternehmen niemals haben werden. 

Die Lektion, die wir daraus ziehen sollten, betrifft Standards: Eine Identity-Schicht für Agenten hat nur Bestand, wenn sie die Anbieter- und SaaS-Grenzen überwindet, die Agenten ständig überschreiten. Das bedeutet, dass sie auf konsistenten Standards basieren sollte, die von allen Parteien auf die gleiche Weise implementiert werden, und als Ebene bereitgestellt werden sollte, anstatt von jedem Unternehmen einzeln entwickelt zu werden. Das ist Okta for KI Agenten.

Wie Okta das agentische Unternehmen absichert

Okta für KI-Agent macht dieses Prinzip zu einer operativen Ebene: Verifizierbare Identity für jeden Agent, Autorisierung, die im Moment der Aktion festgelegt wird, und der verantwortliche Mensch, der über die gesamte Kette hinweg nachvollziehbar bleibt. Der Rest dieses Beitrags erläutert die Architektur am Beispiel eines Unternehmens.

Eine typische agentische Unternehmensimplementierung 

Um dieses hypothetische Szenario zu konkretisieren, betrachten wir Streamward Inc., eine Mischung aus den Unternehmen, mit denen wir zusammenarbeiten. Ein Benutzer stellt eine Anfrage über einen Chat-Assistenten, und ein Master-Agent-Orchestrator analysiert die Absicht und delegiert Teilaufgaben im gesamten Mesh nach geschäftlicher Funktion (Abbildung 3). Um auf nachgelagerte Systeme, proprietäre APIs und Drittanbieterdienste zuzugreifen, verwenden die Agenten eine Mischung aus Laufzeit-Ressourcentypen: MCP-Server, REST-Endpunkte, die durch OpenAPI-Spezifikationen geregelt werden, und native Cloud-Data-Warehouses.

Beispielhafte Multi-Agenten-Mesh-Architektur

• Salesforce Agentforce: Übernimmt CRM-Pipeline-Analysen, Lead-Scoring und Account-Abfragen.
  • Verbundener MCP-Server: gleicht Salesforce-Account-IDs über einen Enterprise-ERP-MCP-Server mit Live-Abrechnungsdaten ab und ruft dabei get_customer_payment_history auf.
• Amazon Bedrock AgentCore: Führt Retrieval-Augmented Generation (RAG) über das Unternehmenswissen aus.
  • Verbundener MCP-Server: Stellt über MCP eine Verbindung zu einer AWS Aurora PostgreSQL-Vektordatenbank her, um semantische Suchen auszuführen, und ruft dabei query_knowledge_base und fetch_unstructured_contract_pdf auf.
• Google Vertex AI: Low-Code-Laufzeitumgebungen zur Steuerung autonomer Kunden-Workflows.
  • Verbundenes OpenAPI-Gateway: Leitet Aufrufe durch ein OpenAPI-konformes Workday- und ServiceNow-Gateway weiter, ruft read_latest_incident_tickets auf und löst create_workday_expense_claim aus.

Die vier häufigen Sicherheitslücken bei der Implementierung

Nun verfolgen wir eine gewöhnliche Anfrage durch dieses Mesh, um häufige Sicherheitslücken aufzuzeigen: eine Abfrage der Unternehmens-Knowledge Base, die die Datenbank erreichen muss. Ohne eine zentrale Identity-Fabric versagt es auf vier Arten, wie an dem Token zu sehen ist, das der Agent mit sich führt (Abbildung 4). Die Lücke besteht darin, was dem Token fehlt.

Schatten-KI 

Eigenentwickelte oder von Drittanbietern stammende Agenten, die in Amazon Bedrock AgentCore ausgeführt werden, werden von Teams häufig konfiguriert oder bereitgestellt, ohne sie über den Identity-Anbieter (Identity-Anbieter) zu registrieren. Da kein Sicherheits-SDK in diese Umgebungen integriert wird, starten die Agenten dynamisch und verbinden sich am Rande der Zugriffsrichtlinien des Unternehmens mit internen Ressourcen. Ihre rohen Token zeigen einen Maschinen-Client, weisen jedoch keinen iss -Claim (Aussteller) auf, haben keinen validierenden Menschen dahinter und keinen Eigentümer, der für ihren Lebenszyklus verantwortlich ist. Sie können einfach keinen Bedrock-Agenten verwalten, den Sie nie ausgestellt haben.

Übermäßig privilegierte Zugriffe 

Der scope -Claim im Token eines nicht verwalteten Agenten birgt ein übermäßiges Risiko. Damit der Bedrock-Agent eine Verbindung zur Zieldatenbank herstellen kann, ohne den Ausführungsablauf ständig zu unterbrechen, um sich über Systemgrenzen hinweg neu zu authentifizieren, neigen Entwickler dazu, dem Agenten einen weitreichenden, langlebigen Service-Account zuzuweisen. Der Gültigkeitsbereich des Tokens umfasst eine dauerhafte, breite administrative Fläche, die weit über das hinausgeht, was eine spezifische Textabfrage benötigt. Jeder zu weit gefasste Scope schafft einen Zugriffspfad, der anfällig für Prompt Injection oder Datenexfiltration ist, doch das Widerrufen des Agent unterbricht jeden anderen automatisierten Workflow, der diesen einzelnen Service-Account nutzt.

Identitätswechsel, nicht Delegation

Wenn die Abfrage von Bedrock AgentCore auf den Aurora-DB-MCP-Zielserver übergeht, wird die Identity vollständig auf einen generischen Machine Principal reduziert. Die Datenbank-Engine protokolliert den Aufruf von query_knowledge_base() durch einen Service-Account, wobei die Identity des menschlichen Bedieners, der die Aufgabe initiiert hat, sowie der spezifische Sub-Agent, der die Abfrage ausführt, fehlen. Ohne eine kryptografische Delegationshistorie im Token kann die Ressourcengrenze keine Datenberechtigungen auf Benutzerebene durchsetzen, was zu einer vollständigen Löschung der Identity und einem fehlerhaften Audit-Trail führt.

Keine Governance

Wenn der Agent einen Tool-Aufruf oder einen unerwarteten Datenbank-Lesevorgang auslöst, enthält das nicht verwaltete Maschinen-Token weder eine Transaktions-Identity noch den Kontext einer menschlichen Zustimmung. Die Aktion wird nahtlos und ohne Laufzeitunterbrechung für eine Genehmigung ausgeführt, was die Security-Teams völlig im Unklaren lässt. Im Nachhinein ist es unmöglich, die automatisierte Transaktion kryptografisch auf einen menschlichen Verantwortlichen zurückzuführen, was bedeutet, dass Sie rechtlich nicht nachweisen können, wer welche Datenbewegung autorisiert hat.

Die meisten Unternehmen beheben ein oder zwei davon.

Die vier häufigen Sicherheitslücken, die im Token zu sehen sind

Sie sollten diese eine Anfrage im Hinterkopf behalten. Die Anleitung später in diesem Beitrag zeigt, wie der Agentcore-Agent auf das Aurora-DB-MCP-Tool zugreift, diesmal mit Okta im Pfad, und dabei ohne einen der vier Ausfälle erfolgreich ist.

Okta for AI Agenten schließt die Sicherheitslücken 

Okta verwandelt die Vertrauensgrenze in eine Governance-Ebene, die direkt in den Ausführungspfad integriert ist (Abbildung 5). Streamward leitet den gesamten MCP-Datenverkehr über ein Inline-Runtime-Agent-Gateway, den Richtliniendurchsetzungspunkt (PEP), mit Okta als dahinterliegendem Richtlinienentscheidungspunkt (PDP). Der Agent speichert niemals Anmeldeinformationen im Klartext für die MCP-Tools. Dies ist die physische Umsetzung der Control-Plane-Idee: Jede Anfrage stoppt an einem Punkt, der die beteiligten Identitäten kennt und in diesem Moment entscheidet, was erlaubt ist.

Beispielhafte Multi-Agenten-Mesh-Architektur mit Okta für KI-Agenten

Der sichere Zugriffsablauf, Schritt für Schritt

Die finale Anfrage, die ein beliebiges Backend-Tool erreicht, enthält eine verifizierbare Identity, die sowohl den menschlichen Kontext (den sub -Claim) als auch den Agent-Workload-Principal (den act -Claim) umfasst. 

Hier ist dieselbe Knowledge Base-Abfrage von vorhin, die nun über Okta ausgeführt wird. Das folgende Diagramm verfolgt dies von Anfang bis Ende, und die darauffolgenden Stationen gehen jeden Schritt durch und zeigen, wie das Token dabei erstellt und ausgetauscht wird (Abbildung 6).

Der sichere End-to-End-Zugriffsablauf

Die endgültige Anfrage, die ein beliebiges Backend-Tool erreicht, enthält eine verifizierbare Identity, die sowohl den menschlichen Kontext (den sub -Claim) als auch den Agent-Workload-Principal (den cid -Claim) umfasst. 

Hop 1: Menschlicher Benutzer zum Frontend

Der Benutzer meldet sich über einen OpenID Connect (OIDC)-Flow im Portal von Streamward an, und Okta stellt ein Standard-Access Token für Benutzer aus.

Hop 2: Frontend zum Orchestrator

Das Frontend verarbeitet den natürlichsprachlichen Prompt und leitet den Aufgabenkontext an den Master-Agent-Orchestrator weiter, wobei das Access Token des Benutzers als Bearer-Token mitgeführt wird.

Hop 3: Orchestrator zu Okta, A2A-Austausch

Der Orchestrator bestimmt, dass die Aufgabe eine analytische Verarbeitung in Bedrock AgentCore über den Agenten Corp-Knowledge-Agent erfordert. Er übermittelt das Benutzer-Token und den angeforderten Scope an den Token-Endpunkt von Okta (/oauth2/v1/token) und initiiert den Cross-App Access (XAA)-Flow (Identity Assertion Authorization Grant). Okta wertet die Zugriffsmethode (Access Policy) des Agenten aus und gibt ein kurzlebiges, einmalig verwendbares ID-JAG-Token (urn:ietf:params:oauth:token-type:id-jag) zurück, dessen Berechtigungen exakt auf diese Aufgabe beschränkt sind.

Hop 4: Orchestrator zu Okta, Token-Austausch

Der Orchestrator erstellt eine Client-Assertion mit dem privaten Schlüssel des Orchestrators und tauscht das ID-JAG-Token am benutzerdefinierten Autorisierungsserver aus, der dem Ziel-Agentcore-Agenten zugewiesen ist. Okta wertet dort die Benutzerzugriffsrichtlinie aus und gibt ein bereichsbezogenes Access Token zurück, das für den Agenten Corp-Knowledge-Agent bestimmt ist.

Hop 5: Orchestrator zu Bedrock AgentCore

Der Orchestrator übergibt das bereichsbezogene Token als Teil des eigentlichen Agent-zu-Agent-Aufrufs (A2A) an den AgentCore-Agenten Corp-Knowledge-Agent. AgentCore verifiziert das Token und lässt zu, dass der Aufruf im Kontext des Orchestrator-Agenten und der initiierenden menschlichen Identity fortgesetzt wird.

Hop 6: AgentCore zum Gateway

Corp-Knowledge-Agent ruft das Tool query_knowledge_base auf dem Aurora DB MCP-Server über das Gateway auf und übergibt dabei das eingehende Token sowie die gewünschte Berechtigung (Scope) für das ausgehende Tool.

Hop 7: Gateway zu Okta, App-übergreifender Zugriff 

Das Gateway initiiert den XAA-Ablauf erneut und übermittelt das eingehende Token und den angeforderten Scope an den Token-Endpoint von Okta (/oauth2/v1/token). Okta wertet die Zugriffsrichtlinie für den Agenten aus und gibt ein kurzlebiges, einmalig verwendbares ID-JAG-Token zurück, das auf die Aufgabe beschränkt ist.

Hop 8: Gateway zu Okta, Token-Austausch 

Das Gateway erstellt eine Client-Assertion mit dem privaten Schlüssel des Agentcore Corp-Knowledge-Agent’s und tauscht das ID-JAG-Token beim benutzerdefinierten Autorisierungsserver aus, der dem Ziel-Aurora-DB-MCP-Server zugewiesen ist. Okta wertet dort die Benutzerzugriffsrichtlinie aus und gibt ein bereichsbezogenes Access Token zurück, das für den MCP-Server bestimmt ist.

Das Tool am Ende erhält eine Anfrage, die es vollständig zuordnen kann: Wer die Person ist, welcher Agent gehandelt hat, dessen Scope und einen Chain-of-Custody-Claim (act), der die gesamte Kette mit einem Datensatz verknüpft. Die Befugnis wurde zur Laufzeit festgelegt, auf die Aufgabe beschränkt und niemals von der dafür verantwortlichen Person getrennt.

Die vier zentralen Sicherheitslücken, die durch die Architektur behoben werden

Indem der Ausführungsablauf von Bedrock AgentCore über diese standardisierte Architektur geleitet wird, neutralisiert Streamward erfolgreich die vier häufigen Identity-Fehler, die nicht verwaltete Agent-Konfigurationen stören:

Behebung von Schatten-KI 

Anstatt dem Bedrock- Corp-Knowledge-Agent zu gestatten, ohne verifizierbaren Aussteller unkontrolliert im zentralen Identity-Anbieter zu agieren, wird der Agent direkt in Universal Directory als eigenständiger Workload-Principal registriert. Die IT-Governance behält die klare Verantwortung für ihren Lebenszyklus und die Transparenz über ihre Netzwerkverbindungen.

Behebung von Over-Privileged Access 

Anstatt über einen weitreichenden, permanenten Service-Account mit Standing-Berechtigungen ausgeführt zu werden, die die gesamte Datenbankschicht Prompt-Injection-Bedrohungen aussetzen, erhält der Agent ein kurzlebiges Token, das zur Laufzeit dynamisch generiert wird. Seine Scopes werden mathematisch geschnitten und strikt auf die einzelne Datenbankoperation eingeschränkt, die für diesen spezifischen Ausführungsblock erforderlich ist (Aurora-DB:read).

Verhinderung von Identitätstäuschung 

Durch die direkte Einbettung der Multi-Hop-Delegationskette act in den Token-Kontext wird die Identity nicht auf eine generische Maschinen-Anmeldedaten reduziert. Die Ressourcengrenze kann die Verantwortungskette präzise tracken, wodurch eine Identity-Löschung verhindert und Datenkontrollen gemäß den tatsächlichen Berechtigungen der initiierenden Person durchgesetzt werden.

Governance-Durchsetzung

Jeder Schritt des Token-Austauschs generiert explizite, strukturierte Events (app.oauth2.token.grant.id_jag) mit einer unveränderlichen Transaktionskennung verknüpft. Dieser permanente Audit-Verlauf liefert Compliance- und Incident Response-Teams den Nachweis darüber, welche Person welche automatisierte Aktion autorisiert hat.

Die Komponenten von Okta for KI Agenten

Sehen wir uns die Komponenten von Okta for AI Agents an, die an der obigen Lösung beteiligt sind.

Agent-Registrierung und -Erkennung  

Diese Komponente verwandelt unbekannte autonome Agenten in bekannte, verifizierbare Workload-Principals, indem sie diese im Universal Directory registriert, wo jeder einen Lebenszyklus, einen namentlich benannten menschlichen Eigentümer und einen Platz in der Richtlinie erhält. 

Da nicht verwaltete Agenten schneller auftauchen, als sie manuell registriert werden können, erkennt Identity Security Posture Management (ISPM) diese über Clouds und MCP-Netzwerke hinweg, einschließlich der No-Code-Agenten, die andernfalls unsichtbar bleiben würden, und ordnet jeden einzelnen einem Eigentümer zu. Ein Agent, den Sie nicht sehen können, ist einer, den Sie nicht autorisieren oder zur Rechenschaft ziehen können.

Automatisches Agent-Onboarding

Agenten, die auf Salesforce, AWS, Microsoft und ServiceNow basieren, importieren direkt in Universal Directory, sodass das Verzeichnis mit ihrem Erscheinen Schritt hält.

Cross App Access 

XAA verwendet den Identity Assertion Authorization Grant, um die Löschung der Identity über Multi-Hop-Workflows hinweg zu verhindern. Anstatt dass ein Agent als anonymer Service-Account agiert, werden sowohl der Mensch (der sub -Claim) als auch der Agent (der act -Claim) im Token übertragen (Abbildung 7), wodurch ein Actor-Claim erzeugt wird, der eine Kette anstelle eines einzelnen Principals darstellt. XAA sorgt dafür, dass die Autorisierung an einen echten Menschen gebunden bleibt, während eine Anfrage Anbietergrenzen überschreitet.

Der XAA-Ablauf

Vermittelte Zustimmung

Für den erstmaligen Agent-zu-SaaS-Zugriff im Namen eines Benutzers vermittelt der Secure Token Service (STS) von Okta die Zustimmung dynamisch. Der Agent pausiert, während der Benutzer den Zugriff einmalig Out-of-Band autorisiert, bevor der Aufruf fortgesetzt wird. Die Einwilligung wird auf der Identity Layer eingerichtet und nicht in jeden Agenten integriert, sodass selbst ein Agent, den Sie nicht ändern können, die Kontrolle erbt.

Agent-zu-Agent-Autorisierung  

In einem Agent-Mesh vermittelt Okta jede Übergabe. Ein einziger Schritt konfiguriert die Verbindung zwischen zwei Agenten (Abbildung 8), und die effektive Berechtigung ist die Schnittmenge der Rechte des Benutzers und der des aufrufenden Agenten, was bedeutet, dass ein Sub-Agent niemals die Kombination mit den geringsten Privilegien überschreitet. Der verschachtelte Akteur-Claim erstreckt sich vom Menschen über jeden Agenten bis zum Zieldienst, mit richtliniengesteuerter Autorisierung bei jedem Hop, wobei der verantwortliche Mensch in der Kette erhalten bleibt.

Konfigurieren der Agent-zu-Agent-Ressourcenverbindung in Okta

Zentrale Auditierung

Da ein Agent keine juristische Person ist und sich nicht selbst verantworten kann, muss am Ende jeder Kette ein verantwortlicher Mensch benennbar sein. Ein einziges Protokoll erfasst jede Transaktion mit expliziten Berechtigungsereignissen, die belegen, wer gehandelt hat und in wessen Namen (Abbildung 9) – dies ist der Nachweis, den eine Aufsichtsbehörde, ein Gericht oder ein Vorstand verlangen wird.

Okta system log für zentrales Audit

Sichere Laufzeitkontrolle

Okta stellt das Inline-Runtime Agent Gateway als zentralen Richtliniendurchsetzungspunkt (PEP) vor nachgelagerten Ressourcen bereit, wobei Okta bei jeder Anfrage als Richtlinienentscheidungspunkt (PDP) fungiert (Abbildung 10).

Das Runtime Agent Gateway

• Virtueller MCP-Server: Das Gateway präsentiert sich als MCP-Server, was es Organisationen ermöglicht, Low-Code- und No-Code-Agenten abzusichern, die auf Unternehmensressourcen zugreifen, ohne dass diese Agenten nativ mit dem Token-Austausch kommunizieren müssen.
• Isolierung von Anmeldedaten: Das Gateway abstrahiert kurzlebige XAA-Token und langlebigere vermittelte SaaS-Token, sodass diese Ressourcen-Anmeldedaten den Agenten niemals offengelegt werden.
• Sicherheit für Inline-Tool-Aufrufe: Low-Code-Plattformen leiten jeden ausgehenden Tool-Aufruf über das Gateway. Dieses fängt den Aufruf ab, prüft die Verknüpfung mit feingranularen Richtlinien in Echtzeit (at wire speed) und injiziert unmittelbar vor der Ausführung ein kurzlebiges Backend-Secret direkt an der Edge. Das ausgestellte Token wird im Moment der Anfrage generiert, ist auf die Aufgabe beschränkt, zielgruppengebunden und in Sekundenschnelle widerrufbar – das Gegenteil von Standing Credentials, die in einer Datei gefunden und wiederverwendet werden können.

Wie es weitergeht: Erweiterte Funktionen von Okta for KI Agenten

Was diese Architektur heute bietet, ist die Grundlage: Jeder Agent erhält eine verifizierbare Identity, und seine Berechtigung wird zur Laufzeit bestimmt und auf die Aufgabe beschränkt. 

Die erste Phase eines globalen Kill Switch ist bereits implementiert und nutzt das Shared Signals Framework (SSF), um Risikoindikatoren in einen Widerruf umzuwandeln, was auf eine koordinierte Echtzeit-Beendigung über alle verbundenen Systeme hinweg ausgeweitet wird – die Kontrolle, die kurzlebige Tokens allein nicht bieten können.

Was als Nächstes kommt, ist dasselbe Control-Plane-Prinzip, das die Bereiche im Lebenszyklus eines Agenten erreicht, die es bisher noch nicht berührt – die Fragen, die Governance-Teams bereits zum menschlichen Zugriff stellen, werden nun auch für Agenten gestellt:

• Zertifizierung des Agent-Zugriffs: Stellt sicher, dass die Berechtigung jedes Agents der gleichen Bestätigung und Überprüfung unterzogen wird wie jeder andere Zugriff, wobei Ressourcenverantwortliche bestätigen, was beibehalten werden soll, und widerrufen, was veraltet ist. 
• Zugriffsgraph von Identität zu Ressource: Verfolgt den vollständigen Pfad von einer Person über jeden Agenten, der für sie agiert, bis hin zu den Ressourcen und Scopes, auf die jeder zugreifen kann. So ist der Schadensradius sichtbar, bevor etwas schiefgeht, und das Ziel für den Widerruf ist im Ernstfall offensichtlich. 
• Human-in-the-Loop-Genehmigung: Bei der Provisionierung und bei der Durchführung einer sensiblen Aktion bleibt eine Person in die Entscheidungsfindung eingebunden, wo es am wichtigsten ist. 
• Unbeaufsichtigte Befugnis: Agenten beginnen, sich unbeaufsichtigte Befugnisse basierend auf ihrem Verhalten zu verdienen, anstatt dass Vertrauen im Voraus gewährt wird.

Nichts davon ist eine neue Steuerungsebene. Es ist derselbe, der sich von dem Moment, in dem ein Agent erstellt wird, bis zu dem Moment erstreckt, in dem seine Befugnis überprüft, eingeschränkt oder entzogen wird.

Ein Konzept für den sicheren Einsatz von Agenten in Unternehmen

Betrachtet man das Gesamtbild, beantwortet die Architektur die drei Fragen, die sich jedes Security-Team stellt (Abbildung 11):

1. Wo sind meine Agenten? (Diejenigen, die das Unternehmen entwickelt hat, und diejenigen, die von selbst hinzugekommen sind.) 
2. Womit können sie sich verbinden? (Von MCP-Servern und SaaS-Apps bis hin zu anderen Agenten, Service-Accounts und Legacy-Bestandssystemen.) 
3. Was dürfen sie tun? (Zur Laufzeit entschieden, in wichtigen Fällen an einen Menschen eskaliert und widerrufbar, wenn es nicht nach Plan läuft.)

Diese drei Fragen bilden die operative Grundlage für den Agentic Enterprise Blueprint.

Der Okta-Blueprint zur Absicherung von KI-Agenten in großem Maßstab

Unternehmen wie Uber haben die Notwendigkeit verdeutlicht, diese Art der Governance für KI-Agenten zu schaffen.  Aber nicht jedes Unternehmen muss dies selbst aufbauen.

Der rote Faden durch jede Ebene ist derselbe: Identity ist die Steuerungsebene, die Autorisierung wird zur Laufzeit entschieden und auf die Aufgabe beschränkt, die verantwortliche Person begleitet die Anfrage, und das Ganze basiert auf offenen Standards, sodass es für jeden Anbieter gilt, mit dem ein Agent in Berührung kommt. 

Agenten unter diesen Bedingungen als vollwertige Identitäten zu behandeln, ist der richtige Weg, um das agentengesteuerte Unternehmen abzusichern, und Okta for AI Agents macht dies zu einer Ebene, die Sie implementieren, anstatt zu einem System, für dessen Aufbau Sie ein Jahr benötigen.  Die Architektur in diesem Beitrag ist etwas, das Sie übernehmen, nicht etwas, das Sie selbst aufbauen. 

Erfahren Sie, wie Okta und Auth0 KI-Agenten absichern, oder sprechen Sie mit unserem Team.