Shadow AI Agents: Das unsichtbare Sicherheitsrisiko, das 88 % aller Unternehmen betrifft

KI-Agenten haben ein Identitätsproblem

Stell dir folgendes Szenario vor: In deinem Unternehmen laufen 47 KI-Agenten. Du weißt von 12. Die IT-Security kennt 8. Die restlichen? Die hat irgendwer aus dem Marketing aufgesetzt, ein Freelancer hat einen für die Datenmigration vergessen, und drei laufen seit Monaten auf einem Dev-Server, weil niemand sie dekommissioniert hat.

Willkommen in der Welt der Shadow AI Agents — dem größten Sicherheitsrisiko, das die meisten Unternehmen gerade komplett ignorieren.

Eine aktuelle Studie zeigt: 88 % aller Unternehmen hatten im letzten Jahr bestätigte oder vermutete Sicherheitsvorfälle durch KI-Agenten. Der Hauptgrund? Nur 22 % behandeln ihre Agenten als eigenständige Identitäten mit dedizierten Zugriffskontrollen. Der Rest operiert mit Shared Service Accounts, vergessenen API-Keys und Zero Visibility.

Als jemand, der täglich mit KI-Agenten arbeitet — für Automatisierung, Code-Review, Deployment — sehe ich das Problem aus erster Hand.

Was sind Shadow AI Agents?

Der Begriff lehnt sich an Shadow IT an — Technologie, die ohne Genehmigung der IT-Abteilung im Unternehmen genutzt wird. Shadow AI Agents sind ein ähnliches, aber deutlich gefährlicheres Phänomen.

Ein Shadow AI Agent ist jeder autonom agierende KI-Agent, der ohne zentrale Registrierung operiert, keine eigene Identität besitzt, keiner Governance-Policy unterliegt und von niemandem aktiv verwaltet wird.

Die Einstiegshürde ist so niedrig wie nie: Ein Entwickler braucht fünf Minuten für einen Agent mit API-Zugang. Ein Marketing-Mitarbeiter nutzt ein No-Code-Tool und hat in zehn Minuten einen Agenten, der eigenständig E-Mails beantwortet. Das Ergebnis: unkontrollierte Proliferation autonomer Systeme ohne Überblick.

Die drei Kerngefahren

1. Unkontrollierte Zugriffsrechte

Die meisten Shadow Agents laufen mit deutlich mehr Rechten, als sie brauchen. Das klassische „ich geb ihm erstmal vollen Zugriff und schränke später ein” — nur dass „später” nie kommt.

Die Zahlen sind eindeutig: Unternehmen ohne Least-Privilege-Ansatz melden eine Vorfallquote von 76 %. Mit konsequentem Least-Privilege sind es 17 %. Faktor 4,5 — allein durch saubere Rechtevergabe.

2. Fehlende Nachvollziehbarkeit

Wenn ein Agent unter einem Shared Service Account operiert, kann keine seiner Aktionen einer konkreten Quelle zugeordnet werden. Datenleak, unberechtigter API-Call, versehentliche Löschung — alles eine schwarze Box. Wer war es? Welcher Agent? Wer ist verantwortlich?

Spätestens bei regulatorischen Anforderungen wird das zum rechtlichen Risiko.

3. Laterale Bewegung und Eskalation

Ein kompromittierter Shadow Agent mit übermäßigen Rechten ist der perfekte Ausgangspunkt für laterale Netzwerkbewegungen. Er hat Zugriff auf APIs, Datenbanken, Cloud-Services — und weil niemand sein Verhalten monitort, fällt nichts auf.

Prompt Injection verschärft das Problem. Wie ich in meinem Artikel über Prompt Injection und Agent Hijacking beschrieben habe, können manipulierte Inputs einen Agenten dazu bringen, seine Aufgabe zu verlassen. Bei einem verwalteten Agenten mit begrenzten Rechten ist der Schaden kontrollierbar. Bei einem Shadow Agent mit Admin-Rechten? Worst Case.

Non-Human Identities: Das vergessene Feld

Hier wird es für uns als Entwickler richtig interessant. Die klassische IAM-Infrastruktur wurde für Menschen gebaut: Login-Credentials, MFA, Session-Management.

Aber Non-Human Identities — Service Accounts, API-Keys, KI-Agenten — übersteigen in vielen Unternehmen längst die Anzahl menschlicher Identitäten. Trotzdem behandeln wir sie wie Bürger zweiter Klasse. KI-Agenten sind aber keine passiven Tools. Sie treffen eigenständig Entscheidungen und interagieren mit Drittsystemen. Sie sind autonome Akteure und brauchen ein entsprechendes Identitätsmanagement.

Wer sich für die technischen Sicherheitsgrundlagen interessiert: In meinem Beitrag über KI-Agenten: Sicherheit, Risiken und Schutzmaßnahmen gehe ich auf die Basis ein — hier konzentrieren wir uns auf die organisatorische Identity-Ebene.

Was die Industrie dagegen tut

Okta for AI Agents

Okta macht am 30. April 2026 „Okta for AI Agents” allgemein verfügbar. Der Ansatz behandelt KI-Agenten als First-Class Identities:

• Shadow Agent Discovery: Automatische Erkennung unsanktionierter Agenten in Cloud- und SaaS-Umgebungen
• Unique Identity Assignment: Jeder Agent bekommt eine eigene Identität mit klarer Zuordnung zu einer verantwortlichen Person
• Just-in-Time Access: Rechte werden granular und zeitlich begrenzt vergeben
• Universal Logout: Ein Kill-Switch, der alle Sessions eines kompromittierten Agenten sofort beendet
• Lifecycle Management: Von der Registrierung über Secret-Rotation bis zur Dekommissionierung

Die Shadow Agent Discovery allein dürfte bei vielen Unternehmen für Überraschungen sorgen.

NIST setzt Standards

Das NIST hat im Februar 2026 ein Concept Paper veröffentlicht, das Standards für Agent-Authentifizierung, Scoped Permissions und Logging definiert. Kommentierungsphase läuft bis 2. April 2026. Sektorspezifische Regulierungen für Healthcare, Finance und Education stehen ab April an.

Wer jetzt keine Strategie für Agent-Identitäten hat, wird bei den kommenden Regulierungen kalt erwischt.

Was du jetzt konkret tun solltest

1. Inventur machen

Erstelle ein vollständiges Inventar aller KI-Agenten. Durchsuche Service Accounts, API-Key-Nutzung, ungewöhnliche Netzwerkaktivitäten. Frag dich: Welche API-Keys sind aktiv? Welche Service Accounts sind mit keiner aktiven Person verknüpft?

2. Unique Identities vergeben

Jeder Agent bekommt eine eigene Identität. Keine Shared Credentials. Jede Aktion muss einer konkreten Agenten-Identität und einer verantwortlichen Person zuordenbar sein.

3. Least Privilege umsetzen

Exakt die Rechte vergeben, die nötig sind — nicht mehr. Regelmäßig überprüfen. Im Kontext von Sandboxing für KI-Agenten hatte ich beschrieben, wie man Agenten technisch isolieren kann. Identity Management ist die organisatorische Ergänzung.

4. Monitoring und Kill-Switch

Logge jede Aktion jedes Agenten. Und implementiere die Möglichkeit, jeden Agenten sofort abzuschalten — kein „ich muss erstmal den Server finden”. Ein Klick, Agent ist tot.

5. Lifecycle-Management

Jeder Agent braucht einen definierten Lifecycle: Erstellung, Registrierung, regelmäßige Reviews und vor allem Dekommissionierung. Der vergessene Agent auf dem Dev-Server ist der, der dir den Breach einbringt.

Das größere Bild

Was hier passiert, ist eine Wiederholung der Geschichte. In den 2000ern hatten wir Shadow IT — eigene Server unter dem Schreibtisch. In den 2010ern Shadow Cloud — ungenehmigtes AWS und Dropbox. Jetzt Shadow AI — autonome Systeme ohne Governance.

Aber es gibt einen entscheidenden Unterschied: Shadow AI Agents handeln eigenständig. Ein vergessener FTP-Server tut nichts, bis jemand darauf zugreift. Ein vergessener KI-Agent macht weiter — schickt E-Mails, macht API-Calls, verarbeitet Daten. Er ist ein aktiver Akteur.

Wer sich für die Zukunft der Agenten-Verwaltung interessiert, findet in meinem Vergleich von Managed vs. Self-Hosted KI-Agenten weitere Denkanstöße.

Fazit: Identity-First ist das neue Security-First

Die Ära der KI-Agenten hat gerade erst begonnen — und mit ihr ein Security-Problem, das massiv unterschätzt wird. 88 % Vorfallquote ist kein Zufall, sondern das Ergebnis von Infrastrukturen, die für eine Welt ohne autonome KI-Systeme gebaut wurden.

Die Lösung ist ein Paradigmenwechsel: Jeder KI-Agent ist eine Identität. Jede Identität braucht Governance. Keine Ausnahmen.

Die Tools existieren oder kommen in den nächsten Wochen. NIST setzt Standards, Okta und CyberArk liefern Plattformen. Die Frage ist nicht, ob du Agent-Identity-Management brauchst, sondern wie schnell du es umsetzen kannst.

Fang heute an. Mach die Inventur. Finde die Shadow Agents. Gib ihnen Identitäten. Schränke ihre Rechte ein. Und bau den Kill-Switch ein, bevor du ihn brauchst.

Denn der nächste Sicherheitsvorfall kommt nicht von einem Hacker, der dein Passwort knackt. Er kommt von einem vergessenen Agenten, den niemand mehr auf dem Schirm hat.