Thought Leadership
KI-Agenten greifen auf SAP, Salesforce und ServiceNow zu, oft mit weitreichenden Rechten und ohne Aufsicht. Wer sie steuern will, muss bei der Sichtbarkeit anfangen.
Das Problem beginnt mit der Frage: Wie viele Agenten haben Sie?
Ein Unternehmen war überzeugt, keine KI-Agenten im Netz zu haben. Der erste automatisierte Scan fand 5.000. Zwei Wochen später waren es 15.000. Exponentielles Wachstum, und kein Mensch im Unternehmen wusste davon.
Das ist kein Einzelfall. Eine Saviynt-Studie unter 100 deutschen CISOs zeigt: 93 Prozent bestätigen, dass KI-Identitäten auf Kernsysteme zugreifen. Nur 25 Prozent steuern diese Zugriffe mit klaren Richtlinien. 76 Prozent haben unsanktionierte KI-Tools entdeckt, sogenannte Shadow AI.
Der regulatorische Druck steigt parallel. NIS2 verlangt die nachvollziehbare Steuerung aller Systemidentitäten, ohne zwischen menschlichen und maschinellen zu unterscheiden. Seit dem 2. August fordert der EU AI Act Lifecycle-Sicherheit für Hochrisiko-KI-Systeme. Und im Juli haben OpenAI und Anthropic unabhängig voneinander bestätigt, dass ihre KI-Modelle autonom aus Testumgebungen ausbrechen und reale Systeme kompromittieren konnten.
Die Frage ist nicht mehr, ob Unternehmen KI-Agenten steuern müssen. Die Frage ist: Wie? Die folgenden drei Schritte lassen sich unabhängig von der eingesetzten Plattform umsetzen.
Schritt 1: Sichtbarkeit schaffen
Man kann nicht steuern, was man nicht sieht. Der erste Schritt ist ein vollständiges Inventar aller KI-Agenten und nicht-menschlichen Identitäten im Unternehmen.
Das klingt einfacher, als es ist. KI-Agenten tauchen in klassischen Verzeichnisdiensten wie Active Directory oder LDAP nicht auf. Sie werden von Fachabteilungen über Low-Code-Plattformen erstellt, über OAuth-Tokens in Cloud-Umgebungen authentifiziert und über API-Keys provisioniert. Viele Unternehmen haben mindestens drei verschiedene Quellen, aus denen Agenten entstehen: die IT-Abteilung (offiziell), Fachabteilungen (oft ohne Wissen der IT) und externe Dienstleister (mit eigenen Credentials).
Für die Bestandsaufnahme gibt es zwei Ansätze. Der erste ist die direkte Anbindung an die Plattformen, auf denen Agenten laufen: Microsoft Copilot Studio, AWS Bedrock, Google Vertex, Salesforce Agentforce, ServiceNow AI. Diese Plattformen haben APIs, über die registrierte Agenten abgefragt werden können. Das erfasst den offiziellen Bestand.
Der zweite Ansatz erfasst, was der erste nicht sieht: Shadow AI. Dafür braucht es eine Analyse der API-Logdateien aus Kernsystemen. Welche Zugriffe kommen von nicht registrierten Identitäten? Welche Muster deuten auf automatisierte Abfragen hin? Zugriffe außerhalb der Bürozeiten, ungewöhnlich hohe Frequenzen, Verbindungen von unbekannten IP-Adressen. Endpoint-Security-Systeme können zusätzlich installierte Software oder Workloads erkennen, die auf lokale KI-Agenten hindeuten.
Das Ergebnis sollte ein zentrales Register sein, das für jeden Agenten drei Fragen beantwortet: Wer hat ihn erstellt? Worauf greift er zu? Wer ist für ihn verantwortlich?
Bei Lösungen wie Saviynt Zuma übernimmt das Modul Zuma Insights diese Aufgabe: kontinuierliche Discovery aller Agenten und nicht-menschlichen Identitäten, Visualisierung der Zugriffsbeziehungen über Access Maps, und eine Timeline-Ansicht aller Lifecycle-Ereignisse.
Schritt 2: Lifecycle-Management aufbauen
Sichtbarkeit allein reicht nicht. Jeder Agent braucht einen definierten Lebenszyklus, vergleichbar mit dem Joiner-Mover-Leaver-Prozess für Mitarbeiter.
In der Praxis fehlt das fast überall. Ein Agent wird ausgerollt, bekommt sein Credentials und läuft autonom. Wenn das Projekt endet, wenn der Use Case sich ändert, wenn der externe Dienstleister den Vertrag beendet, passiert meistens nichts. Der Agent läuft weiter. Mit denselben Rechten. Ohne Verantwortlichen. Das ist der Grund, warum Unternehmen plötzlich Tausende Agenten im Netz haben, von denen niemand etwas weiß.
Ein funktionierender Lifecycle-Prozess für KI-Agenten braucht vier Elemente:
Registrierung. Jeder Agent muss bei der Inbetriebnahme registriert werden. Das kann über ein Formular geschehen (vergleichbar mit dem Onboarding eines externen Mitarbeiters) oder über einen API-Aufruf, der automatisch eine Agenten-Identität im IGA-System anlegt. Entscheidend ist, dass es einen einfachen, schnellen Weg gibt – denn wenn der Prozess zu aufwändig ist, umgehen die Fachabteilungen ihn.
Ownership. Jeder Agent braucht einen namentlich benannten menschlichen Verantwortlichen. Nicht die IT-Abteilung pauschal, sondern eine Person, die für die Berechtigungen, die Aktivitäten und die Stilllegung zuständig ist. In der Praxis ist das oft die Person, die den Agenten erstellt hat, oder der Projektverantwortliche. Außerdem macht es oft Sinn, sowohl einen technischen Eigentümer (der “Entwickler”), als auch einen fachlichen Eigentümer (der “Auftraggeber”) zu definieren.
Rezertifizierung. Die Berechtigung eines Agenten muss regelmäßig geprüft werden. NIS2 verlangt halbjährliche Rezertifizierung für kritische Systeme. Bei KI-Agenten, die Rechte dynamisch eskalieren und an andere Agenten delegieren können, reicht das allein nicht aus. Ergänzend braucht es eine laufende Überwachung.
Offboarding. Wenn ein Agent nicht mehr gebraucht wird, müssen seine Credentials deaktiviert und seine Zugriffsrechte entzogen werden. Automatisch, nicht auf Zuruf. Lösungen wie Zuma Governance automatisieren genau diesen Prozess: Registrierung, Ownership-Zuweisung, Rezertifizierung und schnelles Offboarding verwaister Agenten.
Schritt 3: Echtzeit-Kontrolle implementieren
Die ersten beiden Schritte schaffen Ordnung. Der dritte Schritt schafft Sicherheit in Echtzeit.
Klassische Zugriffssteuerung prüft, ob ein Agent berechtigt ist. Sie prüft nicht, ob das, was er tut, zum Auftrag passt. Ein Agent, der autorisiert ist, CRM-Daten zu lesen, könnte Kundendaten exportieren, Preiskonditionen ändern oder ausgehende Kommunikation auslösen. Technisch hat er die Berechtigung. Die Absicht stimmt jedoch nicht.
Die Vorfälle bei OpenAI und Anthropic haben gezeigt, wohin das führt: Beide Modelle hatten Berechtigungen. Beide taten etwas, das nicht zum Auftrag passte. Kein System hat die Abweichung erkannt, niemand hat beizeiten interveniert.
Was gebraucht wird, ist eine Kontrollschicht, die jede Aktion eines Agenten in Echtzeit bewertet. Nicht nur anhand der Berechtigung, sondern anhand der Absicht: Passt diese konkrete Aktion zum definierten Auftrag des Agenten? Handelt der Agent eigenständig, im Auftrag eines Menschen oder delegiert von einem anderen Agenten?
Fällt eine Aktion aus dem Rahmen, wird sie entweder einem Menschen zur Abnahme vorgelegt, oder direkt blockiert und ein Audit-Ereignis erzeugt. Die Entscheidung passiert zur Laufzeit, nicht beim nächsten Quartalsreview. Saviynts Agent Access Gateway (Zuma Access) implementiert diese Logik unter dem Begriff „Intent-Aware Authorization“ und evaluiert dabei Identität, Kontext, Risiko und Policy bei jeder einzelnen Agenten-Aktion.
Ein wichtiger Aspekt dabei ist die Delegation zwischen Agenten. In Agentic-AI-Architekturen können Agenten Aufgaben an andere Agenten delegieren und dabei Berechtigungen weiterreichen. Ein Nutzer könnte sich über eine Kette von Agenten Rechte verschaffen, die er selbst nicht hat. Die Echtzeit-Kontrolle muss deshalb erkennen, wer den ursprünglichen Auftrag erteilt hat, und ob die gesamte Kette autorisiert ist.
Was CISOs jetzt nicht tun sollten
Im Gespräch mit Partnern und Beratungshäusern zeigt sich ein wiederkehrendes Muster: Viele CISOs wissen, dass AI Governance wichtig ist. Aber sie sind mit Legacy-Migrationen und SAP-Transformationen so ausgelastet, dass sie das Thema Innovation durch KI nicht blockieren wollen. Sie erlauben der Organisation, KI-Agenten ohne Governance einzusetzen, um nicht zum Engpass zu werden.
Das ist nachvollziehbar. Aber es ist gefährlich. Denn jeder Tag ohne Sichtbarkeit ist ein Tag, an dem das Inventar wächst, Agenten Rechte akkumulieren und Shadow AI sich ausbreitet. Der Aufwand, das nachträglich aufzuräumen, steigt exponentiell.
Der bessere Ansatz: Mit Schritt 1 anfangen. Ein erster Scan der Unternehmensumgebung schafft Klarheit, oft innerhalb von Tagen. Das Ergebnis zeigt dem Vorstand, dem CISO und den Fachabteilungen, wie schlimm es bereits schon ist. Und es liefert die Grundlage für alles Weitere.
