KI-Agenten melden sich weiterhin als Menschen an – und Ihr Audit-Trail zahlt den Preis dafür
Cybersecurity-Risikomanagement · Lesezeit: 12 Minuten
Unternehmen haben in den letzten vier Jahren KI-Agenten in Identitätsinfrastrukturen integriert, die nie dafür ausgelegt waren, sie als eigenständige Akteure zu erkennen. Diese Diskrepanz zeigt sich inzwischen deutlich in den Daten, nicht erst in der Nachbetrachtung von Vorfällen. Ein neuer Bericht auf Basis anonymisierter Anmeldeaktivitäten von über 20.000 Unternehmen zeigt: KI-Agenten arbeiten in Unternehmensumgebungen noch weitgehend so wie zu Beginn der generativen KI – authentifiziert als Mensch oder über menschliche Identitäten.
Der zugrunde liegende Bericht, der Okta Enterprise AI Index, wertet Anmeldedaten von Juni 2022 bis Juni 2026 über mehr als 100 KI-Produkte aus, zusammengefasst in 74 Anbietersuiten. Schon die Größe des Datensatzes macht klar: Das ist kein Einzelfall. Es geht nicht um die Fehlkonfiguration eines einzelnen Anbieters oder den überstürzten KI-Rollout eines einzelnen Unternehmens. Es ist ein Muster, das sich über Zehntausende Unternehmen zieht, die sich bewusst oder unbewusst für denselben Weg entscheiden, Workflows von KI-Agenten zu autorisieren.
Die Wachstumszahlen sind beachtlich. KI-native Unternehmen wie Anthropic, OpenAI und Cursor haben ihre Unternehmenskundschaft im Untersuchungszeitraum mehr als vervierfacht. Im März 2026 zog Anthropic bei den Unternehmenskonten an OpenAI vorbei, einen Monat später auch bei den monatlich aktiven Nutzern. Solche Zahlen zeigen, wie schnell aus einer Experimentierphase ein fester Bestandteil des Arbeitsalltags geworden ist. Die wichtigere Erkenntnis liegt aber unterhalb der Wachstumskurve: Die Identitäts- und Zugriffspraktiken für KI-Agenten halten mit dem Tempo der Einführung nicht Schritt.
Kiteworks Secure Data Exchange geht einen anderen Weg: Jeder Akteur, der mit sensiblen Inhalten arbeitet, ob Mensch oder Maschine, braucht eine verifizierbare Identität, klar definierte Berechtigungen und einen eigenen Eintrag im Audit-Trail. Genau dieses Prinzip fehlt dem Bericht zufolge heute in den meisten KI-Deployments von Unternehmen.
Wichtige Erkenntnisse
Die KI-Einführung im Unternehmen überholt die Identitätspraktiken. Anmeldedaten aus vier Jahren und über 20.000 Unternehmen zeigen: KI-native Anbieter haben ihre Unternehmenskonten mehr als vervierfacht, während das dahinterliegende Identitätsmodell seit der Pilotphase kaum angerührt wurde.
KI-Agenten nutzen weiterhin menschliche Zugangsdaten. Servicekonten, statische API-Keys und geteilte menschliche Logins sind laut Okta-Forscherin Fei Liu nach wie vor der Standardweg, um Workflows von KI-Agenten zu autorisieren. Also Methoden, die für eine Welt ohne autonome Software-Akteure gedacht waren.
Ein geliehener Login zerstört den Audit-Trail. Meldet sich ein KI-Agent als Person an, tauchen im Protokoll Aktionen unter deren Namen auf, die diese Person nie ausgeführt hat. Eine genaue Rekonstruktion der Agentenaktivität im Ernstfall wird damit fast unmöglich.
Das Rennen Anthropic gegen OpenAI ist ein Symptom, keine Ursache. Dass Anthropic Anfang 2026 bei Unternehmenskonten und aktiven Nutzern an OpenAI vorbeizieht, belegt vor allem eines: wie schnell agentenbasierte KI in zentrale Geschäftsprozesse einzieht, schneller, als die meisten Identitäts- und Zugriffsprogramme reagieren können.
Agentenbezogene Zugriffskontrolle schließt die Lücke. Jeder KI-Agent bekommt eine eigene, kontrollierte Identität, eigene Berechtigungen und ein eigenes Audit-Protokoll, statt über eine menschliche Sitzung zu laufen. Das ist der Unterschied zwischen einer steuerbaren und einer unkontrollierten KI-Implementierung.
Servicekonten, statische API-Keys und geteilte Logins: drei Wege, wie Agentenidentität scheitert
Laut Fei Liu, der im Bericht zitierten Okta-Forscherin, stützen sich Unternehmen vor allem auf drei Mechanismen, um Workflows von KI-Agenten zu autorisieren: Servicekonten, statische API-Keys und manchmal geteilte menschliche Logins. Jeder dieser Wege löst kurzfristig ein Integrationsproblem und schafft langfristig ein Governance-Problem, das die meisten Unternehmen noch nicht angepackt haben.
Servicekonten sind am weitesten verbreitet. Sie erlauben es einem KI-Agenten, als nicht-menschliche Identität in einer Anwendung zu agieren. Das klingt nach dem richtigen Ansatz, bis man sieht, wie solche Konten meist eingerichtet und überwacht werden. Viele entstehen einmalig, bekommen weitreichende Access Controls für alle denkbaren Aufgaben des Agenten und geraten dann in Vergessenheit. Die Berechtigungen wachsen nicht mit, wenn sich die Rolle des Agenten verändert. Einzelne Aktionen lassen sich keiner konkreten Aufgabe, Anfrage oder geschäftlichen Begründung zuordnen. Das Konto existiert, der Agent nutzt es, und die Protokolle beschreiben das Konto, nicht die Arbeit. Damit sich Zugriffe überhaupt präzise eingrenzen lassen, müssen die Inhalte, auf die Servicekonten zugreifen können, mit Datenklassifizierungs-Labels versehen sein. Ohne sie kann kein Governance-Programm sensible Zugriffe für KI-Agenten wirksam beschränken.
Statische API-Keys bringen ähnliche Probleme mit sich, die der operative Umgang noch verschärft. Ein Key, der einem Agenten Zugriff auf Dateien, Datenbanken oder interne Systeme gibt, läuft meist nicht ab, wird nicht automatisch rotiert und landet häufig in Konfigurationsdateien, Umgebungsvariablen oder, schlimmer noch, direkt in Prompts oder Kontextfenstern des Agenten. Dort kann er unbemerkt offengelegt, mitprotokolliert oder abgezogen werden. Sobald ein Key an mehreren Stellen liegt, kann niemand mehr sicher sagen, wer eigentlich Zugriff hat.
Das dritte Muster, geteilte menschliche Logins, ist besonders heikel, weil es die Grenze zwischen Person und Prozess vollständig auflöst. Die Zugangsdaten eines Mitarbeiters gehen an ein Automatisierungsskript, einen Bot oder einen KI-Agenten, damit dieser in einem System als die Person auftreten kann, das keine eigene Provisionierung für Maschinenidentitäten kennt. Von da an erscheint jede Aktion des Agenten im Protokoll, als hätte der Mensch sie ausgeführt. Kommt es zu einem bestätigten Datenschutzverstoß über ein solches geteiltes Login, lässt sich das Ausmaß des Vorfalls nicht mehr sauber bestimmen. Meldepflichten nach HIPAA, DSGVO oder vergleichbaren Vorgaben gehen dann von der maximal möglichen Exposition aus, solange kein eindeutiger Nachweis sie eingrenzt. Ein vermischter Audit-Trail aus Mensch und Agent kann diesen Nachweis nicht liefern.
Warum „Wenn ein KI-Agent einen menschlichen Login übernimmt, verlieren Sie den Audit-Trail“ jeden CISO beunruhigen sollte
Lius Warnung im Bericht ist unmissverständlich: „Wenn ein KI-Agent einen menschlichen Login übernimmt, verlieren Sie Ihren Audit-Trail vollständig.“ Das ist ein konkreter technischer Fehler, kein abstraktes Risiko. Ein Audit-Trail nützt nur, wenn er im Nachhinein klar zeigt, wer was wann und warum getan hat. Sobald ein Agent unter einer menschlichen Sitzung arbeitet, protokolliert der Trail bei jedem Ereignis den falschen Akteur. Der Name im Log stimmt, die Geschichte dahinter nicht.
Genau dann zählt es, wenn ein Audit-Trail wirklich gebraucht wird: bei der Untersuchung eines Datenschutzverstoßes, einer Compliance-Prüfung, einer Anfrage von Aufsichtsbehörden oder der internen Nachverfolgung sensibler Inhalte. In all diesen Fällen fragt irgendwann jemand: War das ein Mensch oder ein automatisierter Prozess, und mit welcher Berechtigung? Lautet die Antwort „Wir wissen es nicht, weil der Agent als Sarah eingeloggt war“, stockt die Untersuchung, die Compliance-Reaktion verliert an Kraft, und das Unternehmen kann die geforderten Access Controls aus Frameworks wie NIST CSF, ISO 27001 und SOC 2 nicht nachweisen. Speist man dagegen einen sauberen, agentenbezogenen Audit-Log in Echtzeit in eine SIEM-Plattform ein, wird aus der Agenten-Attribution mehr als ein forensisches Werkzeug: Sie erkennt auffälliges Verhalten, bevor ein Vorfall eskaliert.
Es gibt noch einen weniger sichtbaren Preis, lange vor einem Vorfall. Verantwortlichkeit erodiert schleichend im Tagesgeschäft. Wenn niemand sicher sagen kann, welche Aktionen von Menschen und welche von KI-Agenten stammen, lassen sich Ausnahmegenehmigungen, Zugriffsprüfungen und das Prinzip der minimalen Rechte nur noch schwer korrekt umsetzen. Prüfer genehmigen im Zweifel breitere Zugriffe, weil eine Einschränkung riskant wirkt, solange sie nicht wissen, was der Agent wirklich braucht. So entstehen Security Misconfigurations nicht durch eine falsche Entscheidung, sondern durch viele scheinbar vernünftige, die alle auf einem Identitätsmodell beruhen, das Mensch und Software nicht trennt.
Shadow AI ist ein Identitätsproblem, bevor es ein Datenproblem wird
In den meisten Diskussionen über Shadow AI geht es darum, wo sensible Daten landen: in einem nicht genehmigten Modell, einem unkontrollierten Plugin oder einer Browser-Erweiterung. Das ist berechtigt, doch die Okta-Daten weisen auf einen früheren Punkt hin. Bevor ein Agent Daten bewegen oder offenlegen kann, muss er sich irgendwo authentifizieren. Läuft dieser Schritt über ein geteiltes Konto, einen unverwalteten API-Key oder einen geliehenen Login, hat das Unternehmen die Transparenz schon verloren, bevor die Frage nach Data Governance überhaupt gestellt wird.
Deshalb gehört Identität ins Zentrum jeder Diskussion über KI-Governance, nicht in eine Fußnote unter Data Loss Prevention. Ein Agent mit klar definierter, sauber verwalteter Identität ist von Anfang an begrenzt: Er kommt nur an das, was seine Rolle erlaubt, und jede Aktion lässt sich eindeutig ihm und seiner Aufgabe zuordnen. Ein Agent, der unter einer menschlichen Sitzung oder einem breiten Servicekonto läuft, ist praktisch unbegrenzt. Sein Zugriff entspricht dem des Menschen oder Kontos, oft weit mehr, als die Aufgabe verlangt. Programme für AI Data Governance, die bei Richtlinien anfangen, aber die Identitätsarchitektur auslassen, lösen nur die halbe Aufgabe. Shadow AI, also KI-Agenten und KI-Tools außerhalb eines Identitätsprogramms, ist die direkte Folge: unkontrollierte Agenten, die das Unternehmen weder sieht noch eingrenzen noch im Ernstfall zuordnen kann.
Der Kiteworks 2026 Data Security and Compliance Risk: Annual Forecast Report nennt KI-Governance als eine der wichtigsten Prioritäten für Unternehmen in diesem Jahr. Die Okta-Ergebnisse bestätigen das aus einem anderen Blickwinkel: Agentenbasierte Tools kamen schneller in die Unternehmen als die Zero-Trust-Kontrollen für Identität und Zugriff, die zu ihrer Steuerung nötig wären. Wer sein Lieferkettenrisiko-Management ernst nimmt, weitet die Anforderungen an Identitäts-Governance auch auf KI-Anbieter von Drittparteien aus, also auf die Agenten, die diese Anbieter in Kundenumgebungen einsetzen, nicht nur auf die selbst betriebenen Tools. Genau das schließt die Identitätslücke in der Lieferkette, die laut Okta-Daten bei den meisten Unternehmen noch offen ist.
Wie Kiteworks jedem KI-Agenten eine eigene verifizierbare Identität gibt
Kiteworks setzt am selben Punkt an wie die Okta-Erkenntnisse: Mensch und KI-Agent sind gleichwertige Identitäten, die einzeln authentifiziert, autorisiert und protokolliert werden müssen, unter einer Governance-Schicht statt unter zwei getrennten. Die Kiteworks Control Plane steuert jede Anfrage nach sensiblen Inhalten über dieses eine Modell, egal ob sie von einer Person, einer Anwendung oder einem Agenten kommt. So läuft der Zugriff eines Agenten nie über einen Umweg wie geliehene menschliche Zugangsdaten oder ein unverwaltetes Servicekonto.
Der Secure MCP Server wurde genau für diesen Fall gebaut. Er authentifiziert über OAuth 2.0 und legt das Zugriffstoken im sicheren Credential Store des Betriebssystems ab, nicht an einer Stelle, die das KI-Modell selbst auslesen, kopieren oder kompromittieren könnte. Das ist ein grundlegend anderes Design als ein statischer API-Key oder ein geteiltes menschliches Passwort: Der Agent hält nie ein Credential in der Hand, das er über einen Prompt, ein Logfile oder eine gekaperte Sitzung preisgeben könnte. Jede Aktion des Agenten, ob eine Datei lesen, durch einen Ordner navigieren oder Inhalte abrufen, wird in Echtzeit gegen RBAC- und ABAC-Richtlinien geprüft und einzeln protokolliert, nicht als pauschaler Eintrag unter dem Namen einer Person. Das ist die strukturelle Antwort auf Lius Warnung: Verlässt das Credential nie den gesicherten Speicher und wird jede Aktion einzeln autorisiert und protokolliert, gibt es keine geteilte Identität, die im Audit-Trail verschwinden könnte. Das CISO Dashboard zeigt diese agentenbezogene Audit-Telemetrie in Echtzeit und gibt der Sicherheitsleitung genau die durchgängige Transparenz über alle KI-vermittelten Zugriffe, die laut Okta-Bericht in den meisten Deployments fehlt.
Kiteworks Compliant AI zieht diese Linie nicht nur bei der Authentifizierung, sondern auch bei dem, was KI-Agenten sehen und nutzen dürfen. Richtlinien auf Inhaltsebene entscheiden, worauf ein Agent zugreifen darf und was ihm verwehrt bleibt, bevor Inhalte überhaupt ins Kontextfenster des Modells gelangen. So stützen sich Identitäts- und Datengrenzen gegenseitig, statt dass eine allein die andere absichern muss. Datenminimierung auf dieser Ebene, bei der jeder Agent nur die Inhalte für seine aktuelle Aufgabe bekommt, begrenzt den Schaden, falls ein Credential eines Agenten doch einmal kompromittiert wird, weil der Zugriff ohnehin von vornherein eng ist.
Ein agentenbezogenes Zugriffsmodell mit RBAC und ABAC aufbauen
Die Identitätslücke zu schließen heißt, über die Frage „Hat dieser Agent ein Credential?“ hinauszugehen, hin zu „Hat dieser konkrete Agent für diese konkrete Aufgabe genau die Berechtigung, die er jetzt braucht?“ Das ist eine Frage von Rollen und Attributen, keine statische Provisionierung.
Role-based Access Control (RBAC) gibt jedem Agenten eine klare Rolle, zugeschnitten auf seine tatsächliche Funktion. Ein Zusammenfassungsagent braucht zum Beispiel nur Lesezugriff auf die betreffenden Dokumente, ein Workflow-Agent Schreibzugriff auf einen bestimmten Ordner, mehr nicht. Attribute-based Access Control (ABAC) ergänzt das um Kontext: Sensitivität des Inhalts, Zeitpunkt der Anfrage, Umgebung, in der der Agent läuft, und die aktuelle Aufgabe fließen in die Autorisierung ein. Gemeinsam sorgen RBAC und ABAC dafür, dass ein Unternehmen einem Agenten genau den Zugriff gibt, den seine aktuelle Aufgabe erfordert, und nicht mehr, wie es bei den meisten Servicekonten heute üblich ist.
Dieses Modell liefert außerdem, was der Okta-Bericht schmerzlich vermisst: einen sauberen Audit-Log, in dem jeder Eintrag einen echten Agenten, eine echte Aufgabe und eine echte Richtlinie benennt, nicht den Namen einer Person für Arbeit, die sie nie getan hat. Bei einer Vorfallanalyse oder Compliance-Prüfung steht die richtige Antwort dann schon im Log. Ein dokumentierter Incident-Response-Plan, der auch Fehlfunktionen von KI-Agenten abdeckt, vor allem das Isolieren kompromittierter Agentenidentitäten, das Widerrufen der Credentials und das Eingrenzen der betroffenen Inhalte, macht aus dem Audit-Log ein Werkzeug für die operative Reaktion statt nur ein forensisches Nachschlagewerk.
Was Unternehmen jetzt tun sollten, um die Identitätslücke bei KI-Agenten zu schließen
Der Umfang des Okta-Datensatzes, vier Jahre, über 20.000 Unternehmen, über 100 KI-Produkte, zeigt: Das Problem betrifft nicht nur Vorreiter oder Nachzügler. Es ist nahezu flächendeckend. Die meisten Security- und Identity-Teams müssen handeln, unabhängig davon, wie reif ihr KI-Governance-Programm ist.
Einige konkrete Schritte ergeben sich direkt aus dem Bericht. Erstens: Erfassen Sie alle KI-Agenten in Ihrer Umgebung und halten Sie fest, welches Credential jeder nutzt, Servicekonto, API-Key oder menschlichen Login. Beheben können Sie nur, was Sie kennen. Zweitens: Behandeln Sie jeden Agenten, der sich über ein geteiltes menschliches Login authentifiziert, als sofortige Priorität, denn dieses Muster verursacht laut Bericht den größten Schaden am Audit-Trail. Drittens: Prüfen Sie, ob Ihre bestehende IAM-Infrastruktur überhaupt eigene, klar definierte Identitäten für nicht-menschliche Akteure vergeben kann oder ob sie nur für Menschen gedacht war. Viertens: Treffen Sie Zugriffsentscheidungen für KI-Agenten nach den Prinzipien des Zero-Trust-Datenaustauschs: jede Anfrage verifizieren, nur den nötigsten Zugriff gewähren und das Ergebnis protokollieren, statt dem Agenten wegen des Kontos zu vertrauen, unter dem er läuft. Eine formale Risikoanalyse, die Credential-Typ und Berechtigungen jedes Agenten mit seinen tatsächlichen Aufgaben abgleicht und zeigt, wo geteilte Credentials oder überprovisionierte Servicekonten untragbare Risiken schaffen, ist die Grundlage für einen priorisierten Maßnahmenplan.
Auf all das muss man keinen Vorfall abwarten. Die Okta-Daten beschreiben eine strukturelle Lücke in der Autorisierung von KI-Agenten, hier und heute, kein hypothetisches Risiko. Sie jetzt zu schließen, während die Einführung agentenbasierter KI weiter Fahrt aufnimmt, ist deutlich günstiger, als später einen Audit-Trail rekonstruieren zu wollen, den es nie gab.
Erfahren Sie mehr darüber, wie Sie KI-Agenten eine eigene, kontrollierte Identität geben, statt auf geliehene menschliche Zugangsdaten zu setzen: Vereinbaren Sie jetzt eine individuelle Demo.
Häufig gestellte Fragen
Was ist der Okta Enterprise AI Index und was misst er?
Der Okta Enterprise AI Index ist ein Bericht auf Basis anonymisierter Anmeldedaten von über 20.000 Unternehmen im Zeitraum Juni 2022 bis Juni 2026, der mehr als 100 KI-Produkte abdeckt, zusammengefasst in 74 Anbietersuiten. Er verfolgt, wie Unternehmen KI-Tools einführen, und vor allem, wie diese Tools in Unternehmensumgebungen authentifiziert und autorisiert werden. Das Ergebnis: KI-Agenten werden nach wie vor meist über Servicekonten, statische API-Keys oder geteilte menschliche Logins autorisiert, statt über Identitäten, die eigens auf den Agenten zugeschnitten sind. Wer die eigene Betroffenheit einschätzen will, sollte prüfen, wie die eigene IAM-Infrastruktur heute nicht-menschliche Akteure provisioniert. Unternehmen mit Compliance-Auflagen wie HIPAA, DSGVO oder CMMC sollten die im Okta-Bericht dokumentierte Authentifizierungslücke als Compliance-Feststellung behandeln, denn diese Frameworks verlangen nachweisbare Zugriffskontrollen und Audit-Records, ganz gleich, ob der Zugriff von einem Menschen oder einem Agenten ausgeht.
Warum macht es einen Unterschied, ob ein KI-Agent ein Servicekonto oder eine eigene Identität nutzt?
Ein Servicekonto wird meist einmalig mit weitreichenden Rechten ausgestattet, damit der Agent alle denkbaren Aufgaben erledigen kann, und danach selten wieder geprüft. Das führt dazu, dass der Agent oft viel mehr Zugriff hat, als seine aktuelle Aufgabe braucht, und dass jede Aktion dem Konto zugeordnet wird statt einer konkreten, nachvollziehbaren Aufgabe. Das widerspricht dem Prinzip der minimalen Rechte und schwächt genau die Access Controls, die Compliance-Frameworks fordern. Eine agentenbezogene Identität lässt sich dagegen genau auf die jeweilige Aufgabe zuschneiden. Datenminimierung schon bei der Einrichtung des Servicekontos, bei der jeder Agent nur an die Datenquellen kommt, die seine Aufgabe erfordert, macht aus der Richtlinie gelebte Praxis.
Wie zerstört ein geteiltes menschliches Login den Audit-Trail?
Meldet sich ein KI-Agent mit den Zugangsdaten einer Person an, werden alle Aktionen unter deren Identität protokolliert, auch die, die diese Person nie ausgeführt hat. Damit lässt sich bei einer Sicherheitsuntersuchung, Compliance-Prüfung oder Incident Response kaum noch trennen, was ein Mensch und was ein Agent getan hat. Fei Liu von Okta bringt es auf den Punkt: Sobald ein Agent einen menschlichen Login übernimmt, ist der Audit-Trail verloren, weil das Protokoll nicht mehr zeigt, wer oder was tatsächlich gehandelt hat. Agentenbezogene Credentials verhindern das, weil jeder Log-Eintrag den echten Akteur benennt. Zusätzlich sollten Unternehmen ihre SIEM-Warnregeln so einstellen, dass auffällige Muster in agentenbezogenen Logs, etwa ungewöhnliche Zugriffszeiten, Datenmengen oder Ressourcenanfragen, als hochpriorisierte Warnsignale behandelt werden.
Was ist der Secure MCP Server und wie verhindert er die Vererbung von Credentials?
Der Secure MCP Server ist die von Kiteworks kontrollierte Verbindung für KI-Agenten, die über das Model Context Protocol auf Unternehmensinhalte zugreifen. Statt dem Agenten ein statisches Credential zu geben, das er halten oder preisgeben könnte, läuft die Authentifizierung über OAuth 2.0, und das Token liegt im sicheren Credential Store des Betriebssystems. Jede Anfrage wird in Echtzeit gegen RBAC- und ABAC-Richtlinien geprüft. So bleiben Credentials vollständig außerhalb der Reichweite des Agenten, also genau das Problem gelöst, das der Okta-Bericht bei übernommenen menschlichen Logins beschreibt. Die Datenklassifizierung der Inhalte, die der Secure MCP Server verwaltet, macht die ABAC-Durchsetzung präzise: Zugriffsentscheidungen können im Moment der Anfrage zwischen öffentlichen und vertraulichen Inhalten unterscheiden, statt pauschal eine Berechtigung auf den gesamten Zugriffsumfang des Agenten anzuwenden.
Muss man für die Identitätslösung von KI-Agenten die bestehende Identity-Infrastruktur ersetzen?
Nicht zwingend. Wichtiger ist zunächst, KI-Agenten als eigene Klasse kontrollierter Identitäten bereitzustellen, neben menschlichen Anwendern und unter denselben Richtlinien, statt sie behelfsweise durch menschliche Sitzungen oder generische Servicekonten zu schleusen. Kiteworks setzt das über die Kiteworks Control Plane um, die Zugriff, Nutzung und Austausch sensibler Inhalte für Menschen und Agenten unter einer gemeinsamen Richtlinie steuert, kombiniert mit RBAC– und ABAC-Kontrollen, die auf die tatsächlichen Aufgaben jedes Agenten zugeschnitten sind. Eine Risikoanalyse, die zeigt, welche Agenten heute über geteilte Credentials laufen, und die Behebung nach der Sensitivität der zugänglichen Inhalte priorisiert, gibt Identity- und Security-Teams einen klaren, machbaren Startpunkt.
