Ihr Unternehmen hat wahrscheinlich einige tausend Mitarbeiter mit verwalteten Identitäten. Die Personalabteilung hat sie bereitgestellt, die IT-Abteilung verwaltet sie, und Ihre IAM Die Plattform überwacht sie.
Zählen Sie nun die KI-Agenten, die in Ihrem Unternehmen im Einsatz sind. Der Claude Code und die Codex-Instanz, die in jeder Entwickler-IDE integriert sind. Der Salesforce Einstein-Bot mit Zugriff auf alle offenen Deals. Die Zapier-KI, die Ihr CRM ausliest, Nachrichten in Ihren Slack-Kanal schreibt und Zusammenfassungen per E-Mail versendet.
Man kann sie nicht zählen, sichern oder regieren mit traditionellen Methoden. IAM, kannst du?
Genau dieses Problem untersucht dieser Artikel. Was bedeutet die Identität eines KI-Agenten eigentlich, und warum bricht sie mit traditionellen Vorstellungen? IAMund wie man diese KI-Agenten auf Desktop-, SaaS- und Enterprise-Systemen steuert, bevor sie lernen, einen zu steuern.
Was ist die Identität eines KI-Agenten?
Einfach ausgedrückt ist ein KI-Agent eine Software, die im Auftrag eines Menschen oder eines Systems autonom Aktionen ausführt, ohne dass ein Mensch bei jedem Schritt auf „Bestätigen“ klicken muss.
Und wenn eine Software eine Aktion ausführt, benötigt sie dafür Anmeldeinformationen.
Die Identität eines KI-Agenten umfasst alle Anmeldeinformationen, Berechtigungen, Rollen und Attribute, die definieren, was ein KI-Agent ist und was er tun darf. Man kann sie sich wie Reisepass, Visum und Zugangsberechtigung in einem vorstellen.
KI-Agenten als nicht-menschliche Identitäten
Nicht-menschliche Identitäten (NHIs) existieren seit Jahrzehnten: Dienstkonten, API-Schlüssel, Bot-Benutzer, Maschinentoken. Ihre CI/CD-Pipeline authentifiziert sich als Dienstkonto. Ihr Überwachungstool verwendet einen API-Schlüssel, um Warnmeldungen zu veröffentlichen.
KI-Agenten stellen eine neue Klasse von NHI dar, weisen aber ein anderes Risikoprofil auf.
Ein herkömmliches Dienstkonto führt ein festes Skript aus. Es macht jedes Mal dasselbe, liest aus denselben Tabellen und schreibt in denselben Bucket. Sie können die Berechtigungen einmal überprüfen und sich danach kaum noch darum kümmern.
Ein KI-Agent trifft Entscheidungen. Er ermittelt anhand des Kontexts und der Anweisungen, die sich bei jeder Ausführung ändern, welches Tool aufgerufen, welches System beschrieben und welche API verwendet werden soll. Eine einzelne Copilot-Sitzung kann beispielsweise drei Dateien lesen, zwei APIs abfragen und in eine Datenbank schreiben, während eine andere Sitzung acht völlig unterschiedliche Aufgaben ausführen kann.
Diese Variabilität ist es, die den KI-Agenten ausmacht. IAM hart.
KI-Agenten vs. Maschinenidentitäten
Die Maschinenidentitätsverwaltung umfasst Zertifikate, Schlüssel und Token für Server, Container und Workloads. Der Workload weiß genau, was er zu tun hat. Die Identität definiert einen festen Gültigkeitsbereich.
KI-Agenten agieren oberhalb der Infrastrukturschicht. Sie sind Akteure auf Anwendungsebene mit dynamischem, absichtsgesteuertem Verhalten. Ein Kubernetes-Pod entscheidet nicht selbstständig, die Zahlungshistorie eines Kunden abzurufen. Ein KI-Agent hingegen tut dies, weil der Benutzer ihn aufgefordert hat, das Konto zusammenzufassen.
Die Bedrohungsfläche ist anders. Daher muss auch der Rahmen für die KI-Governance anders sein.
Warum traditionell IAM wurde nicht für KI-Agenten entwickelt
Classic IAM Es basiert auf einigen wenigen Annahmen: Ein Mensch meldet sich an, erhält eine Sitzung, führt eine Aufgabe aus und meldet sich wieder ab. Oder ein Dienstkonto läuft nach einem Zeitplan mit einem festen Gültigkeitsbereich.
KI-Agenten verstoßen gegen die meisten dieser Annahmen.
Sie laufen kontinuierlich, sitzungsübergreifend und manchmal ohne klaren Start oder Ende. Sie treffen Autorisierungsentscheidungen in Echtzeit und verketten diese oft über mehrere Systeme hinweg in einem einzigen Workflow. Andere Agenten können ihnen Berechtigungen erteilen (Delegation). Und sie werden von einzelnen Mitarbeitern bereitgestellt, nicht nur von der IT-Abteilung, was bedeutet, dass die Bereitstellung ohne zentrale Übersicht erfolgt.
Unternehmen IAM Es war für all das nicht konzipiert. Es wurde für Menschen an Tastaturen entwickelt.
Warum KI-Agenten einen anderen Ansatz benötigen IAM Modell
Autonome Entscheidungsfindung
Ein Benutzer in Salesforce sucht einen Kontakt. Ein KI-Agent in Salesforce könnte den Kontakt suchen, die zugehörigen Deals abrufen, das Unternehmen in Ihrem ERP-System abgleichen, eine Follow-up-E-Mail entwerfen und eine Kalendereinladung planen. Alles durch eine einzige Benutzereingabe.
Der Agent bestimmt die Handlungsabfolge. IAM Für Menschen entwickelte Tools können die Absicht hinter dieser Kette nicht bewerten. Sie können nur die einzelnen API-Aufrufe sehen, und jeder einzelne erscheint für sich genommen legitim.
Dauerhafter Zugriff und kontinuierliche Ausführung
Die meisten Agenten in Unternehmen melden sich nicht wie Benutzer an und ab. Sie verfügen über OAuth-Token, API-Schlüssel oder Sitzungsberechtigungen, die dauerhaft gespeichert werden. Ein KI-gestützter SaaS-Mitarbeiter kann beispielsweise monatelang ein Aktualisierungstoken mit Zugriff auf Ihren gesamten Google Workspace besitzen.
Das ist eine dauerhafte Berechtigung, die an eine Software gebunden ist, die autonome Entscheidungen trifft. Wenn diese kompromittiert wird oder sich ihr Verhalten ändert, erhalten Sie nicht unbedingt eine Anmeldebenachrichtigung. Sie sehen jedoch eine Protokollierung der technisch autorisierten Aktionen.
Dynamische Autorisierung und Tool-Nutzung
Agentenbasierte KI-Frameworks wie LangChain, AutoGPT und Microsoft Semantic Kernel ermöglichen Agenten den Zugriff auf Werkzeugbibliotheken. Der Agent wählt das jeweils zu verwendende Werkzeug anhand der Aufgabe aus.
Die tatsächlichen Berechtigungen des Agenten hängen also davon ab, welche Tools zur Laufzeit geladen werden, und nicht nur von der statischen Richtlinie. Sie können zwar eine Richtlinie festlegen, aber wenn diese die Tool-Zusammensetzung nicht berücksichtigt, kann der Agent möglicherweise auf Daten zugreifen, die Sie nicht freigeben wollten.
Systemübergreifender Zugriff und Delegierung
KI-Workflows in Unternehmen sind regelmäßig systemübergreifend. Ein Agent, der Daten aus Confluence liest, in Jira schreibt, eine REST-API aufruft und eine Slack-Benachrichtigung auslöst, führt in einem einzigen Workflow vier Autorisierungsprüfungen in vier verschiedenen Systemen durch.
Die meisten dieser Systeme wissen nicht, dass sie mit einem KI-Agenten kommunizieren. Sie sehen ein OAuth-Token, prüfen dessen Gültigkeit und befolgen die Anweisung. Es gibt keine Instanz, die prüft, ob die gesamte Kette plausibel ist.
KI-Agenten-Bereitstellungsmodelle für das Identitätsmanagement in Unternehmen
KI-Agenten gibt es in 3 Einsatzformen, und jede erzeugt ein anderes Problem im Bereich des Identitätsmanagements.
Desktop-KI-Agenten
Desktop-Agenten laufen lokal auf den Rechnern der Mitarbeiter. Beispiele hierfür sind GitHub Copilot, Cursor, Tabnine, Microsoft Copilot unter Windows oder ein beliebiger lokal gehosteter LLM, der über ein Tool wie Open Interpreter mit einer Shell verbunden ist.
Diese Agenten haben Zugriff auf das lokale Dateisystem, lokale Anmeldeinformationen, Browsersitzungen und mitunter auch auf die Zwischenablage. Sie unterliegen den lokalen Berechtigungen des jeweiligen Benutzers, was bedeutet, dass die IT-Abteilung ohne eine Endpunkt-DLP-Lösung nahezu keine Transparenz hat.
Ein Entwickler, der einen lokalen Agenten ausführt, der seine SSH-Schlüssel, seine `.env`-Dateien und seinen Git-Verlauf ausliest, übergibt einer Software, die autonome Entscheidungen trifft, eine Menge sensibler Daten. Die meisten Organisationen haben hierfür keine Richtlinien.
SaaS-KI-Agenten
KI-Agenten im SaaS-Bereich sind die am schnellsten wachsende Kategorie. Jede große SaaS-Plattform bietet mittlerweile KI-Funktionen an: Salesforce Einstein, HubSpot AI, Notion AI, Zendesk AI, Intercom Fin.
Jede dieser Komponenten fordert während der Einrichtung OAuth-Berechtigungen an. Jede Komponente erhält ein dauerhaftes Token. In den meisten Unternehmen installieren einzelne Mitarbeiter oder Teamadministratoren diese Komponenten ohne Beteiligung der zentralen IT-Abteilung.
Das Ergebnis ist eine unkontrollierte Ausbreitung von KI-Identitäten: Dutzende von KI-Agenten sind über SaaS-Tools verstreut, jeder verfügt über weitreichende OAuth-Berechtigungen, keiner von ihnen wird zentral überwacht, und einige von ihnen sind wahrscheinlich noch für Mitarbeiter aktiv, die das Unternehmen vor 6 Monaten verlassen haben.
Enterprise-KI-Agenten
Enterprise-Agenten sind speziell entwickelte KI-Systeme, die auf Organisationsebene eingesetzt werden: interne Chatbots, die auf Azure OpenAI basieren, Workflow-Agenten auf LangChain-Basis, KI-Funktionen von ServiceNow oder benutzerdefinierte Python-Skripte, die eine LLM-API einbinden.
Diese sollten am besten kontrolliert werden. Aber das Wort „sollten“ ist hier sehr irreführend.
Enterprise-Agenten werden häufig von einzelnen Teams ohne Sicherheitsprüfung eingesetzt. Sie laufen unter Dienstkonten, die schnell bereitgestellt und nie wieder überprüft wurden. Sie erhalten weitreichenden Datenbankzugriff, da die korrekte Festlegung von Berechtigungen Zeit in Anspruch nimmt und das Team unter Zeitdruck stand.
Sicherheitsrisiken in KI-Agentenidentitäten
Hier liegt das Problem: Die meisten Unternehmen haben nicht nur ein Problem mit der KI-Identität, sondern drei separate, die nicht miteinander kommunizieren.
Desktop-KI-Agenten unterliegen (oder nicht) den Richtlinien des Endgeräts. SaaS-KI-Agenten unterliegen (oder nicht) den Richtlinien des SaaS-Zugriffsverwalters. Enterprise-KI-Agenten unterliegen (oder nicht) den Richtlinien des Entwicklerteams.
Das Ergebnis sind drei voneinander getrennte Identitätsinseln. Ein Auftragnehmer kann aus Active Directory entfernt und aus Okta gelöscht werden, und trotzdem kann er noch immer über ein aktives SaaS-KI-Token verfügen, das Ihr CRM erreicht, weil niemand diese Zusammenhänge erkannt hat.
Oder: Einem Mitarbeiter werden Phishing-Zugangsdaten gestohlen, der Angreifer meldet sich mit dessen Zugangsdaten an und nutzt dessen bestehenden SaaS-KI-Copilot-Zugang, um Vertriebsdaten der letzten drei Monate zu exfiltrieren. Die SaaS-KI löste keine Warnung aus, da die Zugangsdaten gültig waren.
In den Lücken zwischen den Inseln ereignen sich die Zwischenfälle.
Sicherung von Desktop-KI-Agenten
Lokale Identitätsisolation
Desktop-Agenten sollten in isolierten Umgebungen ohne Zugriff auf Anmeldeinformationen außerhalb ihres Zuständigkeitsbereichs ausgeführt werden. Konkret bedeutet dies: ein separates Benutzerkonto des Betriebssystems, ein Container oder zumindest eine virtuelle Umgebung, die nicht die vollständige Anmeldeinformationskette des Benutzers erbt.
Jeder Agent, der lesen kann ~/.ssh/ or ~/.aws/credentials hat Zugriff auf Schlüssel, die nie dafür bestimmt waren.
Zugriff mit den geringsten Rechten
Geben Sie dem Agenten genau das, was er für seine Aufgabe benötigt. Ein Programmierassistent benötigt Zugriff auf das Repository-Verzeichnis. Er benötigt keinen Zugriff auf den Download-Ordner, die Passwortmanager-Erweiterung oder den System-Schlüsselbund.
Dies setzt voraus, dass die Organisationen genau definieren, was jeder einzelne Mitarbeiter tut, was die meisten bisher noch nicht getan haben.
Sichere Endpunktverwaltung
Desktop-Agenten sollten denselben Zugriffsrichtlinien wie menschliche Benutzer unterliegen und auf dieselbe Weise von nicht verwalteten Geräten gesperrt werden. Entwicklerrechner erfordern besondere Aufmerksamkeit, da dort Cloud-Schlüssel, Datenbankpasswörter und Signaturzertifikate gespeichert sind.
Bei KI-Codierungswerkzeugen wie Copilot oder Cursor sollten Gerätekonformitätsrichtlinien mit Geheimnismanagement (HashiCorp Vault, AWS Secrets Manager) kombiniert werden, damit Agenten niemals Klartext-Anmeldeinformationen erhalten.
Sicherung von SaaS-KI-Agenten
OAuth-Governance
OAuth-Tokens stellen die primäre Angriffsfläche für KI-Agenten in SaaS-Umgebungen dar. Ein Agent, der OAuth-Tokens angefordert hat, ... mail.read, calendar.readwrite und files.readwrite.all Am ersten Tag hatte er auch ein Jahr später noch alle drei Zielfernrohre, obwohl er sie eigentlich nur einmal brauchte. mail.read.
Die Ausweitung des OAuth-Scopes ist ein reales und meist unbemerktes Problem. Sicherheitsteams benötigen Tools (wie Nudge Security, Grip Security oder die SaaS-Managementfunktionen von Okta), die jede OAuth-Berechtigung in der Organisation, die angeforderten Scopes und deren letzte Verwendung anzeigen.
Token, die 90 Tage lang nicht verwendet wurden, sollten überprüft werden. Sie werden widerrufen, wenn kein eindeutiger Inhaber vorhanden ist.
KI-Zugriffssteuerung mit Zero-Trust-Richtlinien
Mitarbeiter installieren KI-basierte SaaS-Tools genauso wie alle anderen SaaS-Tools: ohne die IT-Abteilung zu konsultieren. Das ist nach wie vor das gleiche Problem der Schatten-IT.
Die Governance von Drittanbieter-Apps bedeutet, dass für KI-Tools ab einer bestimmten Berechtigungsschwelle (Lese- und Schreibzugriff auf E-Mails oder Dateien) eine Vorabgenehmigung erforderlich ist. Anschließend sollte das Zero-Trust-Prinzip auf der API-Ebene angewendet werden.
Zero Trust für KI-Agenten bedeutet, jeden API-Aufruf als potenziell verdächtig zu behandeln, unabhängig von der Gültigkeit der Anmeldeinformationen. Überprüfen Sie die Identität, den Geräte- oder Dienstkontext und ob die angeforderte Aktion zum erwarteten Workflow passt, bevor Sie die Autorisierung erteilen.
CASB- Tools (Netskope, Zscaler, Microsoft Defender for Cloud Apps) können dies auf der Netzwerkschicht durchsetzen. Einige können den Datenverkehr auch nach KI-Agententyp klassifizieren.
KI-Aktivitätsüberwachung
Die meisten SaaS-Plattformen protokollieren die API-Aktivitäten. Diese Protokolle werden jedoch nicht automatisch in Ihr SIEM-System eingespielt, und die meisten SOC-Teams erstellen keine Erkennungsregeln für das Verhalten von KI-Agenten.
Mindestens sollten Sie die Audit-Protokollierung für jedes SaaS-Tool mit einer KI-Funktion aktivieren, diese Protokolle in Ihr SIEM exportieren und Basisregeln erstellen, die ungewöhnliche Datenmengen, Zugriffe außerhalb der Geschäftszeiten oder Zugriffsmuster, die nicht dem normalen Verhalten des Benutzers entsprechen, kennzeichnen.
Sicherung von KI-Agenten in Unternehmen
Lebenszyklusmanagement der KI-Identität
Jeder im Unternehmen eingesetzte KI-Agent benötigt ein Identitätslebenszyklusmanagement : Erstellung, Konfiguration, Überprüfung und Außerbetriebnahme.
Das bedeutet, Agentenidentitäten genauso zu behandeln wie menschliche Identitäten. Wenn jemand einen neuen Agenten einsetzt, IAM Es wird eine Dienstidentität mit definiertem Gültigkeitsbereich und einem expliziten Eigentümer erstellt. Wenn das Projekt endet oder der Eigentümer ausscheidet, wird die Identität deaktiviert.
Das Problem ist, dass die meisten Unternehmen kein Verzeichnis ihrer KI-Agenten führen.
Der Bau eines solchen Geräts ist der erste Schritt.
Richtlinienbasierte Autorisierung
Statische Rollenzuweisungen sind für Agenten mit dynamischem Verhalten ungeeignet. Ein besseres Modell ist die attributbasierte Zugriffskontrolle (ABAC) oder die richtlinienbasierte Autorisierung . Dabei werden die Berechtigungen des Agenten zur Laufzeit kontextbezogen ausgewertet: welche Aufgabe er ausführt, welcher Benutzer sie initiiert hat, welche Datenklassifizierung betroffen ist und welche Tageszeit es ist.
Open Policy Agent (OPA) und AWS Cedar sind genau für diese Art von feingranularer, kontextbezogener Autorisierung konzipiert. Beide können komplexe Bedingungen in Millisekunden auswerten.
Privilegierte Zugriffsverwaltung (PAM)
Manche KI-Agenten benötigen erweiterte Zugriffsrechte. Ein Agent zur Vertragsprüfung muss vertrauliche Rechtsdokumente lesen können. Ein Agent für den Sicherheitsbetrieb muss Rohdaten aus Protokolldateien abfragen können.
Diese Agenten sollten , wie privilegierte menschliche Benutzer, das PAM-Verfahren durchlaufen . Die Zugangsdaten werden aus einem Tresor abgerufen, Sitzungen protokolliert und der Zugriff zeitlich begrenzt. BeyondTrust, CyberArk und Delinea bieten Anleitungen zur Erweiterung von PAM auf nicht-menschliche Identitäten.
Kontinuierliche Überwachung und Prüfbarkeit
Ein fehlerhafter oder kompromittierter Agent verhält sich anders als ein normaler. Zu diesen Unterschieden gehören beispielsweise ungewöhnliche Datenmengen, unerwartete Systeme, ungewöhnliche Anfragen usw. Erfassen Sie das Verhalten jedes Agents mithilfe Ihres SIEM-Systems oder eines UBA-Tools und lassen Sie sich bei Abweichungen benachrichtigen.
Jede Aktion muss zu Prüfungszwecken protokolliert werden. Dies umfasst Angaben darüber, wer sie autorisiert hat, welche Daten betroffen waren und wann. DSGVO, SOC 2, HIPAA und die meisten Finanzvorschriften setzen diese Informationen für eine Prüfung voraus.
Aufbau eines einheitlichen KI-Identitäts-Governance-Frameworks
Vereinheitlichung bedeutet nicht ein einziges Werkzeug. Es bedeutet ein Rahmenwerk, das alle drei Bereitstellungstypen abdeckt.
Beginnen Sie mit einer Bestandsaufnahme . Prüfen Sie jedes KI-Tool in Ihrem Unternehmen, jedes Servicekonto, das einen LLM-gestützten Workflow ausführt, und – wenn möglich – die lokale KI-Konfiguration jedes Entwicklers. Sie werden von der Anzahl überrascht sein.
Definieren Sie anschließend Ihre Klassifizierungsstufen.Ein Tier-1-Agent (nur Lesezugriff, einzelnes System, eingeschränkter Datenbereich) erhält eine beschleunigte Genehmigung. Ein Tier-3-Agent (mehrere Systeme, Schreibzugriff, sensible Datenkategorien) durchläuft eine vollständige Sicherheitsprüfung. IAMRechts- und Datenverwaltung.
Erstellen Sie den Lebenszyklusprozess. Für die Erstellung wird ein Verantwortlicher benötigt. Jeder Agent erhält einen Eintrag in Ihrer CMDB oder Ihrem Servicekatalog. Vierteljährliche Zugriffsüberprüfungen gelten für Agentenidentitäten genauso wie für menschliche Personen. Die Außerbetriebnahme ist ein formaler Schritt und nicht einfach nur ein „Wir haben das Skript nicht mehr ausgeführt“.
Wenden Sie die Zero-Trust-Prinzipien auf Agentenebene an. Jeder Agentenaufruf wird geprüft: Ist diese Identität berechtigt, diese Aktion mit diesen Daten zu diesem Zeitpunkt durchzuführen? Verlassen Sie sich nicht allein auf die Gültigkeit der Anmeldeinformationen als Beweis für die Autorisierung der Aktion.
Zentralisieren Sie Ihre Protokollierung. Alle drei Agententypen sollten Aktivitätsprotokolle an dasselbe SIEM-System senden. Erstellen Sie Erkennungsregeln. Führen Sie Planspielübungen durch, die Szenarien mit KI-Agentenkompromittierung beinhalten.
Fazit
KI-Agenten entwickeln sich rasant zu einer der am schnellsten wachsenden Kategorien nicht-menschlicher Identitäten.
Ob sie auf Mitarbeitergeräten laufen, in SaaS-Plattformen eingebettet sind oder unternehmensweite Arbeitsabläufe orchestrieren – sie alle basieren auf Identität, Authentifizierung, Autorisierung und Governance.
Die Herausforderung besteht nicht einfach nur in der Verwaltung von KI-Identitäten in Unternehmen.
Es geht um die Verwaltung von Identitäten, die systemübergreifend mit minimalem menschlichem Eingriff handeln, entscheiden und interagieren können.
Dies erfordert einen modernen Ansatz für das KI-Identitätsmanagement, der Identitätsgovernance, Zugriffskontrolle, privilegiertes Zugriffsmanagement, Lebenszyklusmanagement und kontinuierliche Überwachung kombiniert.
Organisationen, die diese Kontrollmechanismen frühzeitig einführen, werden es deutlich leichter haben, die Einführung von KI im Unternehmen sicher zu skalieren.
Für Teams, die ihre IAM Strategien für KI-Agenten, Maschinenidentitäten, Mitarbeiteridentitäten und privilegierte Konten, Plattformen wie miniOrange Identitäts- und Zugriffsmanagement kann dazu beitragen, Authentifizierung, Autorisierung, Identitätsmanagement und Zugriffsverwaltung im gesamten Unternehmen zu zentralisieren.
Häufig gestellte Fragen
Was ist die Identität eines KI-Agenten?
Die Identität eines KI-Agenten ist die Gesamtheit der Anmeldeinformationen, Berechtigungen und Attribute, die definieren, was ein KI-Agent ist und wozu er innerhalb eines Systems oder einer Organisation befugt ist.
Wie funktioniert ein KI-Agent? IAM anders als traditionelle IAM?
Traditionell IAM Die Steuerung von Menschen und Dienstkonten mit festem Umfang wird von der IT-Infrastruktur übernommen. KI-Agenten hingegen verhalten sich dynamisch und zielgerichtet, können systemübergreifende Entscheidungen autonom treffen und werden häufig ohne zentrale IT-Kontrolle eingesetzt. Dies verändert den Rahmen für die KI-Governance grundlegend.
Wie lassen sich die Identitäten von KI-Agenten in einer Organisation sichern?
Zuerst die Analyse. Führen Sie ein Audit aller KI-Tools, aller OAuth-Berechtigungen und aller mit KI-Workflows verknüpften Dienstkonten durch. Anschließend erstellen Sie einen Klassifizierungs- und Genehmigungsprozess für neue Agenten. Danach stellen Sie sicher, dass die Protokolle an Ihr SIEM-System fließen.
Worin besteht der Unterschied zwischen maschinellem Identitätsmanagement und KI-Agenten-Identitätsmanagement?
Die Identitätsverwaltung von Maschinen regelt Identitäten auf der Infrastrukturschicht: TLS-Zertifikate, Serverschlüssel und Container-Token. Die Identitätsverwaltung von KI-Agenten regelt hingegen Akteure auf der Anwendungsschicht, die autonome Entscheidungen treffen. Da sich Umfang, Verhalten und Risikoprofil unterscheiden, müssen auch die Kontrollmechanismen unterschiedlich sein.
Hinterlasse einen Kommentar