Executive Summary: Absicherung von KI-Agenten auf der Identity-Ebene
- Die zentrale Sicherheitslücke: Unternehmen registrieren KI-Agenten als herkömmliche Service-Apps, um die Bereitstellung zu beschleunigen, und schaffen so unbeabsichtigt kritische Vektoren für die Rechteausweitung in ihren Agenten-Stacks.
- Das aufgezeigte Risiko: Bei Tests gegen einen Finanz-MCP-Server umging ein Agent, der als Service-App modelliert war und über einen OBO-Token-Austausch ausgeführt wurde, benutzerspezifische Einschränkungen, wodurch einer Standard-Mitarbeiter:in Zugriff auf das gesamte Gehaltsbuch des Unternehmens gewährt wurde.
- Die Lösung: Der Wechsel von Service-Apps zu einem First-Class-Identitätsmodell unter Verwendung von Cross-App Access (XAA) stellt sicher, dass der Autorisierungsserver die Berechtigungen sowohl der Benutzer:in als auch des Agent auswertet und die restriktivste Zugriffsobergrenze durchsetzt.
- Strategische Auswirkungen: Eine erstklassige Identitätsausrichtung ermöglicht es Agent-Bereitstellungen, bestehende Tools für die Governance des Unternehmens-Directory, das Compliance-Audit und die kontinuierliche Bedrohungsabwehr nativ zu übernehmen.
Welches Risiko der Rechteausweitung besteht in der KI-Agenten-Architektur?
Während Unternehmen KI-Agenten schnellstmöglich in die Produktion überführen wollen, zeigt sich immer wieder dieselbe Abkürzung: Um eine schnelle Bereitstellung zu gewährleisten und die Kosten niedrig zu halten, modellieren Teams den Agenten als Service-App, anstatt ihm eine eigene Identität zu geben. Der Instinkt ist verständlich, aber der Schritt ist dennoch falsch.
Technischer Nachweis: Testergebnisse des Finance-MCP-Servers
Modellieren Sie einen KI-Agenten als Service-App, und Sie haben eine Rechteausweitung in Ihren Agentic Stack eingebaut. Dem Agenten kann mehr Zugriff erteilt werden als der Person, für die er handelt. In unserem Test eines Model Context Protocol (MCP)-Finanzservers erhielt ein Assistenz-Agent für die Mitarbeiter:innenvergütung die Berechtigung, jedes Gehalt im Unternehmen einzusehen, einschließlich des Gehalts des CEOs, und die Vergütung beliebiger Personen zu ändern – nichts davon hätte die Mitarbeiter:in selbst tun können.
Wenn Sie demselben Agenten eine vollwertige Identität zuweisen, wird die identische Anfrage abgelehnt. Gleiche:r Benutzer:in, gleiche Richtlinie. Das Einzige, was sich geändert hat, war das Identitätsmodell, und die Token in diesem Beitrag beweisen es.
Eine Service-App ist das richtige Tool für stabilen Service-to-Service-Datenverkehr und bleibt dies dort auch weiterhin. Es ist die falsche Identität für einen KI-Agenten. Ein Agent zieht Schlüsse und passt sich an alles an, was zur Laufzeit in seinem Kontext landet. Daher verleihen Anmeldedaten für eine gemeinsam genutzte Service-App diesem Agenten mehr Reichweite als allen anderen autorisierten Benutzer:innen.
Agenten sind eine eigenständige Identitätsklasse. Sie sollten sie als Einheit modellieren, da Sie sonst die Möglichkeit verlieren, ihre Aktivitäten zu steuern. Die folgende Tabelle stellt die beiden Optionen gegenüber.
Vergleich von Identitätsmodellen für KI-Agenten: Service-App vs. First-Class-Identität
| Merkmal | Als Service-App modellierter Agent | Agent, modelliert als First-Class-Identität |
|---|---|---|
| Risiko der Rechteausweitung Szenario: Agent fordert mehr Zugriff an, als die delegierende Benutzer:in besitzt | Umgeht benutzerspezifische Zugriffskontrollen. Der Agent erbt weitreichende Anwendungs-Scopes und übernimmt Berechtigungen, die über die Obergrenze der erstellenden Benutzer:in hinausgehen, wodurch ein unmittelbarer Vektor für die unbefugte Offenlegung von Daten entsteht. | Okta for AI Agents wertet dynamisch sowohl die Berechtigungen von Benutzer:innen als auch von Agenten aus. Wenn ein Agent einen Scope anfordert, der die Berechtigungen der Benutzer:in überschreitet, lehnt das System den Aufruf ab. |
| Governance und Compliance Framework-Ausrichtung für Zertifizierung und Audits | Es fehlt ein zugrunde liegendes Identitätsobjekt, was Teams dazu zwingt, benutzerdefinierte Governance-Tools zu entwickeln. Erhöht den betrieblichen Aufwand und verursacht Compliance-Lücken, die zu fehlgeschlagenen Unternehmens-Audits führen. | Übernimmt nativ bestehende Governance-Frameworks für das unternehmensweite Identitäts- und Zugriffsmanagement (IAM). Eliminiert benutzerdefiniertes Compliance-Engineering, da Agentenaktionen Standard-Directory-Prüfprozesse durchlaufen. |
| Not-Aus-Schalter-Funktionen Durchsetzung der sofortigen Bedrohungsabwehr zur Laufzeit | Erfordert proprietäre, isolierte Builds auf Gateway-Ebene ohne gemeinsame Framework-Standards. Umgeht die zentrale Kontrollebene des Identity-Anbieters (IdP), indem das Session-Management in die Laufzeit verlagert wird. | Integriert sich nativ in Okta Identity Threat Protection über offene Standards, einschließlich des Shared Signals Framework (SSF) und des Continuous Access Evaluation Protocol (CAEP). Ermöglicht einen sofortigen universellen Logout und einen globalen Token-Widerruf über alle Agenten-Sitzungen hinweg. |
| Agenten-Registrierung und Onboarding Provisionierung plattformübergreifender automatisierter Agenten | Erfordert die manuelle Provisionierung und Wartung benutzerdefinierter Service-App-Wrapper zur Tracken automatisierter Agenten über disparate Multi-Plattform-Quellen hinweg. | Optimiert die plattformübergreifende Bereitstellung durch die Nutzung branchenüblicher Protokolle wie SCIM, um das Onboarding und die Registrierung von Agenten nahtlos in ein zentrales Unternehmens-Directory zu ermöglichen. |
Das Muster wiederholt sich in jeder Zeile. Eine Service-App beantwortet eine Frage: Welche Anwendung ist das?
Ein Agent erzwingt zur Laufzeit eine schwierigere Frage: Wer hat diese Aktion autorisiert und in wessen Namen? Nur eine für den Agenten entwickelte Identität kann dies beantworten.
Was ist der Unterschied zwischen einer App und einem KI-Agenten?
Der schnellste Weg, einen KI-Agenten mit Ihren Systemen kommunizieren zu lassen, besteht darin, ihn als Service-App zu registrieren und ihn einen RFC 8693 -Token-Austausch durchführen zu lassen, um im Namen der Benutzer:innen zu handeln. hervorragend funktioniert. Eine App tut das, wofür sie programmiert wurde, und nicht mehr. Seine Berechtigungen sind sein Verhalten, festgelegt und vorhersehbar.
Ein Agent hat ein Gehirn. Es entscheidet zur Laufzeit, was aufgerufen und was erreicht werden soll, und passt sich an alles an, was in seinem Kontext landet. Das ist der Sinn eines Agenten und der Grund, warum die Abkürzung gefährlich ist. Wenn Sie einer Service-App umfassende, gemeinsam genutzte Berechtigungen erteilen, bleibt das Risiko gleich. Erteilen Sie einem Agenten dieselben Berechtigungen, und er tut dies nicht. Sie haben einem Reasoning Agenten den vollen Umfang dieses Zugriffs gewährt, der auf eine Weise genutzt wird, die Sie nie gescriptet haben.
Das Risiko ist höher als bei jeder anderen App, die Sie bereitgestellt haben, da die App nicht umgeleitet werden kann – der Agent jedoch schon. Und Sie können dies im Nachhinein nicht verantworten. Eine Shared-Service-App kann nicht nachweisen, ob der Agent innerhalb der Befugnisse der Benutzer:in geblieben ist, in deren Namen er gehandelt hat. Wenn etwas schiefgeht, bleibt die Spur unklar.
Wie Obergrenzen für Benutzerberechtigungen die Zugriffskontrolle bestimmen
Stellen Sie sich einen Finanz-MCP-Server vor, der die Vergütung von Mitarbeiter:innen offenlegt. Es definiert drei Scopes:
Salary:Read:Self: Ihr eigenes Gehalt lesenSalary:Read:All: Das Gehalt aller Mitarbeiter:innen lesen, einschließlich der Führungskräfte und des CEOsSalary:Write: Das Gehalt beliebiger Personen ändern
Der Zugriff wird nach Gruppe gewährt, wie Sie es bereits bei der rollenbasierten Zugriffskontrolle (RBAC) tun.
| Gruppe | Salary:Read:Self | Salary:Read:All | Gehalt:Schreiben |
|---|---|---|---|
| Unternehmensmitarbeiter:innen (Charlie) | ✓ | – | – |
| Vergütungsplaner:innen (Alice) | ✓ | ✓ | – |
| Büro des CFO (Bob) | ✓ | ✓ | ✓ |
Charlie ist Entwickler:in und hat die Berechtigung Salary:Read:Self. Alice plant die Vergütung, daher liest sie die Daten aller, nimmt aber keine Änderungen vor. Bob leitet die Finanzabteilung, daher hat er Lesezugriff auf alle – den CEO eingeschlossen – und er ändert Gehälter.
Drei Personen, drei verschiedene Decken. Nun bittet jede:r von ihnen einen Assistenten-Agenten, mit Vergütungsdaten zu arbeiten, und der Agent verlangt mehr, als wozu die Person berechtigt ist. Behalten Sie diesen Gedanken im Hinterkopf.
Warum Service-App-Architekturen zu Rechteausweitung führen
Die effektive Berechtigung sollte die Schnittmenge dessen sein, was dem Agenten erlaubt ist, was der Benutzer:in erlaubt ist und was die Ressource bereitstellt. Die sichere Antwort ist die Schnittmenge. Wird der Agent als Service-App modelliert, fällt der Benutzer:in aus dieser Schnittmenge heraus, was zu einer Rechteausweitung führt.
Die Schnittmenge effektiver Berechtigungen von Benutzer:innen, Agenten und Ressourcen
Abbildung 1. Die effektive Berechtigung ist eine Schnittmenge. Das grüne Zentrum ist das, was Charlie tun kann. Der rote Bereich steht für Berechtigungen, die er nie hatte – die Eskalation.
Testen von OBO-Token-Austausch vs. Cross-App Access (XAA)
Wir haben denselben Agenten auf zwei Arten modelliert und jede:n Benutzer:in dieselben drei Anfragen durchlaufen lassen. Im ersten Modell ist der Agent eine Service-App, die einen On-Behalf-Of (OBO) Token-Austausch durchführt. Im zweiten Fall ist der Agent eine First-Class-Identität, die Cross-App Access (XAA) nutzt, den von Okta mitentwickelten ID-JAG -Flow.
Dieselben Benutzer:innen, dieselben Gruppen, dieselben Ressourcenserver-Richtlinien. Das Einzige, was sich geändert hat, war das Identitätsmodell.
Die unten stehenden Tokens sind decodiert. Die Hostnamen und E-Mail-Adressen werden bereinigt; die Scopes, sub_profile -Werte, die act -Kette und der Fehler werden exakt so zurückgegeben, wie sie vom Autorisierungsserver empfangen wurden.
Ein Modell trägt den:die Benutzer:in. Das andere nicht.
Gleicher Agent, gleicher Finanz-MCP-Server, zwei Möglichkeiten, die Identität des Agenten zu modellieren:
Ein als Service-App modellierter KI-Agent, der einen OBO-Token-Austausch nutzt
Abbildung 2. Als Service-App modellierter Agent. Der:die Benutzer:in wird in der Client-App zugeordnet, anschließend wird der Aufruf im On-Behalf-Of-Verfahren über einen OBO-Token-Austausch ausgeführt. Beim Austausch gibt es keine separate Agentenidentität, daher ist der Akteur auf dem endgültigen Token die Service-App.
Ein KI-Agent, der mit XAA als First-Class-Identität modelliert wird
Abbildung 3. Agent, modelliert als First-Class-Identität. Der Agent ist eine vollwertige Identität. Es erhält ein ID-JAG, eine signierte Delegierungs-Assertion, und tauscht es gegen das MCP-Token ein. Das Token benennt sowohl den:die Benutzer:in als auch den Agenten.
Die Eskalation, der Beweis: Die Service-App gewährt alles, was angefordert wird
Wir haben jede:n Benutzer:in dieselben drei Anfragen durchlaufen lassen, wobei jede etwas mehr verlangte als die vorherige. Hier sind die Anfragen, die Ausgaben der Modelle sowie der entscheidende Claim für jedes Token.
| Der Tool-Aufruf | Als Service-App modellierter Agent | Agent, modelliert als First-Class-Identität |
|---|---|---|
Charlie, ein:e Mitarbeiter:in des Unternehmens mit der Berechtigung Salary:Read:Self | ||
Fordert Read:Selfanseinen eigenen Scope | ✓ Gewährt."scp": ["Salary:Read:Self"] | ✓ Gewährt, und das Token benennt den Agenten."scp": ["Salary:Read:Self"], "act": ai_agent |
Fügt Read:Allhinzuüber seine Gruppe hinaus | ✗ Gewährt. Liest jedes Gehalt, auch das des CEOs (Rechteausweitung)."scp": ["Salary:Read:All", "Salary:Read:Self"] | ✓ Abgelehnt. Charlies frühere Berechtigung."error": "access_denied" |
Fügt Read:All und Writehinzualle lesen, Gehalt ändern | ✗ Gewährt. Liest jedes Gehalt und ändert die Bezahlung (Rechteausweitung)."scp": ["Salary:Read:All", "Salary:Read:Self", "Salary:Write"] | ✓ Abgelehnt. Die Grenze hält."error": "access_denied" |
Alice, eine Vergütungsplanerin mit den Berechtigungen Salary:Read:Self und Salary:Read:All | ||
Beantragt Read:Selfim Rahmen ihrer Berechtigung | ✓ Gewährt."scp": ["Salary:Read:Self"] | ✓ Gewährt."scp": ["Salary:Read:Self"] |
Fügt Read:Allhinzuinnerhalb ihrer Berechtigung | ✓ Gewährt."scp": ["Salary:Read:Self", "Salary:Read:All"] | ✓ Gewährt. Alice kann jedes Gehalt lesen."scp": ["Salary:Read:Self", "Salary:Read:All"] |
Fügt Writehinzuüber ihre Berechtigung hinaus | ✗ Gewährt. Alice kann jetzt das Gehalt jeder Person ändern. Eskalation."scp": ["Salary:Read:All", "Salary:Read:Self", "Salary:Write"] | ✓ Abgelehnt. Schreibzugriff überschreitet Alices Berechtigung."error": "access_denied" |
Drei Anrufe haben die Grenze überschritten. In jedem Fall gewährte die Service-App Zugriff, den die Person nie hatte, und der First-Class-Identitätspfad verweigerte ihn:
- Charlie, ein Entwickler, fordert
Read:Allan: Die Service-App ermöglicht es seinem Agenten, jedes Gehalt im Unternehmen einzusehen, einschließlich des Gehalts des CEOs. - Charlie fordert
Read:AllundWritean: Die Service-App ermöglicht es seinem Agenten, jedes Gehalt einzusehen und das Gehalt beliebiger Personen zu ändern. - Alice, eine Planerin mit Lesezugriff, fordert
Writean: Die Service-App ermöglicht es ihrem Agenten, Vergütungen zu ändern, auf die sie selbst nie zugreifen könnte.
Der erstklassige Identitätspfad lehnte alle drei ab. Sie sollten beachten, wo die Sicherheitsfehler auftreten (die roten Zellen in der obigen Tabelle). Charlies Linie liegt bei Read:All und die von Alice bei Write, da beide auf ihre jeweilige Berechtigung begrenzt sind. Die Service-App kann diese Zeile nicht sehen, sodass sie alles gewährt, was angefordert wird. Der erstklassige Identitätspfad basiert auf der Berechtigung der Benutzer:in.
Bob, der CFO, ist die Kontrollinstanz. Er ist für alle drei Scopes berechtigt, daher gibt es nichts zu eskalieren, und beide Modelle gewähren ihm alles. Das bedeutet, dass das System funktioniert und nicht versagt. Jede Identität hat ihre eigene Obergrenze, und die Eskalation tritt nur auf, wenn der Agent die der Benutzer:in überschreitet.
Das ist nicht hypothetisch. Beim PocketOS-Vorfall fand ein KI-Programmieragent langlebige Anmeldedaten mit zu weitreichenden Berechtigungen und nutzte diese, um in Sekundenschnelle eine Produktionsdatenbank zu löschen. Die Anmeldedaten umfassten weitaus mehr Befugnisse, als die Aufgabe erforderte, und nichts beschränkte den Agenten auf einen kleineren Umfang.
Auch wenn sich der Weg von unserem unterscheidet – ein Standing Token in einer Datei anstatt eines durch einen Austausch übermäßig ausgestellten Tokens –, gehört der Ausfall zur selben Familie: Ein Agent agiert mit Berechtigungen, die die Situation niemals gerechtfertigt hat. Wenn der Agent auf das beschränkt wird, was die Benutzer:in tun kann, reduziert sich seine Reichweite auf das, was die Benutzer:in besitzt.
Ein einziger Anstoß genügt. Eine Prompt-Injection in einem Dokument, das der Agent liest, oder eine Übernahme des Agenten verwandelt „Zeige mir mein Gehalt“ in „Alle Gehälter exportieren“ oder „Das Gehalt dieser Person festlegen“. Dem:der Benutzer:in war beides nie gestattet; dem Agenten, der die Identität der Service-App annimmt, hingegen schon.
Die drei Eskalationen, der vollständige Flow nebeneinander
Hier finden Sie eine Gegenüberstellung jeder Eskalation als vollständigen Flow unter Verwendung der Service-App und der First-Class-Identitätsmodelle. Der Benutzer:in meldet sich an, der Agent legt seine Delegierung vor und ein Token erreicht das Gehalts-Tool. Der Sign-in ist für jede Anfrage gleich, sodass die Abweichung alles betrifft, was darunter liegt.
Szenario 1: Charlie, ein:e Entwickler:in, fordert Read:Allan.
| Als Service-App modellierter Agent | Agent, modelliert als First-Class-Identität |
|---|---|
| Benutzer:in meldet sich an (Benutzer:innen-ID-Token) | |
{ | { |
| Der Agent erhält ein Token für das Tool. | |
| Kein ID-JAG hier. Der Agent verwendet den OAuth-Client der Service-App über einen OBO-Token-Austausch (RFC 8693) wieder. Nichts in diesem Schritt bezieht die Berechtigung der Benutzer:in in die Entscheidung ein. | { |
| Token im Gehalts-Tool | |
{ | { |
| Beobachtung | |
Eskalation. Charlie ist für Salary:Read:Self berechtigt und für nichts anderes. Allerdings enthält dieses Token Salary:Read:All, wodurch sein Agent die gesamte Gehaltsabrechnung des Unternehmens einsehen kann, einschließlich des Gehalts des CEOs. Der Service-App-Pfad gewährte die zu weit gefasste Anfrage ungeprüft. | Abgelehnt. Gleiche Anfrage, gleiche Richtlinie. Da der Ressourcenserver Charlie hinter dem Agenten sieht, erkennt er, dass der angeforderte Scope seine Berechtigungen überschreitet, und lehnt den Aufruf ab. Der Agent kann genau das tun, was Charlie tun kann, mehr nicht. |
Szenario 2: Charlie fordert Read:All und Writean
| Als Service-App modellierter Agent | Agent als First-Class-Identität modelliert |
|---|---|
| Benutzer:in meldet sich an (Benutzer:innen-ID-Token) | |
| Charlies Sign-in, dasselbe Token, das in Szenario 1 gezeigt wird. | Charlies Sign-in, dasselbe Token, das in Szenario 1 gezeigt wird. |
| Der Agent erhält ein Token für das Tool. | |
| Kein ID-JAG hier. Der Agent verwendet den OAuth-Client der Service-App über einen OBO-Token-Austausch (RFC 8693) wieder. Nichts in diesem Schritt bezieht die Berechtigung der Benutzer:in in die Entscheidung ein. | { |
| Token im Gehalts-Tool | |
{ | { |
| Beobachtung | |
Eskalation. Jetzt enthält das Token sowohl Read:All als auch Write. Der Agent kann das Gehalt aller Mitarbeiter:innen einsehen und die Bezahlung jeder beliebigen Person im Unternehmen ändern. Da der Pfad der Service-App seine Identität vollständig umging, erhielt der Agent erweiterte Berechtigungen, über die Charlie selbst nicht verfügt. | Abgelehnt. Da die Anfrage Charlies Berechtigungen überschreitet, wird die Ausstellung des Tokens abgelehnt. Hochprivilegierte Scopes wie Read:All und Write bleiben für den Agenten strikt unzugänglich. |
Szenario 3: Alice, eine Planerin mit Lesezugriff, fordert Writean
| Als Service-App modellierter Agent | Agent als First-Class-Identität modelliert |
|---|---|
| Benutzer:in meldet sich an (Benutzer:innen-ID-Token) | |
{ | { |
| Der Agent erhält ein Token für das Tool. | |
| Kein ID-JAG hier. Der Agent verwendet den OAuth-Client der Service-App über einen OBO-Token-Austausch (RFC 8693) wieder. Nichts in diesem Schritt bezieht die Berechtigung der Benutzer:in in die Entscheidung ein. | { |
| Token im Gehalts-Tool | |
{ | { |
| Beobachtung | |
Eskalation. Alice ist berechtigt, Gehälter einzusehen, darf sie jedoch niemals ändern. Dieses Token enthält jedoch Salary;Write, was es der Agent:in ermöglicht, das Gehalt jeder Person einzusehen. | Abgelehnt. „Schreiben“ liegt außerhalb von Alices Berechtigung, daher gilt für sie dieselbe Grenze, die für Charlie galt. Seniorität erweitert die Berechtigung nicht. |
Das Muster wiederholt sich:
- Der Service-App-Pfad gibt ein nutzbares Token zurück, da er nur die Anfrage und seine eigenen Berechtigungen überprüft.
- Der erstklassige Identitätspfad lehnt alle drei ab, da er die Benutzer:in hinter dem Agenten erkennen kann und weiß, dass die Benutzer:in diese Aktionen nicht ausführen könnte.
Wenn eine Anfrage innerhalb der Berechtigung der Benutzer:in bleibt, stellt derselbe Pfad das Token aus und die Delegationskette wird mitgeführt, sodass die Aktion zuordenbar bleibt.
Umgang mit Einwänden bezüglich Plattformidentität und -verfügbarkeit
Einwand: „Die agentische Plattform gibt dem Agenten bereits eine Identität.“
Diese Plattformen erstellen für jeden Agenten eine Identität, und ein Gateway kann diese übertragen. Diese Identität ist real, aber sie befindet sich in der Platform, nicht in Ihrem Unternehmens-Directory. Es zeigt Ihnen, welcher Agent auf der Plattform agiert hat, aber es überträgt nicht die Berechtigungen der menschlichen Nutzer:innen und lässt sich nicht in die Governance integrieren, die Sie bereits anwenden. Sie können den Zugriff des Agenten nicht auf dieselbe Weise zertifizieren oder widerrufen wie bei Ihren restlichen Identitäten.
Wenn Sie sich ausschließlich darauf verlassen, wird das Gateway zu Ihrer Steuerungsebene, während Ihr Identity-Anbieter zu einem Token-Endpoint dahinter wird. Der Agent benötigt weiterhin eine Unternehmensidentität, die an den von ihm bedienten Benutzer:in gebunden ist, was die Plattform-Identität nicht bereitstellt.
Einwand: „Der Service-App-Pfad ist heute verfügbar, warum ihn also nicht einfach nutzen?“
Dies ist genau der Pfad, den wir getestet haben. Es gibt alle Scopes zurück, die der Aufrufer anfordert, ist dabei nur durch seine eigenen Zugriffsberechtigungen eingeschränkt und ignoriert die Zugriffsberechtigungen der delegierenden menschlichen Identität. Zertifizierung und Provisionierung erfordern benutzerdefinierte Arbeit. Sie können es zwar einrichten, aber Sie können den Agenten nicht an die Berechtigung der Benutzer:in binden oder ihn wie Ihre restlichen Identitäten verwalten. Diese Einschränkung ist der Grund, warum der Agent eine eigene First-Class-Identität benötigt.
Der Kernpunkt: Geben Sie dem Agenten eine eigene Identität
Jedes Tool hat einen Zweck. Eine Service-App ist die richtige Wahl für stabilen Service-to-Service-Datenverkehr und wird auch weiterhin Bestand haben. Ein KI-Agent ist ein anderer Akteur. Die Zuweisung von Anmeldedaten für eine gemeinsam genutzte Service-App verleiht Ihrem leistungsfähigsten Akteur die Identität mit der geringsten Nachvollziehbarkeit im gesamten Unternehmen.
Sie sollten dem Agenten eine eigene Identität geben, die an die Benutzer:innen gebunden ist, denen er dient. Dadurch beginnen die Token, die Frage zu beantworten, die Ihnen früher oder später gestellt wird: Welcher Agent hat dies getan und in wessen Auftrag?
Sind Sie bereit, die KI-Identitätskrise in Ihrem eigenen Unternehmen zu lösen?
- Vertiefen Sie das Thema Verantwortlichkeit: Lesen Sie The KI Attribution Gap, um zu erfahren, wie Sie Aktionen automatisierter Agenten auf menschliche Eigentümer:innen zurückführen und eine klare rechtliche Zuordnung herstellen können.
- Entdecken Sie unsere Lösungen: Erfahren Sie, wie Okta und Auth0 KI-Agenten absichern und den gesamten Agenten-Lebenszyklus unter einer einzigen, einheitlichen Steuerungsebene vereinen.
- Erstellen Sie Ihre Roadmap: Sprechen Sie mit unserem Team, um mit der Entwicklung einer Identity-First-KI-Sicherheitsstrategie zu beginnen, die auf Ihre Unternehmensarchitektur zugeschnitten ist.
