Agenten werden zu einem IAM-Workload, und Ihre Servicekonten sind nicht darauf vorbereitet

Zuerst will ich die etablierte Sicht so stark wie möglich darstellen, denn sie ist keineswegs dumm. Servicekonten und API-Schlüssel tragen seit zwei Jahrzehnten Maschinen-Workloads. Sie sind verstanden, sie werden auditiert, jede Cloud und jedes SaaS-Tool unterstützt sie, und das Sicherheitsteam hat bereits eine Tabelle mit allen Einträgen. Wenn jemand sagt, Agenten bräuchten eine neue Identitätskategorie, ist die vernünftige Antwort: Wir haben bereits eine, sie heißt nicht-menschliche Identität, also nutzen wir sie.

Hier hört das jedoch auf zu funktionieren. Ein Servicekonto beantwortet die Frage: "Welches System ruft auf?" Ein Agent erzwingt eine schwierigere Frage: "Welcher Agent ruft auf, in wessen Auftrag, mit welchem Ziel, und wer kann ihn in den nächsten dreißig Sekunden widerrufen?" Die eigenen Zahlen der IAM-Branche besagen, dass nicht-menschliche Identitäten Menschen inzwischen um eine Größenordnung übertreffen. Der Verizon DBIR 2026 warnte außerdem davor, Service- und Maschinenkonten besonders im Blick zu behalten, wenn agentische KI Einzug hält, laut Token Securitys Einordnung des Berichts. Dies ist ein Briefing dazu, warum die Zuordnung scheitert, was als Ersatz gebaut wird und wie die Fehler bereits heute aussehen.

Wichtigste Erkenntnisse - Servicekonten und API-Schlüssel setzen einen stabilen, deterministischen Aufrufer voraus. Agenten sind kurzlebig, nicht deterministisch und delegieren untereinander. Damit brechen die Annahmen zu Audit, Widerruf und Least Privilege, die in gemeinsam genutzten Zugangsdaten stecken. - Die Standardisierung bewegt sich in Richtung Workload-Identität pro Agent: Die IETF-WIMSE-Arbeitsgruppe wird dazu gedrängt, Agenten über ihre Identität unterscheidbar zu machen, nicht nur über Token-Scopes, mit SPIFFE-artigen Kennungen pro Agent für Richtlinien, Audit und Widerruf. - Die Vorfälle sind bereits konkret: Kompromittierte OAuth-Tokens im Salesloft-Drift-Ökosystem wurden genutzt, um in Salesforce-Umgebungen von Unternehmen vorzudringen, und der Hugging-Face-Vorfall im Juli wurde von einem autonomen Agenten vollständig durchgeführt. - Die Implementierungsempfehlungen konvergieren: eine eigene Identität pro Agent, kurzlebige und aufgabenbezogene Zugangsdaten außerhalb des Modellkontexts sowie Audit-Trails, die dem Agenten und nicht einer gemeinsamen Rolle zugeordnet sind. - Wenn sich Ihre Agenten alle über ein gemeinsames Servicekonto authentifizieren, können Ihre Logs nicht sagen, welcher Agent was getan hat. Das ist der Test für diese Woche.

Was passiert ist

In den ersten Augustwochen liefen zwei Entwicklungen zusammen. Erstens wurde die Standardisierungsdebatte konkret. Ein am 4. August erstelltes Issue zum IETF-WIMSE-Architekturentwurf argumentiert, dass die aktuelle Formulierung des Entwurfs zu KI-Vermittlern zu schwach ist: Sie erlaubt "separate workload identities or token scopes", um Aktionen autonomer Agenten zu unterscheiden. Das Issue erklärt, warum Token-Scopes dafür nicht ausreichen. Scopes begrenzen, was ein Token tun darf, aber sie verändern nicht, wer das Token ist. Mehrere Agenten, die dieselben Zugangsdaten teilen, bleiben in Audit-Logs, Widerrufssystemen und agentenspezifischen Richtlinien ununterscheidbar, unabhängig davon, wie unterschiedlich die Scopes sind. Der vorgeschlagene Fix: Verwaltete Agentenplattformen sollten jedem Agenten eine eindeutige Workload-Kennung geben, die in einem eigenen Claim übertragen und als stabiler Schlüssel für Richtlinien, Audit und Widerruf verwendet wird. Googles Agentenidentitätsdesign, bei dem jeder bereitgestellte Agent eine SPIFFE-basierte Identität erhält, die an seine Agentenressource gebunden ist, wird als funktionierendes Beispiel genannt.

Zweitens rissen die Vorfälle nicht ab. Der Hugging-Face-Vorfall Mitte Juli war der erste öffentlich bekannte Einbruch bei einem namentlich genannten Unternehmen, der von einem autonomen Agenten von Anfang bis Ende durchgeführt wurde: Codeausführung in der Dataset-Pipeline, Erbeutung von Zugangsdaten, laterale Bewegung durch interne Cluster und Tausende Aktionen an einem Wochenende. Bereits früher im Jahr verlor Moltbook, ein soziales Netzwerk für KI-Agenten, 1,5 Millionen API-Tokens aus einer falsch konfigurierten Datenbank, nur wenige Tage nachdem die Plattform 1,5 Millionen Agentenkonten erreicht hatte, laut Studio Globals Zusammenfassung. Und das wiederkehrende DBIR-Beispiel für Angriffe auf nicht-menschliche Identitäten, die Kompromittierung von Salesloft-Drift-OAuth-Tokens und deren Nutzung für den Zugriff auf Salesforce-Umgebungen großer Unternehmen wie Google, Cisco und Zscaler, entspricht genau der Form von Zugangsdaten, von denen Agenten abhängen.

Im August 2026 schlug ein IETF-WIMSE-Issue vor, dass Agentenaktionen durch separate Workload-Identitäten und nicht durch Token-Scopes unterschieden werden müssen, mit agentenspezifischen Kennungen als stabilem Schlüssel für Richtlinien, Audit und Widerruf. Vorausgegangen waren der von einem Agenten durchgeführte Hugging-Face-Vorfall im Juli und ein Vorfall im Januar, bei dem die Agentenplattform Moltbook 1,5 Millionen API-Tokens offenlegte.

Warum Servicekonten und API-Schlüssel nicht zu Agenten passen

Die Fehlanpassung hat vier Seiten, und es lohnt sich, sie einzeln zu benennen, weil die Lösungen unterschiedlich sind.

Gemeinsame Identität zerstört Zuordnung. Servicekonten sind darauf ausgelegt, gemeinsam genutzt, statisch und breit privilegiert zu sein. Zehn Agenten unter einem Konto führen dazu, dass Ihr Audit-Log nur einen Akteur zeigt, wie es Cockroach Labs in einem Praxisbericht formuliert: Sie können nicht erkennen, welcher Agent auf welche Daten zugegriffen hat, Rotation muss über alle Agenten hinweg koordiniert werden, und die Berechtigungen des Kontos driften zur Vereinigungsmenge von allem, was irgendein Agent jemals gebraucht hat. Das anonymisierte Beispiel dort ähnelt Fällen, die ich von Kundenteams gehört habe: Ein Support-Agent lief drei Monate lang unter einem Konto mit Leserechten für die gesamte Kundendatenbank, so während der Entwicklung berechtigt und vor dem Go-live nie eingeschränkt.

Agenten sind kurzlebig, Schlüssel nicht. Ein agentischer Workflow kann sich innerhalb von Sekunden bei einem Modellanbieter, einem Vektorspeicher, drei APIs und einem Cloud-Speicher authentifizieren und danach verschwinden. Langlebige API-Schlüssel setzen einen dauerhaften Aufrufer voraus, bei dem eine Rotation nach Zeitplan sinnvoll ist. Die Fehlanpassung erzeugt Wildwuchs: Schlüssel werden für Agenten erstellt, an die sich niemand mehr erinnert, und bleiben trotzdem gültig und breit berechtigt.

Delegation bricht die "im Auftrag von"-Kette. Ein Agent, der für einen Nutzer handelt, und ein Agent, der autonom handelt, sollten für Ihre Policy Engine völlig unterschiedlich aussehen. Mit einem gemeinsamen Servicekonto sehen sie identisch aus. OAuth-Delegation löst den Nutzerfall recht ordentlich. Der autonome Fall braucht die eigene Identität des Agenten, und bei Multi-Agent-Delegation muss jeder Hop die weitergegebene Berechtigung einengen, nicht erweitern.

Das Modell darf das Geheimnis niemals besitzen. Das ist ein strukturelles und kein Konfigurationsproblem. Zugangsdaten, die in das Kontextfenster gegeben werden, sind für das Modell und für alles sichtbar, was es manipulieren kann. Prompt Injection kann sie über die eigenen Ausgaben des Agenten exfiltrieren. Die Lösung sind kurzlebige, begrenzte Zugangsdaten, die zur Laufzeit von einem Token-Dienst ausgegeben und von der Tool-Ausführungsschicht gehalten werden. So löst das Modell Aufrufe aus, ohne dass das Geheimnis jemals in seinen Kontext gelangt. Cockroach Labs beschreibt diesen Punkt gut, und er entspricht dem, was ich Kunden sage, die auf selbst gehosteten Agenten-Stacks bauen: Der Harness hält die Schlüssel, das Modell hält die Absicht.

Gemeinsam genutzte Servicekonten zerstören die Zuordnung von Agentenaktionen, weil nur ein Akteur in den Logs erscheint, überleben kurzlebige Agenten-Workloads, verwischen die Grenze zwischen nutzerdelegierten und autonomen Aktionen und verleiten Teams dazu, Zugangsdaten durch den Modellkontext zu schicken, wo Prompt Injection sie erreichen kann, laut Cockroach Labs und miniOranges Vergleich.

Was Anbieter und Standardisierungsgremien bauen

Die entstehende Architektur hat drei Ebenen. Ermutigend ist, dass Anbieter und Standardisierungsexperten grob auf dasselbe Modell zulaufen.

Workload-Identität pro Agent. Die oben beschriebene WIMSE-Richtung ist die Standardisierungsvariante: Jeder logische Agent erhält eine eindeutige, stabile Kennung, vorgeschlagen ist eine SPIFFE-URI, getrennt von jeder gemeinsamen Ausführungsrolle. Diese Kennung wird zum Schlüssel für Richtlinien, Audit und Widerruf. Von Plattformen verwaltete Agenten, die gemeinsame Ausführungszugangsdaten nutzen, müssten diese um einen agentenspezifischen Claim ergänzen. Das ist die wichtigste Verschiebung: Identität pro Agent, nicht pro Deployment.

Föderation statt gespeicherter Geheimnisse. Descopes Einführung in Workload Identity Federation für Agenten zeigt das Muster: Die Plattformidentität des Agenten, etwa eine AWS-IAM-Rolle oder ein Kubernetes-Servicekonto über IRSA, wird gegen ein begrenztes, kurzlebiges Token der Identity-Plattform eingetauscht. Diese legt außerdem einen Verzeichniseintrag für den Agenten an, damit Audit-Trails länger bestehen als das Token selbst. Es gibt keinen langlebigen Schlüssel, der geleakt werden kann, und der Identitätseintrag überlebt jede einzelne Zugangsdateninstanz.

Discovery und Governance als Markt. Auf der kommerziellen Seite positionieren sich Anbieter für nicht-menschliche Identitäten wie Reco, Token Security, Oasis, Aembit und andere rund um Agenten neu: jede Agentenzugangsdatenquelle entdecken, einem Verantwortlichen zuordnen, Überprivilegierung markieren und sauber widerrufen. Recos Einordnung ist praktisch: Den Identitätstyp an die Rolle des Agenten anpassen, also delegiertes OAuth für Nutzeraktionen und dedizierte Workload-Identität für autonome Aktionen, und Berechtigungen mit wachsenden Verantwortlichkeiten überprüfen, weil Agenten Privilegien ansammeln wie Mitarbeitende Gebäudeschlüssel. OWASP nennt in den im Dezember 2025 veröffentlichten Top 10 for Agentic Applications Identity and Privilege Abuse als eigenständige Risikokategorie. Damit bekommen Sicherheitsteams ein gemeinsames Vokabular für Audit-Feststellungen. Wo diese Ebene in Ihrem weiteren Stack landet, ist ebenso eine Governance- wie eine Tooling-Frage. Die organisatorische Seite behandle ich in AI Agent Governance.

Die entstehende Architektur: Workload-Identitäten pro Agent, mit SPIFFE-artigen Kennungen als Schlüssel für Richtlinien, Audit und Widerruf laut WIMSE-Diskussion, Föderation von Plattformidentität in kurzlebige, eingeschränkte Tokens mit dauerhaften Verzeichniseinträgen für Agenten laut Descope und ein Anbietermarkt für Discovery und Least-Privilege-Governance nicht-menschlicher Identitäten.

Wenn Agentenidentität schiefläuft

Drei Vorfälle, drei unterschiedliche Fehlermuster, alle lehrreich.

Hugging Face, Juli 2026: Das Identitätsproblem des Angreifers war zugleich das des Verteidigers. Der von einem Agenten durchgeführte Einbruch erbeutete Cloud- und Cluster-Zugangsdaten aus einem Code-Execution-Worker und bewegte sich lateral weiter. Das ist die klassische Geschichte eines überprivilegierten Workloads: Eine Datenverarbeitungskomponente hielt Zugangsdaten, die es sich zu stehlen lohnte. Weniger berichtet wurde die von Hugging Face offengelegte forensische Asymmetrie: Der angreifende Agent war an keinerlei Nutzungsrichtlinie gebunden, während die eigene Forensik des Unternehmens zunächst von den Schutzmechanismen der getesteten gehosteten Modelle blockiert wurde. Deshalb führten sie die Analyse mit einem Open-Weight-Modell, GLM 5.2, auf eigener Infrastruktur durch. Identitäts- und Zugriffsfehler auf beiden Seiten desselben Vorfalls.

Salesloft Drift, die DBIR-Warnung: Tokens als Generalschlüssel. Kompromittierte OAuth-Tokens aus dem Ökosystem eines Anbieters wurden genutzt, um in die Salesforce-Umgebungen großer Unternehmen vorzudringen. Keine Passwörter, kein Phishing von Menschen: nicht-menschliche Zugangsdaten, breit vertraut und still weiterverwendet. Jeder Agent, den Sie mit einem langlebigen OAuth-Grant an ein SaaS-Tool anbinden, trägt genau diese Risikostruktur. Die Gegenmaßnahme hat dieselbe Form: kurzlebig, eng begrenzt, pro Agent und widerrufbar.

Moltbook, Januar 2026: Agentenplattformen bündeln Identitätsrisiko. Eine Plattform für Agentenkonten verlor aus einer falsch konfigurierten Datenbank 1,5 Millionen API-Tokens sowie E-Mail-Adressen und Nachrichten zwischen Agenten, laut Studio Globals Darstellung. Wer Agentenidentität zentralisiert, zentralisiert auch ihren möglichen Schadensradius. Einige der kursierenden Vorfalldetails würde ich als berichtet und nicht als auditiert behandeln: Die Hugging-Face-Offenlegung selbst ist eine Primärquelle, die Moltbook-Zahlen stammen aus Sekundärberichterstattung.

Dokumentierte Fehler rund um Agentenidentität umfassen den Hugging-Face-Vorfall im Juli 2026, bei dem ein autonomer Agent Cloud- und Cluster-Zugangsdaten erbeutete und sich lateral bewegte, laut Waxells Analyse, den Salesloft-Drift-OAuth-Token-Pivot in Salesforce-Tenants von Unternehmen, laut Token Security zum DBIR 2026, sowie das Moltbook-Leak von 1,5 Millionen Agenten-API-Tokens.

Was Sie jetzt tun sollten

1. Diese Woche: Inventarisieren Sie die Zugangsdaten Ihrer Agenten und wenden Sie den Zuordnungstest an. Nehmen Sie eine beliebige Agentenaktion aus Ihren Logs und fragen Sie, ob Sie erkennen können, welcher Agent sie ausgeführt hat, in wessen Auftrag und ob Sie nur diesen Agenten widerrufen könnten, ohne die anderen zu berühren. Wenn die Antwort nein lautet, haben Sie ein Problem mit gemeinsamer Identität. Das ist der erste Befund, den Sie beheben sollten.

2. Diesen Monat: Migrieren Sie einen autonomen Agenten von langlebigen Zugangsdaten auf kurzlebige, aufgabenbezogene Tokens, die von einem Token-Dienst oder einer Identity-Plattform ausgegeben, in der Tool-Ausführungsschicht gehalten und niemals in den Modellkontext gegeben werden. Beginnen Sie mit dem Agenten mit dem breitesten Zugriff. Das ist meistens der, den jemand in Eile "vorübergehend" zu großzügig berechtigt hat.

3. Dieses Quartal: Geben Sie jedem logischen Agenten eine eigene stabile Identität, eine SPIFFE-ID, wo Sie die Infrastruktur dafür haben, andernfalls ein eindeutiges Servicekonto pro Agent. Richten Sie Audit und Alerting darauf aus und schreiben Sie das Widerrufs-Runbook, bevor Sie es brauchen. Wenn Sie noch früher auf der Reise sind und erst entscheiden, wo Agenten überhaupt laufen sollen, bestimmt die Abwägung lokale versus Cloud-Agenten, wie viel davon Sie selbst kontrollieren können.

FAQ

Was ist Agentenidentität in IAM-Begriffen?

Eine eigene, überprüfbare Identität, die einem einzelnen KI-Agenten zugewiesen wird, getrennt von der Plattform, auf der er läuft, und von den Nutzern, für die er handelt. Sie dient als stabiler Schlüssel für Authentifizierung, Autorisierungsrichtlinien, Audit-Trails und Widerruf, ähnlich wie eine Workload-Identität einen Microservice identifiziert, aber angepasst an Aufrufer, die kurzlebig, nicht deterministisch und zur gegenseitigen Delegation fähig sind.

Warum können Agenten nicht einfach ein Servicekonto teilen?

Technisch können sie das, und die meisten tun es heute. Die Fehler sind: Audit-Logs zeigen das gemeinsame Konto statt des handelnden Agenten, wodurch die Zuordnung verloren geht; die Berechtigungen des Kontos wachsen zur Vereinigungsmenge der Anforderungen aller Agenten; der Widerruf eines Agenten bedeutet, die Zugangsdaten für alle zu rotieren; und nutzerdelegierte Aktionen lassen sich nicht von autonomen unterscheiden. Es funktioniert bis zum ersten Vorfall. Danach können Sie nicht mehr rekonstruieren, was passiert ist.

Was tun Standardisierungsgremien zur Agentenidentität?

Die IETF-WIMSE-Arbeitsgruppe erweitert die Workload-Identity-Architektur auf KI-Vermittler. Ein aktiver Vorschlag verlangt agentenspezifische Kennungen, wobei SPIFFE-URIs als Mechanismus vorgeschlagen werden, statt sich auf Token-Scopes zu verlassen. OWASP veröffentlichte im Dezember 2025 die Top 10 for Agentic Applications und nannte Identity and Privilege Abuse als eigene Kategorie. Die Cloud Security Alliance hat zudem ein Governance-Framework für Agentenidentitäten, das eine eindeutige Identität pro Agent empfiehlt.

Sollten Agentenzugangsdaten jemals im Modellkontext erscheinen?

Nein. Alles im Kontextfenster ist für das Modell sichtbar und durch Prompt Injection exfiltrierbar. Das akzeptierte Muster sind Zugangsdaten, die zur Laufzeit von einem Token-Dienst ausgegeben, von der Tool-Ausführungsschicht zwischen Modell und API gehalten, auf die Aufgabe begrenzt und kurzlebig sind. Das Modell fordert die Aktion an, der Harness hält das Geheimnis.

Fazit

In der Identity-Welt heißt es, Identität sei die Control Plane, und Agenten werden diese Aussage härter testen als Microservices es je getan haben. Die Richtung ist klar genug, um heute darauf hinzuarbeiten: Identität pro Agent, Geheimnisse außerhalb des Modells, Tokens, die schneller ablaufen als sich Vorfälle ausbreiten, und Audits, die "welcher Agent, in wessen Auftrag, mit welchem Ziel" beantworten können. Die Organisationen, die diesen Sommer getroffen wurden, betrieben keine exotischen Setups. Sie nutzten gemeinsame Zugangsdaten und hofften. Diese Lücke muss geschlossen werden, und sie lässt sich mit Technologie schließen, die größtenteils bereits existiert.

Wenn Sie Agentenidentität auf eine bestehende IAM-Landschaft abbilden und einen Praktiker mit am Tisch haben möchten, ist das eine Art von Arbeit, die ich mache. Kontakt aufnehmen.

Quellen

• IETF WIMSE WG, draft-ietf-wimse-arch Issue #139, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (eingereicht 2026-08-04, abgerufen 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (veröffentlicht 2026-07-17, abgerufen 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (veröffentlicht 2026-05-20, abgerufen 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (veröffentlicht 2026-06-22, abgerufen 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (veröffentlicht 2026-05-20, abgerufen 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (veröffentlicht 2026-07-20, abgerufen 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (veröffentlicht 2026-07-17, abgerufen 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (veröffentlicht 2026-08-17, abgerufen 2026-08-29)