Der KI-Agent, der für Sie arbeitet, hat wahrscheinlich mehr Zugriff als Sie

Die KI übernimmt nicht die Arbeit des Vertreters. Sie ist ein Werkzeug, das der Vertreter benutzt. Aber das Werkzeug erhält letztlich mehr Zugriff auf das System als die Person, für die es arbeitet. Diese Lücke, ein Mensch mit eingeschränktem Zugriff, der eine non-human identity mit weiterreichendem Zugriff verwendet, wird zur normalen Form der KI-Einführung in Unternehmen, und fast niemand überprüft sie so, wie er die Berechtigungen einer Person überprüfen würde.

Netwrixs Bericht zur Daten- und Identitätssicherheit 2026, basierend auf einer Umfrage unter 2.317 Sicherheits- und IT-Führungskräften, liefert Zahlen zu diesem Muster. 72 % der Organisationen geben an, dass das Risiko der Offenlegung identitätsbezogener Daten gestiegen ist. 58 % sagen, dass jetzt mehr Identitäten Zugriff auf Unternehmensdaten haben als zuvor. 41 % setzen bereits agentische KI in der Produktion ein, wobei diese Agenten im Auftrag von Menschen gegen sensible Daten agieren. Nicht-menschliche Identitäten sind kein zukünftiges Problem. Sie sind bereits der Mehrheitseigentümer in vielen Umgebungen.

Der Teil, der in einer Zugriffsüberprüfung nicht angezeigt wird

Die meisten Identity Governance-Programme basieren auf einem Joiner-Mover-Leaver-Rhythmus. Jemand beginnt, seine Zugriffsrechte wachsen oder ändern sich, und schließlich verlässt er das Unternehmen und die Zugriffsrechte werden widerrufen.Servicekonten, API-Schlüssel, Zertifikate und Automatisierungstoken folgen diesem Muster nicht. Sie werden während einer Bereitstellung erstellt, von der Vorlage geerbt, die am schnellsten einsatzbereit war, und dann unbeachtet gelassen, weil niemand die Nachverfolgung übernimmt.

Der Bericht bestätigt dies. Nur 19 % der Organisationen geben an, nicht-menschliche Identitäten vollständig zu verwalten. 76 % können den dauerhaften Zugriff nicht sofort widerrufen, wenn er nicht mehr benötigt wird. 64 % haben zumindest teilweise überprovisionierten Zugriff auf kritische Daten. Setzt man das zusammen, erhält man eine Anzahl von Zugangsdaten, die größer ist als die menschliche Belegschaft, schwerer zu verfolgen und selten überprüft wird.

Es gibt eine spezielle Version dieses Problems, die es wert ist, hervorgehoben zu werden: Die zertifikatbasierte Authentifizierung wird zum primären Vertrauensmechanismus für KI-Agenten und Automatisierung, aber die meisten Organisationen haben wenig Einblick in die zugrunde liegende Zertifikatsinfrastruktur. Fehlkonfigurierte Vorlagen, zu großzügige Einschreiberechte und vererbte Vertrauensbeziehungen in Active Directory Certificate Services können es einem Angreifer ermöglichen, eine privilegierte Identität zu imitieren, ohne jemals ein Passwort zu berühren.

Warum dies ein Problem des Änderungsmanagements ist und nicht nur der Identität

Hier ist der Teil, der übersehen wird. Die Berechtigungen eines Dienstkontos, die Vertrauenskette eines Zertifikats, der Umfang eines API-Schlüssels – nichts davon existiert nur in einer Identity-Plattform. Es befindet sich in Konfigurationsdateien, Registrierungsschlüsseln, Zertifikatsspeichern und geplanten Aufgaben auf den tatsächlichen Systemen, auf denen das Konto arbeitet. Wenn sich eine regulatorische Verpflichtung ändert, sei es eine neue PCI DSS-Anforderung, eine aktualisierte NIST-Kontrolle oder eine NERC CIP-Revision, sollen die Zugriffsüberprüfung und der Widerrufsschritt zusammen erfolgen. In der Praxis erhält die Identitätsseite Aufmerksamkeit, während die Konfigurationsseite still im Hintergrund vor sich hin driftet.

Genau dort verbirgt sich die unbefugte Änderung. Ein Registrierungsschlüssel, der einem Dienstkonto weitergehende Einschreiberechte gewährt, als es benötigt. Eine Konfigurationsdatei, die noch auf eine außer Betrieb genommene Integration verweist. Eine vor sechs Monaten bearbeitete Zertifikatvorlage, die niemand zur Überprüfung markiert hat. Keines davon erscheint in einer Zugriffsbestätigungs-Tabelle. Sie erscheinen, wenn jemand tatsächlich betrachtet, was sich am System geändert hat.

Die Systeme beobachten statt nur die Liste

Hier kommt die Dateiintegritätsüberwachung und das Sicherheitskonfigurationsmanagement ins Spiel. Netwrix Change Tracker verwaltet keine Identitäten, überwacht jedoch die Systeme, auf denen diese Identitäten und ihre Anmeldeinformationen existieren. Es legt Basiswerte für Konfigurationsdateien, Registrierungsschlüssel und Systemeinstellungen fest und meldet jede Abweichung von dieser Basis in Echtzeit. Wenn eine Regel für geplante Änderungen existiert, sei es im Zusammenhang mit einem Patch-Fenster oder einer genehmigten ServiceNow-Anfrage, werden entsprechende Änderungen automatisch herausgefiltert. Übrig bleibt die ungeplante Aktivität: die Registrierungsänderung, die niemand genehmigt hat, die Konfigurationsänderung ohne entsprechende Änderungsanforderung, die Abweichung, die sonst unbemerkt bliebe, bis eine Prüfung oder ein Vorfall jemanden zum Nachforschen zwingt.

Dieses Closed-Loop-Modell, das beobachtete Änderungen mit genehmigten über ITSM-Integrationen wie ServiceNow, BMC Remedy und Cherwell abgleicht, bietet Sicherheits- und Compliance-Teams etwas, das eine reine Zugriffsüberprüfung nicht kann: eine systemweite Aufzeichnung dessen, was tatsächlich passiert ist, wann es passiert ist und ob es erwartet wurde. In Kombination mit über 250 vorgefertigten Compliance-Berichten, die auf Frameworks wie PCI DSS, NIST, HIPAA und DISA STIG abgestimmt sind, verwandelt diese Aufzeichnung das "Wir glauben, unsere Kontrollen funktionieren" in Beweise, die ein Prüfer tatsächlich überprüfen kann.

Der Vertreter bekommt immer noch die Schuld

Wenn diese Salesforce-Integration kompromittiert wird oder der Assistent stillschweigend Daten außerhalb seines vorgesehenen Umfangs abruft, wird im Vorfallbericht nicht der KI-Anbieter genannt. Es wird das Konto genannt, das sich authentifiziert hat, und die Person, deren Name damit verbunden ist. Identity Governance kann die Richtlinie festlegen, was dieses Konto berühren darf. Sie kann Ihnen nicht eigenständig sagen, was letzten Dienstag tatsächlich am System geändert wurde. Das ist eine andere Frage, und jemand muss weiterhin auf die Antwort achten.