Agenten sind keine Nutzer: Die Identitätskrise hinter 88 % der KI-Vorfälle in Unternehmen

Im Februar 2026 hat Gravitee Umfragedaten von mehr als 900 Führungskräften veröffentlicht, die zeigen: 88 % der Organisationen hatten im vergangenen Jahr einen bestätigten oder vermuteten Sicherheitsvorfall mit KI-Agenten (opens in new tab), während nur 21,9 % der Teams KI-Agenten als eigenständige identitätstragende Security Principals behandeln. 45,6 % verlassen sich nach wie vor auf gemeinsam genutzte API-Keys für die Authentifizierung zwischen Agenten. Über die Hälfte aller Agenten läuft ganz ohne Sicherheits-Oversight oder Logging.

Die Geschichte ist nicht, dass Prompt Injection die Oberhand gewinnt. Sie ist, dass die meisten von uns Agenten nach zwei Mustern in die Produktion gebracht haben, die nie tragfähig waren: über die Credentials eines menschlichen Nutzers ("als Jane ausführen") oder über einen Service Account, dessen Scope einmal für einen Batch-Job aus 2018 bemessen wurde. Wenn etwas schiefläuft, endet der Incident Report immer gleich — der Agent hatte die Rechte für das, was er tat, niemand konnte erklären, warum, und niemand konnte ihn sauber abschalten.

Was folgt, ist das Identitätsmodell, das wir standardmäßig einsetzen, warum die üblichen Alternativen strukturell kaputt sind, und ein konkretes Muster — OIDC Workload Identity, kurzlebige JWTs, enge Policies pro Agent, ein zentraler Event Log — mit dem Sie einen entgleisten Agenten in unter einer Minute abschalten, ohne jedes Secret in Ihrem Bestand rotieren zu müssen.

Der Vorfall ist fast nie das, was die Pressemitteilung behauptet

Wenn man genug Post-Mortems liest, zeichnet sich ein Muster ab. Die Pressemitteilung sagt: "Prompt Injection führte zur Datenexfiltration." Der tatsächliche Report sagt: Ein Agent bekam ein Personal Access Token eines Senior Engineers, das Token trug Org-Admin-Rechte auf einem Dutzend Repos, ein Tool Call schleuste Daten über einen Pfad aus, an den niemand gedacht hatte, und die Rotation des geteilten Tokens legte die Produktion für sechs Stunden lahm.

Die OWASP Top 10 for Agentic Applications 2026 (opens in new tab) benennt das direkt: ASI03 heißt "Identity and Privilege Abuse" — das Ausnutzen delegierten Vertrauens, geerbter Credentials oder Rollenketten. Der Microsoft-Beitrag zum Umgang mit diesen Risiken (opens in new tab) hebt dasselbe Muster hervor. Prompt Injection ist gelegentlich der Auslöser. Der Blast Radius hängt immer am Identitätsmodell.

"Als Jane ausführen" ist eine Haftungsfrage, kein Design

Einem Agenten die Credentials eines Menschen zu geben, ist der schnellste Weg an Corporate SSO vorbei. Es ist auch die Entscheidung, die am schlechtesten altert — aus drei disqualifizierenden Gründen.

Revocation wird zur karrierelimitierenden Entscheidung. Wenn "Janes Agent" um zwei Uhr morgens Unsinn macht, ist Ihr einziger Hebel Janes Account. Ihre Session zu deaktivieren, beendet den Agenten — und gleichzeitig ihr VPN, ihre Laptop-Synchronisation, ihren Kalender und jede andere Automatisierung unter ihrer Identität. On-Call-Engineers weigern sich, den Hebel zu ziehen, bis ein Senior zustimmt, und genau dieser Zeitverlust ist das Fenster, in dem der Agent weiter Calls abfeuert.

Der Audit-Pfad kollabiert auf einen einzigen Akteur. Jede Log-Zeile sieht aus, als hätte Jane sie erzeugt. Wenn Compliance fragt, wer die Kundenliste exportiert hat, lautet die Antwort Jane — bis Sie forensisch rekonstruieren, welches Event von ihr stammte und welches vom Agenten.

Scope Inflation ist unvermeidbar. Jane hat die Scopes, die sie für ihre Arbeit braucht, und bei jedem Senior Operator sind das die meisten. Ihr Agent erbt das vollständig — eine latente Angriffsfläche, die still weiterwächst, sobald Jane neue Verantwortlichkeiten übernimmt.

"Als Jane ausführen" ist in Ordnung für einen Fünf-Minuten-Prototyp. Es ist eine Abkürzung, die achtzehn Monate in Ihrer Codebasis bleibt, bis ein Breach Sie zwingt, sie rauszureißen.

Generische Service Accounts scheitern in die andere Richtung

Das zweithäufigste Muster ist ein geteilter Service Account — ai-agent@company.com, ml-bot-prod — mit einem breiten Token, das jeder Agent nutzt. Das ist, was 45,6 % der Gravitee-Befragten aktuell tun. Es löst das "Jane wird gekündigt"-Problem und produziert vier schlimmere.

Attribution pro Agent ist konstruktionsbedingt verloren. Jede Log-Zeile sagt ml-bot-prod. Benimmt sich einer von fünf Agenten daneben, rotieren Sie das geteilte Credential und brechen die anderen vier.

Das Credential ist langlebig und weit verteilt. Geteilte Keys landen in CI-Secrets, in .env-Dateien, in Slack-DMs und in alten Notion-Seiten. Die Enthüllung im Juni 2026 von 16 Milliarden Credentials, bewaffnet zum Zugriff auf Corporate Data Lakes und KI-Agenten-Systeme (opens in new tab), traf auf Umgebungen, in denen genau das Standard war.

Scope wird für den größten Use Case bemessen. Wenn irgendein Agent ins CRM schreiben muss, dürfen es alle. Least Privilege kollabiert zur Vereinigungsmenge aller Caller-Bedürfnisse.

Niemand ist verantwortlich. Menschliche Accounts werden vierteljährlich rezertifiziert. ml-bot-prod hat niemanden. Nicht-menschliche Identitäten übertreffen menschliche in Unternehmensnetzen inzwischen ungefähr 50 zu 1 (opens in new tab), die meisten auf langlebigen Tokens, die klassisches Tooling nie erfasst hat.

Was eine Agenten-Identität tatsächlich braucht

Wenn Sie den Vendor Pitch weglassen, sind die Anforderungen schmal. Bei den meisten Teams, mit denen wir arbeiten, fehlen drei oder vier dieser sechs.

1. Eine eindeutige, nicht wiederverwendbare Kennung. Eine pro Agent-Instanz, nicht eine pro Agent-Typ. Zehn Summarizer-Worker bedeuten zehn IDs. Erst das macht Attribution möglich und Revocation chirurgisch statt nuklear.

2. Ein kurzlebiges Credential. Minuten bis eine Stunde, keine Monate. SPIFFEs SVIDs haben standardmäßig 1-Stunden-TTLs mit automatischer Erneuerung bei 50 % der Gültigkeitsdauer (opens in new tab). Ein kompromittiertes 1-Stunden-Credential hat ein 60-minütiges Blast-Window; eines mit einem Jahr hat 8.760 Stunden.

3. Ein enger, expliziter Scope. Nicht "Read-Write auf CRM" — sondern "Read auf Contacts, wo owner_id = <initiating user>, Write auf Notizen zu gelesenen Contacts, kein Zugriff auf Opportunities oder Billing." Wenn das mühsam klingt: gut. Es ist absichtlich mühsam.

4. Attribution zurück auf den initiierenden Menschen. Autonome Agenten handeln immer noch als Reaktion auf einen menschlichen Auslöser. Das Token muss diese Abstammung tragen. Der act-Claim aus RFC 8693 ist das Standardkonstrukt: Das Token ist für den Nutzer, der Actor ist der Agent, und Claims können verschachtelt werden, um Ketten abzubilden. Christian Postas Analyse von On-behalf-of für KI-Agenten (opens in new tab) ist die klarste Erklärung dazu, die wir gefunden haben.

5. Ein Append-Only-Audit-Trail. Jeder Tool Call, jede Scope Assertion — mit Agent-ID, initiierendem Menschen, Zeitstempel und Ergebnis — auf Infrastruktur, die der Agent nicht redigieren kann. Kiteworks weist darauf hin, dass 33 % der Organisationen überhaupt keine KI-Audit-Trails haben und 61 % auf fragmentierter Infrastruktur laufen, die keine belastbaren Nachweise liefern kann (opens in new tab). Die Audit-Trail-Lücke ist der stärkste Einzelprädiktor für Governance-Versagen.

6. Revocation mit einem Klick, für einen Agenten. Sie müssen einen einzelnen Agenten per ID benennen und jedes Credential, das er hält, invalidieren können, ohne irgendetwas anderes zu berühren. Wenn Ihre Antwort darin besteht, ein geteiltes Secret zu rotieren, haben Sie die nukleare Option — keine Revocation.

Ein konkretes Muster, das funktioniert

Das Modell, das wir standardmäßig einsetzen, hat drei bewegliche Teile und einen Event Bus und setzt voraus, dass Sie bereits einen OIDC IdP (Keycloak, Auth0, Entra ID, Ory) und eine Policy Engine (OPA, Cedar oder das native Äquivalent Ihrer Plattform) im Einsatz haben.

OIDC-ausgestellte Workload Identity pro Agent-Instanz. Wenn ein Agent startet, präsentiert er etwas, das Ihre Infrastruktur attestieren kann — ein JWT eines Kubernetes Service Accounts, Cloud-Instance-Metadata, ein SPIFFE SVID — und tauscht das gegen ein kurzlebiges OIDC-Token, gebunden an eine konkrete Agent-ID wie agent:summarizer:prod:7a2c91. Der IdP verweigert Tokens für IDs, die nicht auf einer Allowlist stehen.

Kurzlebige JWTs, pro Interaktion gescopet. Wenn der Agent im Namen eines Nutzers handelt, führt er einen Token Exchange nach RFC 8693 (opens in new tab) aus und reicht sowohl sein eigenes als auch das Token des Nutzers ein. Das resultierende Access Token trägt einen act-Claim mit dem Agenten, einen sub mit dem Nutzer, eine aud, die auf eine Downstream-API beschränkt ist, und Scopes, die auf die Schnittmenge von Nutzer- und Agent-Permissions verengt sind. TTL: fünf bis fünfzehn Minuten.

Policies pro Agent, an der Ressource durchgesetzt. Die Policy Engine hält Regeln wie "Agent agent:summarizer:* darf E-Mails lesen, bei denen der act.sub mit dem Mailbox-Eigentümer übereinstimmt; darf nicht senden; darf nicht löschen." Deklarativ, versionskontrolliert, in Pull Requests reviewt. Eine Policy-Änderung erfordert kein Deployment.

Ein Event Bus, der jede Entscheidung loggt. Jeder Token Exchange, jede Policy Evaluation, jeder Tool Call wird an einen unveränderlichen Stream angehängt, der Ihr SIEM, Ihre Analytics und einen Kill-Switch-Service speist. "Was hat Agent X heute getan?" beantworten Sie mit einer einzigen Query.

Das ist nicht revolutionär. SPIFFE/SPIRE liefert Workload Identity. OAuth 2.1 plus RFC 8693 liefert Delegation. OPA oder Cedar liefert Policies. Was in den meisten Implementierungen fehlt, ist die Disziplin, diese Bausteine gezielt für Agenten zusammenzubringen.

Die Revocation-Brandschutzübung

Jedes Team, mit dem wir arbeiten, bekommt am ersten Tag dieselbe Übung: einen einzelnen Agenten benennen, ihn abschalten, bestätigen, dass er tot ist. Stoppuhr läuft. Ziel: unter 60 Sekunden. Die meisten Teams brauchen im ersten Anlauf zwischen sechs Minuten und vier Stunden — die Varianz hängt fast ausschließlich an der Credential-Struktur.

Eine funktionierende Übung: Ein Operator öffnet die Admin-Konsole, sucht die Agent-ID, klickt auf Revoke. Der IdP markiert die ID als deaktiviert, verweigert weitere Exchanges und publiziert ein Revocation-Event. Downstream-APIs, die den Stream abonnieren, lehnen noch laufende Tokens ab. In maximal 15 Minuten besitzt der Agent kein funktionierendes Credential mehr; eine Deny-Regel der Policy Engine drückt das auf Sekunden.

Die Variante über den geteilten Service Account: geteilten Key rotieren, an einen Secrets Manager propagieren, vier Agenten, einen Cron-Job und das CI neu deployen. Die legitimen Systeme gehen down. Der abtrünnige Agent arbeitet, wenn er das alte Credential gecached hat, weiter — bis zum nächsten Fetch.

Berichterstattung zu Agent Governance (opens in new tab) hält fest, dass die meisten Organisationen ihre Agenten zwar überwachen, aber nicht stoppen können. Containment, nicht Detection, ist die Lücke.

Scope Inflation ist der zweite stille Killer

Revocation beantwortet "Können wir einen Agenten stoppen, der heute entgleist?". Sie beantwortet nicht das langsamere Versagen: einen Agenten, dessen Scope über zwei Jahre gewachsen ist, während niemand hingesehen hat. Ein Assistent, der mit "Kalender lesen, Zeiten vorschlagen" gestartet ist, landet bei "E-Mails lesen, CRM lesen, ins CRM schreiben, Webhooks auslösen, im Namen jedes Nutzers handeln". Jeder einzelne Schritt war begründet. Das Gesamte hat niemand reviewt.

Die Gegenmaßnahmen sind langweilig und wirksam.

Scopes nach Plan prüfen. Quartalsweise. Vergleichen Sie, was die Policy gewährt, mit dem, was der Agent in den letzten 90 Tagen tatsächlich genutzt hat. Ungenutzte Scopes werden entfernt; bricht das etwas, lernen Sie, welcher Code-Pfad von einem Scope abhing, den niemand begründen konnte.

Auf Scope-Erweiterungen alerten, nicht nur auf Nutzung. Ihr IdP emittiert ein Event, wenn die Policy eines Agenten einen Scope hinzufügt. Dieses Event geht an einen Menschen, nicht in ein Log. Erweiterungen in der Produktion außerhalb von Change Windows werden untersucht.

Scope-Verengung pro Nutzer statt rollenweitem Scope bevorzugen. "E-Mails des Nutzers, der diese Aufgabe initiiert hat, lesen" ist eingegrenzt; "E-Mails lesen" ist eine Haftungsfrage. Die Verengung steht im Token Exchange, nicht in der Anwendungslogik.

"Kann Agenten erstellen" als privilegiert behandeln. Gravitee weist darauf hin, dass 25,5 % der deployten Agenten weitere Agenten erzeugen und beauftragen können (opens in new tab). Diese Fähigkeit potenziert Scope Creep exponentiell und gehört hinter eine explizite Freigabe.

Wohin die Standards laufen

Im Januar 2026 hat das US-amerikanische NIST CAISI eine Federal-Register-RFI zu Sicherheitsüberlegungen für KI-Agenten (opens in new tab) veröffentlicht, mit Kommentarfrist bis zum 9. März 2026. Die Stellungnahmen forderten das NIST auf, SP 800-218 (SSDF) (opens in new tab) und SP 800-160 so zu erweitern, dass sie agentische KI über den gesamten Lebenszyklus abdecken. Formelle Leitlinien sind im Laufe von 2026 und Anfang 2027 zu erwarten.

Für Teams im DACH-Raum richten sich BaFin- und BSI-Leitlinien in der Regel sechs bis zwölf Monate später an NIST-Mustern aus. Wenn Sie das oben skizzierte Identitätsmodell jetzt bauen, sind Sie dem voraus, worauf Compliance landen wird. Bleiben Sie auf "als Jane ausführen", werden Sie hetzen.

Die Kurzfassung

Behandeln Sie jeden Agenten als identitätstragenden Principal: eindeutige ID, kurzlebiges Token, enger Scope, klare Attribution zum initiierenden Menschen, unveränderlicher Audit-Trail, einziger Revocation-Pfad. Fahren Sie die Revocation-Brandschutzübung vierteljährlich. Prüfen Sie Scopes vierteljährlich. Lassen Sie niemals einen Agenten Credentials mit einem menschlichen Nutzer oder einem anderen Agenten teilen.

Die Muster — SPIFFE Workload Identity, OAuth 2.1 Token Exchange mit RFC 8693, Policy Engines, eventbasierter Audit — sind seit Jahren produktionsreif. Neu ist, sie gezielt auf Agenten anzuwenden, statt zu erben, was gerade an IAM herumlag. Die Inzidenzrate von 88 % ist das Symptom dafür, dass genau dieser Schritt übersprungen wird.

Weiterführende Literatur

• Gravitee — State of AI Agent Security 2026 Report (opens in new tab)
• OWASP Top 10 for Agentic Applications 2026 (opens in new tab)
• Microsoft — Addressing OWASP Top 10 Risks in Agentic AI with Copilot Studio (opens in new tab)
• NIST CAISI — RFI on Security Considerations for AI Agents (Federal Register, Januar 2026) (opens in new tab)
• RFC 8693 — OAuth 2.0 Token Exchange (opens in new tab)
• SPIFFE Concepts — Workload Identity und SVIDs (opens in new tab)
• Christian Posta — Explaining OAuth Delegation, On Behalf Of, and Agent Identity for AI Agents (opens in new tab)