Von den rund 3 Millionen KI-Agenten in US-amerikanischen und britischen Unternehmen arbeiten 1,5 Millionen ohne aktive Aufsicht. Fast jeder zweite Agent hat keine Governance, keinen Audit-Trail und keinen klaren Verantwortlichen. Das ist kein theoretisches Risiko. Es ist der aktuelle Zustand in Unternehmen weltweit, und die Sicherheitsbranche spricht bereits von der “Agent Identity Crisis”.
Das Problem ist nicht mangelndes Sicherheitsbewusstsein. Das Problem ist, dass KI-Agenten in keine der Kategorien passen, für die klassische Identity-Systeme gebaut wurden. Ein Agent ist kein menschlicher Benutzer. Er ist kein Service Account. Er ist etwas Neues: autonom, kurzlebig, fähig, Unter-Agenten zu starten, und mit tausenden Aktionen pro Sekunde arbeitend. Nur 18% der Security-Verantwortlichen sind zuversichtlich, dass ihr aktuelles IAM diese Identitäten verwalten kann.
Warum klassisches IAM bei Agenten versagt
Identity and Access Management wurde für ein einfaches Modell gebaut: Ein Mensch meldet sich an, bekommt eine Rolle, greift auf Ressourcen innerhalb dieser Rolle zu. Das System geht davon aus, dass die Identität dauerhaft ist, die Zugriffsmuster vorhersehbar sind und die Session einen klaren Anfang und ein klares Ende hat.
KI-Agenten verletzen jede einzelne dieser Annahmen.
Agenten sind autonom und kurzlebig
Ein Kundenservice-Agent startet vielleicht um 9:01 Uhr, bearbeitet 200 Tickets und wird um 17:00 Uhr beendet. Ein Datenanalyse-Agent existiert möglicherweise nur 47 Sekunden, um eine Abfrage auszuführen und Ergebnisse zu liefern. Klassisches IAM verwaltet langlebige Konten mit stabilen Zugriffsmustern. Agent-Identitäten sind konstruktionsbedingt kurzlebig.
Die CSA/Strata-Umfrage unter 285 Security-Fachleuten ergab: 44% der Unternehmen nutzen weiterhin statische API-Keys für die Authentifizierung ihrer Agenten. Weitere 43% setzen auf Benutzername/Passwort-Kombinationen. Beide Ansätze setzen eine dauerhafte Identität voraus und schaffen genau die Art langlebiger Credentials, die Angreifer ausnutzen.
Agenten erzeugen Unter-Agenten
Laut Gravitees State of AI Agent Security 2026 können 25,5% der eingesetzten Agenten andere Agenten erstellen und beauftragen. Ein Research-Agent beauftragt einen Datenabruf-Agenten, der einen Datenbank-Agenten beauftragt, der einen Formatierungs-Agenten beauftragt. Jeder Unter-Agent erbt Berechtigungen des Eltern-Agenten, aber die meisten IAM-Systeme können diese Delegationskette nicht nachverfolgen.
Wenn etwas schiefgeht, muss klar sein: Welcher Agent hat es getan, wer hat diesen Agenten autorisiert, welche Berechtigungen hatte er und wie hat er sie bekommen. Nur 28% der Unternehmen können Agent-Aktionen über alle Umgebungen hinweg auf ihre menschlichen Auftraggeber zurückverfolgen.
Non-Human Identities explodieren
Das Ausmaß ist beeindruckend. Non-Human Identities (NHIs), also Service Accounts, API-Keys, OAuth-Tokens und jetzt KI-Agenten, übersteigen menschliche Identitäten im Verhältnis 144:1 im durchschnittlichen Unternehmen. Dieses Verhältnis wuchs innerhalb eines Jahres um 44%. Jeder KI-Agent kommt dazu, und jeder einzelne stellt einen Zugangspunkt dar, der Governance benötigt.
Authorization Bypass: Wie es in der Praxis aussieht
Die größte Gefahr unkontrollierter Agent-Identitäten ist nicht der Datendiebstahl durch externe Angreifer. Es sind legitime Mitarbeitende, die versehentlich Zugang zu Daten erhalten, die sie nie sehen sollten, weil Agenten breitere Berechtigungen haben als jeder einzelne Mensch.
Der Marketing-Agent als Datenleck
The Hacker News dokumentierte einen Fall bei einem Technologieunternehmen mit rund 1.000 Mitarbeitenden. Das Unternehmen setzte einen KI-Agenten für Marketingaufgaben ein und gab ihm breiten Zugriff auf die Databricks-Umgebung. Als ein neuer Mitarbeiter namens John, bewusst mit eingeschränkten Rechten ausgestattet, den Agenten um eine Churn-Analyse bat, lieferte dieser detaillierte sensible Kundendaten, auf die John über seine eigenen Credentials keinen Zugriff hatte.
Die breiten Berechtigungen des Agenten umgingen das gesamte Zugangskontrollmodell des Unternehmens. John hackte nichts. Er stellte eine Frage in natürlicher Sprache, und der Agent antwortete mit Daten, auf die er selbst Zugriff hatte, John aber nicht. Im Kontext der DSGVO wäre das ein meldepflichtiger Vorfall, da personenbezogene Daten an unbefugte Empfänger gelangten.
CyberArks Finanzsektor-Angriffsdemo
CyberArk Labs demonstrierte einen Angriff auf den KI-Agenten eines Finanzdienstleisters. Die Forscher betteten bösartige Prompts in ein Lieferadressen-Feld ein. Der Agent wurde dazu gebracht, Tools über seinen eigentlichen Zweck hinaus zu nutzen, griff auf Rechnungssysteme zu und extrahierte sensible Bankdaten von Lieferanten. Die Ursachen waren banal: keine Eingabefilterung, keine Prompt-Sanitisierung und zu weitreichende Berechtigungen.
88% hatten Vorfälle im letzten Jahr
Das sind keine Einzelfälle. Gravitees Umfrage unter 750 CTOs und VPs ergab: 88% der Unternehmen meldeten bestätigte oder vermutete Sicherheitsvorfälle mit KI-Agenten im vergangenen Jahr. Im Gesundheitswesen lag die Quote bei 92,7%. Dokumentierte Vorfälle umfassen Agenten, die auf veralteten Daten operierten, vertrauliche Daten weitergaben, Datenbanken ohne Autorisierung löschten und unautorisierte Finanzentscheidungen trafen.
Gravitee-CEO Rory Blundell formulierte es klar: “Es gibt jetzt über 3 Millionen KI-Agenten in Unternehmen, eine Belegschaft größer als die gesamte globale Mitarbeiterzahl von Walmart. Aber viel zu oft werden diese Agenten nicht kontrolliert.”
Der Agent-IAM-Stack: Was funktioniert
Die Absicherung von KI-Agent-Identitäten erfordert ein Umdenken in drei Bereichen: wie Agenten authentifiziert werden, wie ihre Aktionen autorisiert werden und wie nachverfolgt wird, was sie getan haben.
Authentifizierung: Kurzlebige Tokens statt API-Keys
Das erste Prinzip ist einfach: Agenten sollten niemals langlebige Credentials besitzen. Statische API-Keys landen in Konfigurationsdateien, werden in Repositories committed und existieren noch lange, nachdem der Agent, der sie nutzte, beendet wurde.
Der bessere Ansatz ist OAuth 2.0 mit kurzlebigen, scope-begrenzten Tokens. Microsofts Entra Agent ID, angekündigt auf der Build 2025, implementiert genau das: Agenten erhalten Federated Identity Credential (FIC) basierte Tokens, die schnell ablaufen und nur auf bestimmte Ressourcen zugreifen können. Auth0s Auth for GenAI verfolgt einen entwicklerorientierten Ansatz und integriert Agent-Identität in LangChain, LlamaIndex und Vercel AI Workflows.
Wie t3n.de berichtet, ist das Schlüsselmuster Delegation statt Impersonation: Ein Agent erhält ein delegiertes Token mit begrenztem Scope, abgeleitet von den Berechtigungen seines menschlichen Auftraggebers, aber niemals dessen tatsächliche Credentials.
Autorisierung: Least Privilege pro Aufgabe
Jeder Agent sollte mit null stehenden Berechtigungen starten. Er beantragt Zugriff auf bestimmte Ressourcen für eine bestimmte Aufgabe, erhält eine kurzfristige Gewährung, und diese Gewährung verfällt, wenn die Aufgabe abgeschlossen ist.
CyberArks Ansatz behandelt jeden KI-Agenten als privilegierte Identität, die dieselben Kontrollen erfordert wie ein menschlicher Administrator: Just-In-Time (JIT) Zugriffsbereitstellung, Sitzungsaufzeichnung und Echtzeit-Verhaltensanalyse durch ihr CORA-AI-System. Strata Identitys AI Identity Gateway bietet dynamischen On-Behalf-Of (OBO) Token-Austausch und Runtime-Autorisierung.
Das Ziel: Wenn ein Agent kompromittiert wird oder eigenständig agiert, bleibt der Schaden auf das begrenzt, was er in genau diesem Moment tun durfte, nicht auf alles, was er theoretisch hätte zugreifen können.
Nachverfolgbarkeit: Jede Aktion zurück zu einem Menschen
Der EU AI Act verlangt die Nachverfolgbarkeit von KI-Systemaktionen, und das aus gutem Grund. Wenn ein Agent eine Datenbanktabelle löscht oder eine E-Mail an einen Kunden sendet, muss jemand verantwortlich sein. Das geht über die Anforderungen des EU AI Act hinaus: Auch die DSGVO verlangt bei der Verarbeitung personenbezogener Daten eine klare Verantwortungszuordnung. Die BaFin-Aufsicht stellt für den Finanzsektor zusätzliche Anforderungen unter DORA (Digital Operational Resilience Act).
Das bedeutet: Jede Agent-Aktion muss protokolliert werden mit der Identität des Agenten, dem menschlichen Auftraggeber, der den Agenten autorisierte, der spezifischen Berechtigungserteilung und dem Ergebnis. Nur 21% der Unternehmen führen Echtzeit-Inventare ihrer Agenten.
Das Agentic AI IAM Framework der Cloud Security Alliance schlägt Decentralized Identifiers (DIDs), Verifiable Credentials (VCs) und einen Agent Naming Service (ANS) vor. Die OpenID Foundation veröffentlichte ein Whitepaper zu den Protokoll-Herausforderungen.
Wer Agent-IAM baut
Die Anbieterlandschaft teilt sich in zwei Lager: etablierte IAM-Anbieter, die Agent-Funktionen ergänzen, und Startups, die Agent-first-Identitätsplattformen bauen.
Etablierte Anbieter: Microsoft (Entra Agent ID), Okta/Auth0 (Auth for GenAI), CyberArk (CORA AI + Privileged Access für Agenten) und Ping Identity (delegationsbasierter Agent-Zugriff). Diese Unternehmen haben die Enterprise-Beziehungen und können Agent-Identität in bestehende IAM-Stacks einbetten.
Agent-first-Startups: Strata Identity (AI Identity Gateway), Frontegg (zweckgebautes Agent-IAM), Aembit (Workload Identity für Agenten), Astrix Security (NHI Discovery und Governance) und Token Security (NHI für die Agentic Era). Wie security-insider.de berichtet, bieten auch DACH-Anbieter wie FirstAttribute AG mit ihrer my-IAM-Plattform Lösungen für KI-Identitäten auf Basis von Microsoft Entra ID.
Das M&A-Signal ist stark: Palo Alto Networks übernimmt CyberArk für rund 25 Milliarden Dollar. Identitätssicherheit für autonome Agenten ist eindeutig das Investitionsfeld der Stunde.
Fünf Schritte zur Agent-Identity-Strategie
Basierend auf dem CSA-Framework und CyberArks Vier-Säulen-Modell sieht eine praktische Umsetzung so aus.
Schritt 1: Inventarisieren. Identifizieren Sie jeden KI-Agenten in Ihrer Umgebung, wer ihn eingesetzt hat, worauf er zugreift und ob er Unter-Agenten starten kann. Nur 21% der Unternehmen tun das heute.
Schritt 2: Verantwortlichkeiten zuordnen. Jeder Agent braucht einen menschlichen Auftraggeber, der für seine Aktionen verantwortlich ist. Keine verwaisten Agenten. Wenn niemand ihn verantwortet, läuft er nicht.
Schritt 3: Statische Credentials ablösen. Migrieren Sie von API-Keys und Shared Service Accounts zu OAuth 2.0/OIDC-basierten kurzlebigen Tokens. Microsoft Entra Agent ID, Auth0 oder Curity bieten Implementierungspfade.
Schritt 4: Least Privilege pro Aufgabe. Implementieren Sie JIT-Zugriffsbereitstellung, damit Agenten scope-begrenzte Berechtigungen nur bei Bedarf erhalten, keine stehenden Zugriffsrechte.
Schritt 5: Überwachen und reagieren. Setzen Sie Identity Threat Detection and Response (ITDR) für Agent-Identitäten ein. CyberArk, Strata und Okta bieten agenten-bewusstes Monitoring. Definieren Sie Schwellenwerte für Anomalien: ungewöhnliche Zugriffsmuster, Rechteeskalation und Datenvolumen-Spitzen.
Die 40% der Unternehmen, die aktuell ihre Identitäts-/Security-Budgets erhöhen für KI-Agent-Risiken, treffen die richtige Entscheidung. Die anderen 60% werden nachziehen, wahrscheinlich nach einem Vorfall.
Häufig gestellte Fragen
Wie authentifizieren sich KI-Agenten bei Unternehmenssystemen?
Der empfohlene Ansatz ist OAuth 2.0 mit kurzlebigen, scope-begrenzten Tokens statt statischer API-Keys oder Passwörter. Microsofts Entra Agent ID nutzt Federated Identity Credentials für den Token-Austausch. Auth0s Auth for GenAI integriert Agent-Identität in Frameworks wie LangChain und Vercel AI. Das Schlüsselprinzip ist Delegation: Agenten erhalten begrenzte Tokens, abgeleitet von den Berechtigungen ihres menschlichen Auftraggebers.
Was ist der Unterschied zwischen menschlicher Identität und KI-Agent-Identität?
Menschliche Identitäten sind dauerhaft, langlebig und folgen vorhersehbaren Zugriffsmustern. KI-Agent-Identitäten sind kurzlebig, autonom und können Unter-Agenten erzeugen. Agenten arbeiten mit Maschinengeschwindigkeit und führen tausende Aktionen pro Sekunde aus. Klassisches IAM verwaltet stabile Benutzerkonten; Agent-IAM muss dynamische, kurzlebige Identitäten mit Delegationsketten handhaben, die auf einen menschlichen Auftraggeber zurückverfolgbar sind.
Warum reicht klassisches IAM für KI-Agenten nicht aus?
Klassisches IAM setzt dauerhafte Identitäten mit vorhersehbaren Zugriffsmustern und klaren Session-Grenzen voraus. KI-Agenten verletzen diese Annahmen: Sie sind autonom, kurzlebig, können Unter-Agenten erzeugen und arbeiten mit Maschinengeschwindigkeit. Eine CSA/Strata-Umfrage ergab, dass 44% der Unternehmen noch statische API-Keys für die Agent-Authentifizierung nutzen und nur 18% der Security-Verantwortlichen zuversichtlich sind, dass ihr IAM Agent-Identitäten verwalten kann.
Was passiert, wenn ein KI-Agent mehr Rechte hat als sein Benutzer?
Es kommt zum Authorization Bypass. The Hacker News dokumentierte einen Fall, in dem ein Marketing-KI-Agent mit breitem Databricks-Zugriff sensible Kundendaten an einen neuen Mitarbeiter lieferte, der bewusst eingeschränkte Rechte hatte. Der Mitarbeiter hackte nichts; der Agent hatte breiteren Zugriff als der Benutzer und erfüllte die Anfrage mit seinen eigenen Credentials. Im Kontext der DSGVO wäre dies ein meldepflichtiger Vorfall.
Wie sollten Unternehmen sich auf KI-Agent-Identitätsmanagement vorbereiten?
Fünf Schritte: (1) Alle KI-Agenten in der Umgebung inventarisieren, (2) jedem Agenten einen menschlichen Auftraggeber zuordnen, (3) statische API-Keys durch OAuth 2.0/OIDC-basierte kurzlebige Tokens ersetzen, (4) Least Privilege pro Aufgabe mit Just-In-Time-Zugriff durchsetzen und (5) Identity Threat Detection and Response (ITDR) für Agent-Identitäten einsetzen. Das Agentic AI IAM Framework der Cloud Security Alliance bietet eine umfassende Referenzarchitektur.