Shadow Agents: Das neue Blindspot der CISOs
Ein CISO, mit dem ich vor einigen Wochen gesprochen habe, hat mir etwas gesagt, das mir seitdem nicht aus dem Kopf geht. Er arbeitet für ein mittelgroßes Finanzinstitut in der DACH-Region. ISO 27001 zertifiziert, NIS2 in Umsetzung, Security Operations Center mit 24/7-Abdeckung. Kein Neuling.
"Wir haben letzte Woche gemerkt, dass drei Teams intern Agents laufen lassen. Über externe SaaS-Anbieter. Keiner hat uns informiert."
Das ist kein Einzelfall. Laut dem Pentera 2026 Report wissen 67 Prozent der Security-Verantwortlichen nicht, welche KI-Modelle und Agents in ihrer Organisation laufen. Gartner prognostiziert gleichzeitig, dass bis Ende 2026 bereits 40 Prozent aller Enterprise-Applikationen KI-Agents eingebaut haben werden. Deloitte stellt fest, dass 79 Prozent der Organisationen Agentic AI bereits deployen oder testen. Nur 21 Prozent haben dafür ein reifes Governance-Modell. Und 88 Prozent hatten bereits AI-Agent-Security-Incidents laut Gravitee.
Die Kurven laufen in die falsche Richtung.
Von Shadow IT zu Shadow AI zu Shadow Agents
Das ist kein neues Phänomen. Es ist eine Progression, die ich über Jahre beobachte.
Shadow IT war das Problem der 2010er. Fachabteilungen buchten SaaS-Dienste, ohne IT zu fragen. Dropbox, Salesforce, Slack: alle zuerst ohne IT-Freigabe in Unternehmen angekommen. Es hat rund zehn Jahre gedauert, bis Identity Governance und SaaS Security Posture Management (SSPM) als Standard galten.
Shadow AI folgte. Teams fingen an, GPT-APIs direkt aufzurufen, Daten in externe Modelle zu schicken, Workflows um öffentliche LLMs herum zu bauen. Die Datenabfluss-Frage stand schnell auf der Agenda. Viele Unternehmen haben dafür inzwischen Policies. Noch nicht alle.
Shadow Agents sind die nächste Stufe. Und hier liegt der qualitative Unterschied: Agents holen nicht nur Daten. Sie handeln.
Ein Agent schreibt in S3. Er öffnet Tickets. Er ruft APIs auf. Er triggert Workflows. Er kann, wenn er die entsprechenden Credentials hat, Ressourcen anlegen, löschen, neu konfigurieren. Mit Identitäten, die oft nicht unter das klassische IAM-Management fallen, weil sie als Service-Account, API-Key oder OAuth-Token in einem SaaS-Produkt stecken, das die Fachabteilung selbst eingerichtet hat.
Das ist kein KI-Problem. Es ist das alte Identity-Problem mit einer neuen Dimension: Principals handeln jetzt autonom. Und die Zeitscheibe, die wir bei Shadow IT hatten, um Governance nachzuziehen, existiert für Shadow Agents nicht mehr.
Warum die klassische Antwort nicht reicht
Wenn ich dieses Thema in Kundengesprächen aufbringe, höre ich oft: "Wir haben eine AI-Policy." Gut. Aber eine Policy, die Agents als Sonderfall von "KI-Nutzung" behandelt, trifft den Kern nicht.
Das Problem ist identity-seitig, nicht AI-seitig.
Ein Agent ist ein Principal. Er hat Credentials. Er hat Berechtigungen. Er führt Aktionen aus, die in Audit-Logs auftauchen. Wenn dieser Principal nicht in eurem Identity-Inventar steht, wenn niemand ihn besitzt, wenn seine Berechtigungen nie reviewed wurden, dann habt ihr das klassische Problem eines unmanaged Service-Accounts. Der Unterschied zu früher: dieser Service-Account trifft Entscheidungen. Und er tut es schneller als jeder Mensch.
Ich habe das aus nächster Nähe erlebt. Im Rahmen meines SaaS-Projekts (52 Tage, ca. 292.000 Netto-Codezeilen, gebaut mit AWS Kiro) hatte ich einen Punkt, an dem mehrere Agents parallel liefen, jeder mit eigenen IAM-Rollen und Berechtigungen. Was mir klar wurde: Ohne explizites Identitäts-Design werden die Agents untereinander schnell zur Blackbox. Wer hat was wo geschrieben? Welcher Agent hat welche Ressource angesprochen? Ohne sauberes Tagging und ohne explizite Principal-Identitäten gibt es darauf keine verlässliche Antwort.
In einem Produktivsystem, in einem regulierten Umfeld, in einer C5-Audit-Situation, ist das ein Showstopper.
Drei Schritte, die CISOs jetzt gehen können
Das Governance-Problem bei Agents ist lösbar. Aber es braucht einen anderen Ansatz als bei Software-Tools.
1. Agent-Inventar nach Identität, nicht nach Tool
Der erste Schritt ist ein Inventar aller laufenden Agents. Nicht katalogisiert nach Anbieter oder Plattform, sondern nach Principal: Welcher Agent hat welche Credentials? Welche Permissions sind damit verbunden? In welchem Kontext läuft er?
Das klingt nach einer unkomplizierten Übung. In der Praxis ist es oft überraschend schwer, weil Agents auf unterschiedlichen Wegen in die Umgebung gekommen sind: einige über die zentrale IT, einige über Fachabteilungen, einige als eingebettete Features in SaaS-Produkten, die jemand vor sechs Monaten aktiviert hat.
Ohne Inventar gibt es keinen Scope. Ohne Scope gibt es kein Governance-Programm, das funktioniert.
2. Jeder Agent braucht einen menschlichen Eigentümer
Das ist die Frage, die ich in jedem Workshop stelle und die selten eine befriedigende Antwort hat: Wer ist verantwortlich, wenn ein Agent etwas falsch macht?
Nicht die Fachebene "das Produkt ist von Team X", sondern konkret: Wer überprüft die Permissions dieses Agents quartalsweise? Wer bekommt den PagerDuty-Alert, wenn er unerwartetes Verhalten zeigt? Wer wird angerufen, wenn er Teil eines Security-Incidents ist?
Diese Frage muss vor dem Rollout beantwortet sein. Nicht danach. Wer das Ownership nicht definiert, bevor ein Agent live geht, schiebt das Problem auf den schlechtestmöglichen Zeitpunkt: den ersten Incident.
Bei AWS-nativen Agents lässt sich das mit tagging-basierten Ownership-Metadaten und IAM-Permission-Boundaries strukturieren. Für externe Agents über SaaS braucht es ein entsprechendes Feld im CMDB oder GRC-Tool, das die gleiche Frage stellt.
3. CloudTrail als Audit-Grundlage für Agent-Aktionen
Jede Aktion eines Agents ist ein API-Call. Und in AWS-Umgebungen wird jeder API-Call in CloudTrail aufgezeichnet.
Das ist die gute Nachricht: Die technische Grundlage für Visibility ist vorhanden. Die schlechte Nachricht: sie muss aktiv genutzt werden. CloudTrail aufzuzeichnen ist nicht das Gleiche wie CloudTrail auszuwerten.
In Kombination mit AWS Security Lake lassen sich Agent-Aktionen über Zeit analysieren. Wer hat wann welche Ressource angesprochen? Welche Zugriffsmuster sind normal? Was ist eine Anomalie? Das ist die Grundlage für eine echte Antwort auf die Frage: "Wissen wir, was unsere Agents tun?"
Und es ist die Grundlage für die Antwort, die in einem C5:2026-Audit zur Frage der KI-Systemüberwachung verlangt wird. Wer heute keine CloudTrail-basierte Auswertung für Agent-Aktionen hat, wird sie spätestens für die nächste Attestierung brauchen.
Das Identity-Problem kommt vor dem AI-Problem
Ich arbeite in TM Forum Catalysts und Kundenprojekten seit Monaten an der Frage, wie Agentic AI in Enterprise-Umgebungen autonom handeln kann, ohne dass Governance und Compliance auf der Strecke bleiben. Meine Beobachtung: Die meisten Herausforderungen, die dabei auftauchen, sind keine AI-spezifischen Probleme. Sie sind Identity-Probleme, die durch die Autonomie von Agents sichtbarer und dringlicher werden.
RBAC, Least Privilege, Ownership, Audit Trail: das sind Konzepte, die jeder CISO kennt. Sie müssen jetzt auf Principals angewendet werden, die nicht aus einer HR-Datenbank kommen, die nicht "onboarding" und "offboarding" kennen wie Menschen, und die im Extremfall mehrere tausend Aktionen pro Tag ausführen.
Das ist kein Grund zur Panik. Es ist ein Grund zur Struktur.
Agent Sprawl ist kein Zukunftsproblem. Er ist bereits da. Der Unterschied zwischen gut geführten und überwältigten Organisationen wird nicht darin liegen, ob sie Agents einsetzen. Er liegt darin, ob sie wissen, welche.
Arbeitet ihr gerade an Agent-Governance-Frameworks oder habt ihr ähnliche Erfahrungen mit Shadow Agents gemacht? Ich freue mich über den Austausch im Kommentar oder direkt auf LinkedIn.