KI-Agents melden sich weiterhin als Menschen an – und Ihr Audit-Trail zahlt den Preis dafür
Unternehmen haben in den letzten vier Jahren KI-Agents 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 nur in der Nachbetrachtung von Vorfällen. Ein neuer Bericht, der auf anonymisierten Anmeldeaktivitäten von über 20.000 Unternehmen basiert, zeigt: KI-Agents agieren in Unternehmensumgebungen weitgehend so wie zu Beginn der generativen KI – authentifiziert als Mensch oder über menschliche Identitäten.
Der Bericht, der Okta Enterprise AI Index, analysiert Anmeldedaten von Juni 2022 bis Juni 2026 über mehr als 100 verschiedene KI-Produkte, zusammengefasst in 74 Anbietersuiten. Die Größe des Datensatzes macht deutlich, dass es sich hier nicht um einen Einzelfall handelt. Es geht nicht um eine fehlerhafte Konfiguration eines einzelnen Anbieters oder einen überstürzten KI-Rollout eines Unternehmens. Es ist ein Muster, das sich über zehntausende Unternehmen erstreckt, die sich bewusst oder unbewusst für denselben Weg der Autorisierung von KI-Agent-Workflows entscheiden.
Die Wachstumszahlen sind beeindruckend. KI-native Unternehmen wie Anthropic, OpenAI und Cursor haben ihre Unternehmenskundenbasis im Untersuchungszeitraum mehr als vervierfacht. Im März 2026 überholte Anthropic OpenAI bei den Unternehmenskonten und im Folgemonat auch bei den monatlich aktiven Nutzern. Diese Meilensteine zeigen, wie schnell agentenbasierte KI von der Experimentierphase zum Standardwerkzeug im Unternehmen geworden ist. Doch die entscheidendere Erkenntnis liegt unterhalb der Wachstumskurve: Die Identity- und Access-Praktiken für KI-Agents halten mit der Geschwindigkeit der Einführung nicht Schritt.
Kiteworks Secure Data Exchange basiert auf einem anderen Ansatz: Jeder Akteur, der mit sensiblen Inhalten arbeitet – ob Mensch oder Maschine – benötigt eine verifizierbare Identität, klar definierte Berechtigungen und einen eigenen Eintrag im Audit-Trail. Genau dieses Prinzip fehlt laut Bericht in den meisten KI-Deployments von Unternehmen heute.
Wichtige Erkenntnisse
1. Die Einführung von KI im Unternehmen überholt die Identity-Praktiken.
Neue Anmeldedaten über vier Jahre und mehr als 20.000 Unternehmen zeigen, dass KI-native Anbieter ihre Unternehmenskonten mehr als vervierfacht haben, während das zugrunde liegende Identitätsmodell seit der Pilotphase kaum verändert wurde.
2. Agents nutzen weiterhin menschliche Zugangsdaten.
Servicekonten, statische API-Keys und geteilte menschliche Logins sind laut Okta-Forscherin Fei Liu nach wie vor der Standard, um KI-Agent-Workflows zu autorisieren – Methoden, die für eine Welt ohne autonome Software-Akteure entwickelt wurden.
3. Ein geliehener Login zerstört den Audit-Trail.
Authentifiziert sich ein KI-Agent als Person, erscheinen im Protokoll Aktionen unter dem Namen dieser Person, die sie nie durchgeführt hat. Das macht eine genaue Rekonstruktion der Agentenaktivitäten bei Vorfällen nahezu unmöglich.
4. Das Rennen Anthropic vs. OpenAI ist ein Symptom, nicht die Ursache.
Dass Anthropic OpenAI Anfang 2026 bei Unternehmenskonten und aktiven Nutzern überholt, bestätigt, wie schnell agentenbasierte KI in zentrale Geschäftsprozesse einzieht – schneller, als die meisten Identity- und Access-Programme darauf reagieren können.
5. Agentenbezogene Zugriffskontrolle schließt die Lücke.
Jeder KI-Agent erhält eine eigene, kontrollierte Identität, Berechtigungen und ein eigenes Audit-Protokoll – statt über eine menschliche Sitzung zu laufen. Das unterscheidet eine steuerbare KI-Implementierung von einer unkontrollierten.
Sie vertrauen darauf, dass Ihr Unternehmen sicher ist. Aber können Sie es nachweisen?
Jetzt lesen
Servicekonten, statische API-Keys und geteilte Logins: Drei Wege, wie Agentenidentität scheitert
Laut Fei Liu, der im Bericht zitierten Okta-Forscherin, verlassen sich Unternehmen stark auf drei Mechanismen, um KI-Agent-Workflows zu autorisieren: Servicekonten, statische API-Keys und in manchen Fällen geteilte menschliche Logins. Jeder dieser Ansätze löst ein kurzfristiges Integrationsproblem, schafft aber langfristig ein Governance-Problem, das die meisten Unternehmen noch nicht adressiert haben.
Servicekonten sind am weitesten verbreitet. Sie ermöglichen es einem KI-Agenten, als nicht-menschliche Identität in einer Anwendung zu agieren – scheinbar der richtige Ansatz, bis man sieht, wie diese Konten meist bereitgestellt und überwacht werden. Viele Servicekonten werden einmalig erstellt, erhalten weitreichende Access Controls für alle potenziellen Aufgaben des Agents und bleiben dann unbeachtet. Die Berechtigungen werden nicht angepasst, wenn sich die Rolle des Agents erweitert. Einzelne Aktionen werden nicht auf spezifische Aufgaben, Anfragen oder geschäftliche Gründe zurückgeführt. Das Konto existiert, der Agent nutzt es, und die Protokolle beschreiben das Konto – nicht die Arbeit. Die Anwendung von Datenklassifizierungs-Labels auf Inhalte, auf die Servicekonten zugreifen können, ist Voraussetzung für präzises Scoping – ohne sie kann ein Governance-Programm keine sensiblen Zugriffsbeschränkungen für Agents durchsetzen.
Statische API-Keys bringen ähnliche Probleme mit sich, die durch den operativen Umgang noch verschärft werden. Ein Key, der einem Agent Zugriff auf Dateien, Datenbanken oder interne Systeme gewährt, läuft meist nicht ab, wird nicht automatisch rotiert und landet oft in Konfigurationsdateien, Umgebungsvariablen oder – schlimmer noch – direkt in Prompts oder Agent-Kontextfenstern, wo er unbemerkt offengelegt, protokolliert oder exfiltriert werden kann. Sobald ein Key an mehreren Stellen existiert, kann niemand mehr mit Sicherheit beantworten, wer Zugriff hat.
Das dritte Muster, geteilte menschliche Logins, ist besonders kritisch, da es die Grenze zwischen Person und Prozess komplett auflöst. Die Zugangsdaten eines Mitarbeiters werden einem Automatisierungsskript, Bot oder KI-Agent übergeben, damit dieser als die Person in einem System agieren kann, das keine eigene Provisionierung für Maschinenidentitäten vorsieht. Von diesem Moment an erscheinen alle Aktionen des Agents im Protokoll, als hätte der Mensch sie durchgeführt. Ein bestätigter Datenschutzverstoß über ein geteiltes menschliches Login, das ein Agent genutzt hat, macht es unmöglich, das Ausmaß des Vorfalls korrekt zu bestimmen – Meldepflichten nach HIPAA, DSGVO oder ähnlichen Vorgaben gelten für die maximale mögliche Exposition, sofern keine eindeutigen Nachweise diese eingrenzen. Ein gemischter Human-Agent-Audit-Trail 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 eindeutig: „Wenn ein KI-Agent einen menschlichen Login übernimmt, verlieren Sie Ihren Audit-Trail vollständig.“ Das beschreibt einen konkreten, technischen Fehler – kein abstraktes Risiko. Ein Audit-Trail ist nur dann nützlich, wenn er im Nachhinein klar angibt, wer was, wann und warum getan hat. Sobald ein Agent unter einer menschlichen Sitzung agiert, protokolliert der Trail für jedes Ereignis den falschen Akteur. Der Name im Log stimmt – die Geschichte dahinter nicht.
Gerade in den Momenten, in denen ein Audit-Trail wirklich gebraucht wird – etwa bei der Untersuchung eines Datenschutzverstoßes, einer Compliance-Prüfung, einer Anfrage von Aufsichtsbehörden oder einer internen Nachverfolgung sensibler Inhalte – ist das entscheidend. In all diesen Szenarien stellt jemand irgendwann die Frage: Hat das ein Mensch getan oder ein automatisierter Prozess, und mit welcher Berechtigung? Ist die Antwort „Wir wissen es nicht, weil der Agent als Sarah eingeloggt war“, stockt die Untersuchung, die Compliance-Reaktion wird schwächer und das Unternehmen kann die geforderten Access Controls von Frameworks wie NIST CSF, ISO 27001 und SOC 2 nicht nachweisen. Wird ein sauberer, agentenbezogener Audit-Log in Echtzeit in eine SIEM-Plattform eingespeist, wird die Agenten-Attribution vom forensischen Werkzeug zur Verhaltensdetektion, die Anomalien erkennt, bevor ein Vorfall eskaliert.
Es gibt auch einen weniger sichtbaren Preis, der sich schon lange vor einem Vorfall bemerkbar macht: Die Verantwortlichkeit erodiert schleichend im Tagesgeschäft. Wenn niemand sicher sagen kann, welche Aktionen von Menschen und welche von Agents stammen, werden Ausnahmegenehmigungen, Datenzugriffsprüfungen und Least-Privilege-Prinzipien schwerer korrekt umzusetzen. Prüfer genehmigen breitere Zugriffe, weil eine Einschränkung riskant erscheint, wenn sie nicht wissen, was der Agent tatsächlich benötigt. So entstehen Security Misconfigurations nicht durch eine falsche Entscheidung, sondern durch viele scheinbar vernünftige, die auf einem Identitätsmodell basieren, das Menschen und Software nicht trennt.
Shadow AI ist ein Identitätsproblem, bevor es ein Datenproblem ist
Die meisten Diskussionen über Shadow AI drehen sich darum, wo sensible Daten landen: in einem nicht genehmigten Modell, einem unkontrollierten Plugin oder einer Browser-Erweiterung. Das ist berechtigt, aber die Okta-Daten zeigen auf einen vorgelagerten Punkt. 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 bereits verloren, bevor die Data-Governance-Frage überhaupt gestellt wird.
Deshalb gehört Identität ins Zentrum jeder KI-Governance-Diskussion – nicht als Fußnote unter Data Loss Prevention. Ein Agent mit klar definierter, gut verwalteter Identität ist von vornherein begrenzt: Er kann nur auf das zugreifen, was seine Rolle erlaubt, und jede Aktion ist eindeutig auf ihn und seine Aufgabe zurückzuführen. Ein Agent, der unter einer menschlichen Sitzung oder einem breit angelegten Servicekonto agiert, ist praktisch nicht eingeschränkt – sein Zugriff entspricht dem des Menschen oder Kontos, oft weit mehr als für die Aufgabe nötig. AI Data Governance-Programme, die mit Richtlinien beginnen, aber die Identitätsarchitektur auslassen, lösen nur die halbe Aufgabe. Shadow AI – Agents und KI-Tools außerhalb eines Identity-Programms – ist die direkte Folge: unkontrollierte Agents, die das Unternehmen weder sieht, noch eingrenzen oder im Vorfall 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 einer anderen Perspektive: Agentenbasierte Tools wurden schneller eingeführt als die zero trust Identity- und Access Controls, die zu ihrer Steuerung nötig sind. Programme zum Management von Lieferkettenrisiken, die Identitäts-Governance-Anforderungen auch auf KI-Anbieter von Drittparteien ausweiten – also auf die Agents, die diese Anbieter in Kundenumgebungen einsetzen, nicht nur auf die Tools, die Kunden selbst betreiben – schließen die Supply-Chain-Identitätslücke, die laut Okta-Daten von den meisten Unternehmen noch nicht adressiert wurde.
Wie Kiteworks jedem KI-Agent eine eigene verifizierbare Identität gibt
Kiteworks adressiert dieses Problem aus demselben Ausgangspunkt wie die Okta-Erkenntnisse: Menschen und KI-Agents sind gleichwertige Identitäten, die individuell authentifiziert, autorisiert und protokolliert werden müssen – unter einer Governance-Schicht, nicht unter zwei getrennten. Die Kiteworks Control Plane steuert jede Anfrage nach sensiblen Inhalten, egal ob sie von einer Person, einer Anwendung oder einem Agent kommt, über dieses einheitliche Modell. So wird der Zugriff eines Agents nie über einen Workaround wie geliehene menschliche Zugangsdaten oder ein unverwaltetes Servicekonto geleitet.
Der Secure MCP Server wurde speziell für diesen Anwendungsfall entwickelt. Er authentifiziert über OAuth 2.0, wobei das Zugriffstoken im sicheren Credential Store des Betriebssystems gespeichert wird – 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 besitzt nie ein Credential, das er über einen Prompt, ein Logfile oder eine kompromittierte Sitzung offenlegen könnte. Jede Aktion des Agents – ob Datei lesen, Ordner navigieren oder Inhalte abrufen – wird in Echtzeit gegen RBAC- und ABAC-Richtlinien geprüft und individuell protokolliert, nicht als generischer 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 individuell autorisiert und protokolliert, gibt es keine geteilte Identität, die im Audit-Trail verloren gehen kann. Das CISO Dashboard stellt diese agentenbezogene Audit-Telemetrie in Echtzeit dar und verschafft der Sicherheitsleitung die einheitliche Transparenz über alle KI-vermittelten Zugriffe, die laut Okta-Bericht in den meisten Deployments fehlt.
Kiteworks Compliant AI setzt diese Disziplin auch bei dem, was Agents sehen und nutzen dürfen, nicht nur bei der Authentifizierung, um. Die Durchsetzung von Richtlinien auf Inhaltsebene bestimmt, worauf ein Agent zugreifen oder was er zurückhalten darf, bevor Inhalte überhaupt ins Kontextfenster des Modells gelangen. So verstärken sich Identitäts- und Daten-Grenzen gegenseitig, statt dass eine allein die andere absichert. Datenminimierung auf dieser Ebene – jeder Agent erhält nur die Inhalte, die seine aktuelle Aufgabe erfordert – begrenzt den Schaden, falls ein Agenten-Credential kompromittiert wird, da der Zugriff ohnehin von vornherein beschränkt ist.
Agentenbezogenes Access-Control-Modell mit RBAC und ABAC aufbauen
Die Identitätslücke zu schließen bedeutet, über „Hat dieser Agent ein Credential?“ hinauszugehen zu „Hat dieser spezifische Agent für diese spezifische Aufgabe genau die Berechtigung, die er jetzt braucht?“. Das ist eine rollen- und attributbasierte Frage, keine statische Provisionierung.
Role-based Access Control (RBAC) gibt jedem Agenten eine klar definierte Rolle, die auf seine tatsächliche Funktion zugeschnitten ist. Ein Zusammenfassungsagent braucht beispielsweise nur Lesezugriff auf die zu bearbeitenden Dokumente, ein Workflow-Agent Schreibzugriff auf einen bestimmten Ordner – und sonst nichts. Attribute-based Access Control (ABAC) ergänzt diesen Ansatz um Kontext: Sensitivitätsklassifizierung des Inhalts, Zeitpunkt der Anfrage, Deployment-Umgebung des Agents und die aktuelle Aufgabe fließen in die Autorisierung ein. Zusammen ermöglichen RBAC und ABAC, dass ein Unternehmen einem Agenten exakt den Zugriff gewährt, den seine aktuelle Aufgabe erfordert – und nicht mehr, wie es bei den meisten Servicekonten heute der Fall ist.
Dieses Modell liefert auch das, was der Okta-Bericht als fehlend hervorhebt: 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 ist die Antwort bereits korrekt im Log dokumentiert. Ein dokumentierter Incident-Response-Plan, der auch Fehlfunktionen von KI-Agents abdeckt – insbesondere die Schritte zur Isolierung kompromittierter Agentenidentitäten, Widerruf der Credentials und Eingrenzung der betroffenen Inhalte – macht aus dem Audit-Log ein operatives Reaktionswerkzeug statt nur eines forensischen Assets.
Was Unternehmen jetzt tun sollten, um die KI-Agenten-Identitätslücke zu schließen
Die Größe des Okta-Datensatzes (vier Jahre, über 20.000 Unternehmen, über 100 KI-Produkte) zeigt: Das Problem betrifft nicht nur Early Adopters oder Nachzügler. Es ist nahezu universell – die meisten Security- und Identity-Teams müssen unabhängig vom Reifegrad ihres KI-Governance-Programms handeln.
Einige konkrete Schritte ergeben sich direkt aus den Berichtsergebnissen. Erstens: Inventarisieren Sie alle KI-Agents in Ihrer Umgebung und identifizieren Sie, welches Credential jeder nutzt – Servicekonto, API-Key oder menschlicher Login. Sie können nur beheben, was Sie kennen. Zweitens: Behandeln Sie jeden Agenten, der sich über einen geteilten menschlichen Login authentifiziert, als sofortige Priorität für die Behebung, da dieses Muster laut Bericht den gravierendsten Audit-Trail-Verlust verursacht. Drittens: Prüfen Sie, ob Ihre aktuelle IAM-Infrastruktur tatsächlich separate, klar definierte Identitäten für nicht-menschliche Akteure bereitstellen kann oder ob sie nur für Menschen konzipiert wurde. Viertens: Treffen Sie Agenten-Zugriffsentscheidungen nach zero trust data exchange-Prinzipien: Jede Anfrage verifizieren, minimal nötigen Zugriff gewähren und das Ergebnis protokollieren – statt dem Agenten aufgrund des Kontos, unter dem er läuft, zu vertrauen. Eine formale Risikoanalyse, die den Credential-Typ und die Berechtigungen jedes Agents mit seinen tatsächlichen Aufgaben abgleicht – und aufzeigt, wo geteilte Credentials oder überprovisionierte Servicekonten unakzeptable Risiken schaffen – ist die Grundlage für einen priorisierten Maßnahmenplan.
Für all das muss kein Vorfall abgewartet werden. Die Okta-Daten beschreiben eine strukturelle Lücke in der Autorisierung von KI-Agents heute – kein hypothetisches Risiko. Sie jetzt zu schließen, während die Einführung agentenbasierter KI weiter beschleunigt, ist deutlich günstiger, als nachträglich einen Audit-Trail rekonstruieren zu müssen, den es nie gab.
Erfahren Sie mehr darüber, wie Sie KI-Agents eine eigene, kontrollierte Identität geben statt geliehener menschlicher Zugangsdaten – vereinbaren Sie jetzt eine individuelle Demo.
Häufig gestellte Fragen
Der Okta Enterprise AI Index ist ein Bericht, der auf anonymisierten Anmeldedaten von über 20.000 Unternehmen von Juni 2022 bis Juni 2026 basiert und mehr als 100 verschiedene KI-Produkte, konsolidiert in 74 Anbietersuiten, abdeckt. Er verfolgt, wie Unternehmen KI-Tools einführen und insbesondere, wie diese Tools innerhalb von Unternehmensumgebungen authentifiziert und autorisiert werden. Der Bericht zeigt, dass KI-Agents nach wie vor meist über Servicekonten, statische API-Keys oder geteilte menschliche Logins autorisiert werden, statt über speziell auf den Agenten zugeschnittene Identitäten. Unternehmen, die ihre eigene Exponierung gegenüber diesem Muster bewerten möchten, sollten prüfen, wie ihre IAM-Infrastruktur derzeit nicht-menschliche Akteure provisioniert. Unternehmen mit regulatorischen Compliance-Anforderungen – HIPAA, DSGVO, CMMC – sollten die im Okta-Bericht dokumentierte Authentifizierungslücke als Compliance-Feststellung behandeln, da diese Frameworks nachweisbare Access Controls und Audit-Records verlangen, unabhängig davon, ob der Zugriff durch einen Menschen oder einen Agenten erfolgt.
Ein Servicekonto wird meist einmalig mit weitreichenden Berechtigungen ausgestattet, damit der Agent alle potenziellen Aufgaben abdecken kann, und wird danach selten überprüft. Das führt dazu, dass der Agent oft viel mehr Zugriff hat, als seine aktuelle Aufgabe erfordert, und jede Aktion dem Konto und nicht einer konkreten, nachvollziehbaren Aufgabe zugeordnet wird. Das widerspricht dem Least-Privilege-Prinzip und schwächt die Access Controls, die Compliance-Frameworks von Unternehmen verlangen. Agentenbezogene Identitäten lassen sich dagegen exakt auf die jeweilige Aufgabe begrenzen. Datenminimierung bei der Bereitstellung von Servicekonten – jeder Agent erhält nur Zugriff auf die Datenquellen, die seine Aufgabe erfordert – macht aus dem Policy-Ansatz gelebte Praxis.
Authentifiziert sich ein KI-Agent mit den Zugangsdaten einer Person, werden alle Aktionen unter deren Identität protokolliert, auch wenn die Person diese nie ausgeführt hat. So ist es praktisch unmöglich, menschliche von Agentenaktivitäten bei einer Sicherheitsuntersuchung, Compliance-Prüfung oder Incident Response zu unterscheiden. 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 widerspiegelt, wer oder was tatsächlich gehandelt hat. Agentenbezogene Credentials verhindern dies, indem jeder Log-Eintrag den tatsächlichen Akteur benennt. Unternehmen sollten zudem sicherstellen, dass ihre SIEM-Alert-Konfigurationen auffällige Muster in agentenbezogenen Logs – etwa ungewöhnliche Zugriffszeiten, Datenvolumen oder Ressourcenanfragen – als hochpriorisierte Warnsignale behandeln.
Der Secure MCP Server ist die von Kiteworks gesteuerte Verbindung für KI-Agents, die das Model Context Protocol zum Zugriff auf Unternehmensinhalte nutzen. Statt einem Agenten ein statisches Credential zuzuweisen, das er halten oder offenlegen könnte, erfolgt die Authentifizierung über OAuth 2.0 mit Speicherung des Tokens 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 Agents – genau das Problem, das der Okta-Bericht beschreibt, wenn Agents menschliche Logins übernehmen. Die Datenklassifizierung der vom Secure MCP Server verwalteten Inhalte macht die ABAC-Durchsetzung präzise: Zugriffsentscheidungen können zwischen öffentlichen und vertraulichen Inhalten im Moment der Agentenanfrage unterscheiden, statt eine pauschale Berechtigung auf den gesamten Zugriffsumfang des Agents anzuwenden.
Nicht zwingend. Der dringendere Schritt ist, KI-Agents als eigene Klasse kontrollierter Identitäten bereitzustellen – neben menschlichen Anwendern und unter denselben Richtlinien – statt sie als Workaround durch menschliche Sitzungen oder generische Servicekonten zu leiten. Kiteworks realisiert dies über die Kiteworks Control Plane, die Zugriff, Nutzung und Austausch sensibler Inhalte für Menschen und Agents unter einer Policy steuert, kombiniert mit RBAC– und ABAC-Kontrollen, die auf die tatsächlichen Aufgaben jedes Agents zugeschnitten sind. Eine Risikoanalyse, die abbildet, welche Agents aktuell über geteilte Credentials agieren – und die Behebung nach Sensitivität der zugänglichen Inhalte priorisiert – gibt Identity- und Security-Teams einen klaren, handhabbaren Startpunkt für die Agentenidentitäts-Remediation.
Weitere Ressourcen
- Blogbeitrag
Zero‑Trust-Strategien für bezahlbaren KI-Datenschutz - Blogbeitrag
Wie 77 % der Unternehmen bei KI-Datensicherheit scheitern - eBook
AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen - Blogbeitrag
Es gibt kein „–dangerously-skip-permissions“ für Ihre Daten - Blogbeitrag
Regulierungsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen den Nachweis, dass sie funktioniert.