KI-Agenten greifen heute bereits eigenständig auf SAP-, Salesforce- und ServiceNow-Systeme zu, oft mit weitreichenden Berechtigungen und ohne klare Governance. Für Security-Teams entsteht dadurch eine neue Realität: Jede dieser Instanzen ist eine Identität mit eigenen Berechtigungen, Zugriffen und Risiken. Anders als ein Mitarbeiter arbeitet sie rund um die Uhr, trifft Entscheidungen in Millisekunden und steht in keinem HR-System. Wer diese Agenten nicht wie Mitarbeiter führt, verliert die Kontrolle über die eigenen Kernsysteme.
Ein unterschätztes Risiko
Das Problem ist nicht theoretisch. Eine Saviynt-Studie unter deutschen CISOs und CIOs zeigt: 93 Prozent bestätigen, dass KI-Identitäten bereits auf Kernsysteme zugreifen, aber nur 25 Prozent steuern diese Zugriffe mit klaren Richtlinien. Mehr als die Hälfte hat keinen vollständigen Überblick über die KI-Identitäten in ihrer Umgebung, und 76 Prozent haben bereits unsanktionierte KI-Tools entdeckt, oft mit eigenen Zugangsdaten und erhöhten Berechtigungen.
Drei Szenarien zeigen, wo das Risiko konkret entsteht. Ein Unternehmen testet einen KI-Agenten für die Automatisierung von Compliance-Prüfungen, nach der Pilotphase wird das Projekt eingestellt, der Agent läuft aber weiter, weil ihn niemand im Identity-System erfasst hat, mit fortbestehendem Zugriff auf Finanzdaten und Audit-Systeme. Ein externer Anbieter liefert einen KI-Agenten für vorausschauende Wartung, der auf Produktionsdaten zugreift, der Dienstleister wird kompromittiert, und die Zugangsdaten des Agenten landen beim Angreifer, der sich anschließend unauffällig durch die Systeme des Unternehmens bewegt. Und eine Fachabteilung erstellt über eine Low-Code-Plattform eigene KI-Agenten mit Zugriff auf Kundendaten und ERP-Systeme, ohne dass die IT-Sicherheit davon erfährt. In allen drei Fällen hilft Perimetersicherheit nicht, denn der Zugriff erfolgt über eine bereits legitimierte Identität, und klassische Identity-Management-Systeme greifen nicht, weil sie für menschliche Nutzer gebaut wurden.
Warum Agenten anders ticken als Mitarbeiter
Security-Verantwortliche kennen den Joiner-Mover-Leaver-Prozess für Mitarbeiter, für KI-Agenten gibt es in den meisten Unternehmen nichts Vergleichbares. Ein Mitarbeiter wird eingestellt und verlässt irgendwann das Unternehmen, ein KI-Agent läuft dagegen potenziell unbegrenzt, wenn ihn niemand aktiv stilllegt. Stößt er in einem Workflow auf ein Hindernis, kann er versuchen, sich zusätzliche Berechtigungen zu beschaffen, in Maschinengeschwindigkeit statt im Tempo eines Helpdesk-Tickets. In Agentic-AI-Architekturen delegieren Agenten zudem Aufgaben an andere Agenten und reichen dabei Berechtigungen weiter, die der ursprüngliche Agent gar nicht hatte. Erschwerend kommt hinzu, dass KI-Agenten nicht nur in der IT-Abteilung entstehen, Fachabteilungen erstellen sie über Low-Code-Plattformen, Entwickler deployen sie in Cloud-Umgebungen, externe Dienstleister bringen eigene mit. Die Angriffsfläche wächst damit an Stellen, die Security-Teams oft gar nicht sehen.
Fünf Maßnahmen für Security-Verantwortliche
Die folgenden Schritte lassen sich unabhängig von der eingesetzten Plattform umsetzen und orientieren sich am Least-Privilege-Prinzip sowie an den Anforderungen von NIS2, DORA und dem KRITIS-Dachgesetz. Erstens: KI-Agenten inventarisieren, also eine vollständige Bestandsaufnahme aller Agenten durchführen, autorisierte genauso wie Shadow AI, indem API-Zugriffe auf Kernsysteme analysiert, Cloud-Umgebungen gescannt und Fachabteilungen gezielt befragt werden. Ohne Inventar ist keine Steuerung möglich.
Zweitens: Jedem Agenten einen menschlichen Verantwortlichen zuordnen, eine namentlich benannte Person, die für Berechtigungen, Aktivitäten und Stilllegung zuständig ist, vergleichbar mit der Eigentümerschaft für Service Accounts. Drittens: Lifecycle-Prozesse einführen, also Registrierung, Genehmigung, regelmäßige Rezertifizierung und Stilllegung, mit einem Ablaufdatum für jeden Agenten. Endet die Pilotphase, wird der Agent deaktiviert, endet der Vertrag mit dem externen Dienstleister, werden dessen Zugangsdaten automatisch entzogen.
Viertens: Least Privilege konsequent anwenden, KI-Agenten sollten nur die Berechtigungen erhalten, die sie für ihre Aufgabe brauchen, wobei Just-in-Time-Zugriff für Agenten sogar wichtiger ist als für menschliche Nutzer, da sie rund um die Uhr aktiv sind. Standing Privileges sind bei KI-Agenten ein besonders hohes Risiko. Fünftens: Zugriffe in Echtzeit überwachen, denn manuelle Rezertifizierungen im Quartalsrhythmus reichen bei Agenten nicht aus, die in Millisekunden Entscheidungen treffen. Nötig ist eine Echtzeit-Überwachung mit automatisierten Alerts bei Abweichungen vom definierten Verhalten, sowohl für Zugriffe auf Unternehmensanwendungen als auch für die Kommunikation zwischen Agenten.
Regulatorischer Druck wächst
NIS2 fordert von Unternehmen eine nachvollziehbare Steuerung privilegierter Zugriffe, DORA verlangt von Finanzunternehmen eine strenge Kontrolle von IKT-Risiken und Drittanbieter-Zugriffen, das KRITIS-Dachgesetz verpflichtet Betreiber kritischer Infrastrukturen zu höheren Sicherheitsstandards, und der EU AI Act fordert Transparenz und Nachvollziehbarkeit für KI-Systeme. Keine dieser Regulierungen unterscheidet zwischen menschlichen und maschinellen Identitäten, die Pflicht zur Kontrolle gilt für alle. Laut dem Schwarz Digits Cyber Security Report 2026 gehen dennoch fast die Hälfte der deutschen Unternehmen fälschlicherweise davon aus, von NIS2 nicht betroffen zu sein, und 54 Prozent stufen das Cyberrisiko durch KI als nicht vorhanden ein. Die Lücke zwischen regulatorischer Anforderung und betrieblicher Realität ist damit erheblich.
Die entscheidende Frage lautet nicht, welche Chancen künstliche Intelligenz bietet, sondern wer oder was mit welchen Rechten auf kritische Systeme zugreift. KI-Agenten sind keine Werkzeuge mehr, sie agieren zunehmend wie eigenständige digitale Akteure und müssen deshalb auch wie Identitäten gesteuert werden. Wer diese Transparenz nicht herstellen kann, verliert die Kontrolle über seine eigene Infrastruktur.