KI-Agenten sind Identitäten: Least Privilege für Nicht-Menschen

Zwei Jahre lang haben die meisten Teams einen KI-Agenten als Feature einer Anwendung behandelt. Er rief Tools mit der gerade bequemsten Credential auf: dem persönlichen Access Token des Entwicklers, einem geteilten Service-Account, einem API-Key in einer Umgebungsvariable. Im Demo funktionierte das. Die erste Audit-Frage übersteht es nicht, und die lautet immer gleich: Wer hat das getan, und wer hat es erlaubt?

Ein Agent, der Mails liest, Tickets anlegt oder Datensätze ändert, ist ein Nutzer deiner Systeme, nur sehr schnell und sehr wörtlich. Dieser Artikel behandelt Agenten als Identitäten und geht die Entscheidungen durch, die daraus folgen: delegierte oder eigene Zugangsdaten, OAuth Token Exchange, kurzlebige Tokens mit engem Scope, Secrets, Audit und Offboarding. Ich habe außerdem geprüft, was die Anbieter im Oktober 2026 tatsächlich liefern, denn mehrere Ankündigungen wurden im Sommer zu allgemein verfügbaren Produkten.

Warum ein Agent eine eigene Identität braucht

Anwendungsidentitäten wurden für Dienste gebaut, die Menschen entwickeln, benennen und jahrelang betreiben. Menschliche Identitäten kommen mit Passwort, MFA und Vorgesetztem. Ein Agent ist weder das eine noch das andere. Microsofts Dokumentation beschreibt Agenten, die Minuten existieren oder tausendfach pro Tag erzeugt und zerstört werden, und nennt die Probleme, die eine Agenten-Identität lösen soll: Agenten-Aktionen von denen der Mitarbeiter, Kunden und Workloads unterscheiden, passend dimensionierten Zugriff geben, Agenten von den kritischsten Rollen fernhalten und für große, kurzlebige Flotten skalieren.

Das praktische Argument ist einfacher. Ohne eigene Identität kannst du drei Fragen nicht beantworten: Was erreicht dieser Agent, was hat er getan, und wie stoppe ich ihn, ohne das Konto eines Kollegen zu beschädigen? Ein geteiltes Token scheitert an allen dreien. Liest der Agent außerdem nicht vertrauenswürdige Inhalte, was die meisten nützlichen Agenten tun, bestimmen seine Rechte den Schadensradius einer erfolgreichen Prompt Injection (siehe die Muster der Lethal Trifecta). An der Identität hängst du diese Grenze auf.

Delegiert oder eigene Zugangsdaten: pro Aufgabe wählen

Ein Agent kann sich auf drei Arten authentifizieren, und nur zwei davon sind gut. Entra Agent ID benennt die guten ausdrücklich: autonomer Zugriff mit Rechten, die direkt der Agenten-Identität gegeben sind, und delegierter Zugriff, bei dem der Agent im Namen eines Menschen mit dessen Rechten handelt und der Nutzer kontrolliert, was delegiert wird.

Meine Regel: Wenn die Arbeit für jemanden ist, etwa „fasse mein Postfach zusammen“ oder „bereite mein Angebot vor“, nutze delegierten Zugriff, damit der Agent die Grenzen dieser Person erbt und deine bestehenden Zugriffsrichtlinien weiter greifen. Wenn die Arbeit vom Agenten als Rolle erledigt wird, etwa nächtlicher Abgleich oder eine Support-Triage-Queue, gib ihm eine eigene Identität mit den kleinsten App-Berechtigungen, die du vertreten kannst. Microsofts Best-Practice-Leitfaden sagt dasselbe: Client Credentials nur mit den nötigen App-Berechtigungen für autonome Agenten, On-Behalf-Of für interaktive, und keine App-Berechtigungen, wo delegierte genügen.

Eine Folge übersieht man leicht. Ein delegiertes Token ist durch den Nutzer begrenzt, und ein Nutzer ist oft Administrator. Delegation hilft nicht, wenn die Person dahinter überprivilegiert ist, deshalb muss auch der eigene Scope des Agenten gedeckelt sein, und die effektiven Rechte sind die Schnittmenge beider.

Der delegierte Token-Fluss

Der Standardmechanismus ist OAuth 2.0 Token Exchange, RFC 8693. Ein Client sendet ein Subject Token (für wen die Anfrage ist) und optional ein Actor Token (wer handelt), zusammen mit gewünschter Audience und Scope. Ohne Actor Token entsteht Impersonation: Der Agent wird einfach zum Nutzer, und niemand kann beide unterscheiden. Mit Actor Token entsteht Delegation: Der Agent behält seine eigene Identität, und das neue Token hält fest, dass er für den Nutzer handelt.

In den Schritten 3 und 4 ist der Identity Provider der Policy-Punkt. Er kann den Tausch verweigern, wenn der Agent gesperrt ist, der Nutzer nicht eingewilligt hat oder der angeforderte Scope weiter ist als erlaubt, und er kann eine kurze Laufzeit setzen. Weil das neue Token die API als Audience hat, ist eine geleakte Kopie anderswo wertlos. Der act-Claim reist dann zum Resource Server und in dessen Logs, wodurch sich „der Nutzer war es“ und „der Agent war es für den Nutzer“ später unterscheiden lassen.

Kenne die Grenzen des Standards. RFC 8693 lässt act-Claims verschachteln, um eine Kette von Akteuren zu beschreiben, aber ein Empfänger soll nur den Top-Level-Claims vertrauen, frühere Akteure sind informativ. Nichts darin zwingt dazu, dass Berechtigungen bei jedem Hop schrumpfen. WorkOS beschreibt das als Multi-Hop-Delegationsproblem und verweist auf Entwürfe zu abschwächenden Tokens und verifizierbaren Actor-Ketten. Bis diese reifen, halte Ketten kurz, verenge den Scope bei jedem Tausch und ergänze eine Policy-Prüfung beim Tool-Aufruf, statt dich allein auf die Gültigkeit des Tokens zu verlassen.

Die Enterprise-Variante derselben Idee heißt Cross App Access. Der Nutzer meldet sich beim Unternehmens-Identity-Provider an, der eine Identity Assertion JWT Authorization Grant (ID-JAG) ausstellt; der Client tauscht sie am Authorization Server des Zielservices gegen ein Access Token. Admins aktivieren einen Server einmal, und Nutzer erben ihn innerhalb ihrer bestehenden Gruppen und Rollen, ohne Einwilligungsdialog pro Server. Das MCP-Projekt hat es am 18. Juni 2026 als Enterprise-Managed-Authorization-Erweiterung übernommen.

Secrets: Die beste Credential ist die, die du nicht speicherst

Ein Agent hat zwei Arten von Secrets: die Credential, mit der er beweist, wer er ist, und die Drittanbieter-Tokens, mit denen er in anderen Systemen handelt. Beide sind attraktive Ziele, weil Agenten Code ausführen, nicht vertrauenswürdige Eingaben lesen und Logs schreiben. Ich würde diese Regeln anwenden.

• Keine statischen Keys für Produktions-Agenten. Entras Leitfaden bevorzugt föderierte Identity Credentials (Managed Identities) oder Zertifikate gegenüber Client Secrets, Secrets nur für die Entwicklung und Zertifikatsrotation mindestens jährlich. Oktas Agent SSO stellt ebenso kurzlebige, identitätsgesteuerte Tokens statt statischer API-Keys aus.
• Halte Credentials außerhalb der Reichweite des Modells. Der Agent-Prozess fragt einen Sidecar, Vault oder Broker nach einem Token; das Modell sieht das Secret nie in Prompt, Tool-Argumenten oder Tool-Ergebnissen. Entra bietet dafür ein Auth-SDK als Sidecar, auch für Agenten auf AWS Bedrock oder n8n.
• Eine Credential pro Blueprint und Umgebung. Teile keine Credential zwischen nicht verwandten Agenten und trenne Dev, Test und Prod, damit eine Kompromittierung lokal bleibt.
• Halte Drittanbieter-Tokens in einem Token Vault, pro Kunde oder Mandant, und gib sie dem Agenten nur über einen begrenzten, protokollierten Aufruf frei. Auth0 hat einen Token Vault mit Organizations-Unterstützung für Multi-Tenant-SaaS angekündigt.
• Bereinige Logs und Traces. Tokens lecken über Debug-Logs, Fehlermeldungen und Observability-Pipelines; schwärze Authorization-Header, bevor sie den Prozess verlassen. Zur Laufzeitseite siehe die Sandboxing-Checkliste.

Kurze Laufzeiten zählen mehr als clevere Speicherung. Ein schnell ablaufendes Token macht aus einem Leak eine Fußnote statt eines Vorfalls, und der Rat zur Scope-Minimierung aus den MCP-Richtlinien gilt direkt: mit risikoarmen Lese-Scopes starten und erst bei einer privilegierten Operation erhöhen, statt alle Scopes vorab zu veröffentlichen.

Was die Anbieter im Oktober 2026 liefern

Geprüft gegen Herstellerdokumentation und Ankündigungen, ist das der aktuelle Stand. Das Feld bewegt sich schnell, also prüfe Daten und Lizenzen, bevor du auf eine Zeile planst.

Zwei Beobachtungen. Erstens sind die Protokolle schneller zusammengewachsen als erwartet: Entra, Okta und das MCP-Projekt beschreiben dieselbe Form, nämlich eine Verzeichnisidentität für den Agenten, Token-Ausstellung beim Identity Provider und kurzlebige Tokens mit engem Scope an der Ressource. Zweitens ist die kommerzielle Grenze real. Microsoft trennt die Identitätsplattform von den Governance-Funktionen, und Okta trennt Single Sign-on von Lifecycle-Governance. Plane Budget für die Governance-Schicht ein, denn Identität ohne Review und Lifecycle ist nur ein anderer Ort, Agenten zu vergessen. In einem eigenen Artikel habe ich beschrieben, warum OpenAIs Dots Agenten-Governance zur Identitätsfrage machen.

Audit und Offboarding

Jede Aktion zurechenbar machen

Logging nützt nur, wenn das Log Agenten von Menschen unterscheiden und den Menschen hinter einer delegierten Aktion benennen kann. Entra markiert Audit-Ereignisse mit einem Agent-Typ (Blueprint, Agenten-Identität oder Agent-User-Konto) und der Blueprint-ID und ergänzt einen Agent-Sign-in-Ereignistyp. Weil sich Agenten mit delegierten oder reinen App-Berechtigungen anmelden können, erscheinen ihre Anmeldungen in allen vier Sign-in-Log-Typen, also filtere nach Agent-Typ statt nach einem einzelnen Log.

• Logge bei jedem delegierten Aufruf Subject und Actor, bei autonomen nur die Agenten-Identität.
• Alarmiere bei Credential-Änderungen, neuen Berechtigungen, Anmeldungen von unbekannten Orten und bei Änderungen außerhalb deiner Deployment-Pipeline.
• Verknüpfe die Agenten-Identität mit der Run-ID in deinen Traces, damit du nachvollziehen kannst, was eine Identität über eine ganze Agent-Schleife getan hat.
• Halte die Aufbewahrung lang genug für dein Compliance-Regime; Agenten-Logs haben hohes Volumen, also exportiere sie in ein Archiv.

Agenten wie Mitarbeiter offboarden

Agenten sind leicht erzeugt und ebenso leicht vergessen. Entras Modell zeigt, wie ein guter Lebenszyklus aussieht. Jeder Blueprint und jede Agenten-Identität braucht einen Sponsor, die Person oder Gruppe, die für den Zweck verantwortlich ist, plus einen technischen Owner. Lifecycle-Workflows können Co-Sponsoren benachrichtigen und die Sponsorschaft automatisch übertragen, wenn ein Sponsor die Rolle wechselt oder geht, um verwaiste Agenten zu verhindern. Microsoft empfiehlt, dass Sponsoren alle 6 bis 12 Monate bestätigen, dass ein Agent noch gebraucht wird, und dass du vierteljährlich auf fehlende Sponsoren und Agenten ohne jüngste Aktivität prüfst.

Trenne beim Abschalten Deaktivieren von Löschen. Das Deaktivieren eines Blueprints stoppt sofort die Authentifizierung aller seiner Agenten-Identitäten, was ihn zum Kill Switch macht, und lässt die Beweise stehen. Das Löschen löscht das Objekt vorläufig (Soft Delete) und asynchron seine untergeordneten Identitäten; die Bereinigung kann Stunden oder Tage dauern, und Objekte sind 30 Tage wiederherstellbar. Verlass dich im Notfall nicht aufs Löschen; deaktiviere zuerst. Danach kommt, was kein Verzeichnis für dich erledigt: Widerrufe Tokens, die der Agent in Drittsystemen hält, entferne seine Secrets und seine Einträge in Vaults und schließe seine Verbindungen zu externen Diensten.

Kontroll-Checkliste

Nutze diese Tabelle in Design-Reviews. Jede Kontrolle hat einen konkreten Test; kannst du für eine Zeile keinen Nachweis zeigen, gilt sie als offen.

Zwei Zeilen verdienen eine Übung statt eines Dokuments: der Test mit verweigertem Scope und die Deaktivierung. Bitte einen Agenten, etwas außerhalb seines Scopes zu tun, und prüfe, dass es scheitert und der Fehlschlag geloggt wird. Tu dann so, als wäre er kompromittiert, und miss, wie lange es dauert, jede Credential zu kappen, die er hält.

Was ich zuerst tun würde

Du brauchst keinen Plattformkauf, um anzufangen. In dieser Reihenfolge:

1. Inventarisiere jeden Agenten und jede Automatisierung, die heute deine Systeme aufrufen, und markiere, welche ein persönliches Token oder einen geteilten Key nutzen.
2. Gib jedem Agenten eine eindeutige Identität und einen Sponsor, beginnend bei denen, die Kundendaten oder Geld berühren.
3. Entscheide pro Agent delegiert oder autonom und schneide Scopes auf das zu, was die Aufgabe braucht; teste, dass ein Aufruf außerhalb des Scopes scheitert.
4. Wechsle zu Token Exchange und kurzlebigen Tokens bei deinem Identity Provider; entferne statische Keys aus Produktion und aus Prompts.
5. Schreibe das Runbook für Deaktivieren und Widerrufen, übe es einmal und plane den vierteljährlichen Waisen-Review ein.

Agenten-Identität ist nicht glamourös, aber sie ist die Kontrolle, die alles andere durchsetzbar macht: Sandboxing begrenzt, was Code tun kann, und Identität begrenzt, was der Agent erreichen darf und wen du zur Verantwortung ziehen kannst.

Quellen

1. Microsoft Learn: What is Microsoft Entra Agent ID?
2. Microsoft Learn: What are agent identities?
3. Microsoft Learn: Best practices for Microsoft Entra Agent ID
4. Microsoft Learn: Microsoft Entra Agent ID logs
5. Microsoft Learn: How agent identity deletion works
6. Microsoft Learn: What's new in Microsoft Entra Agent ID
7. Microsoft Learn: Microsoft Agent 365 overview
8. Okta: Okta brings first-class identity to AI agents with Agent SSO (24 August 2026)
9. Okta: Auth0 gives developers the identity layer to securely ship agentic apps (May 2026)
10. IETF: RFC 8693, OAuth 2.0 Token Exchange
11. Model Context Protocol blog: Enterprise-Managed Authorization, zero-touch OAuth for MCP (18 June 2026)
12. Model Context Protocol: Security best practices
13. WorkOS: AI agents and the multi-hop delegation problem
14. TechCrunch: OpenAI launches Dots, its bubbly agentic avatar