Ein KI-Agent kann eine Rechnung lesen, einen Termin vorbereiten oder ein Ticket schließen. Aber wer handelt dabei eigentlich? Der angemeldete Mensch, eine technische Anwendung oder eine eigenständige Agentenidentität? Diese Entscheidung bestimmt, welche Daten der Agent sieht, welche Aktionen er ausführen darf und wem sie später zugerechnet werden.
Bei klassischen Anwendungen ist die Trennung vertraut: Ein Benutzer meldet sich an, ein Backend besitzt eine technische Identität, und Berechtigungen werden an Rollen gebunden. Ein Agent macht diese Architektur nicht überflüssig. Er verschärft sie. Denn er wählt Werkzeuge und Handlungsschritte teilweise selbst. Eine zu breite Berechtigung wird dadurch nicht nur missbraucht, sondern kann auch durch eine falsche Interpretation, manipulierten Kontext oder einen fehlerhaften Plan aktiviert werden.
Meine Kernthese: Ein Agent sollte nie „die Rechte bekommen, die er vermutlich braucht“. Er braucht eine eindeutig erkennbare Identität und genau die Rechte, die für den aktuellen Auftrag, das konkrete Werkzeug und die zulässige Wirkung erforderlich sind.
Drei Identitäten statt eines Service Accounts
Der Begriff „Service Account“ ist im Alltag bequem, aber architektonisch zu ungenau. Er kann ein gemeinsam genutztes Benutzerkonto, einen Service Principal, eine Managed Identity oder eine andere Maschinenidentität meinen. Für Agenten sollten diese Varianten nicht vermischt werden. Entscheidend ist, in wessen Auftrag eine Aktion stattfindet.
Das wichtigste Auswahlkriterium ist nicht die technische Bequemlichkeit, sondern die fachliche Verantwortung. Wenn André den Agenten bittet, seine eigenen Termine zu lesen, ist Delegation plausibel. Wenn ein Nachtlauf alle offenen Supportfälle klassifiziert, braucht der Prozess eine eigene Workload Identity. Wenn viele dynamisch erzeugte Agenten autonom auftreten, reicht ein gemeinsamer Service Principal kaum noch aus: Aktivitäten, Lifecycle und Verantwortlichkeit müssen pro Agent oder Agententyp sichtbar werden.
Delegierte Rechte: Der Benutzer bleibt die Grenze
Beim delegierten Zugriff handelt der Agent mit Rechten, die ein Benutzer besitzt und der Anwendung erteilt wurden. Im Microsoft Identity Platform On-Behalf-Of Flow wird die Identität des Benutzers durch eine API-Kette weitergereicht. Die mittlere API erhält für den Downstream-Dienst delegierte Scopes – nicht einfach pauschale Application Roles.
Das ist für persönliche Assistenz ein starkes Modell: Der Agent kann grundsätzlich nur sehen, was der Benutzer sehen darf. Trotzdem ist „on behalf of“ keine Vollmacht für jede Aktion. Ein Agent, der einen Kalender lesen darf, muss nicht automatisch Termine absagen dürfen. Ein Agent, der Dokumente analysiert, braucht nicht automatisch Schreibzugriff auf die gesamte Bibliothek.
Ich würde delegierte Berechtigungen deshalb entlang der Wirkung schneiden: Lesen, Entwurf erzeugen, Änderung vorbereiten und Änderung ausführen sind vier verschiedene Fähigkeiten. Besonders irreversible Aktionen sollten eine zusätzliche fachliche Freigabe verlangen, selbst wenn der OAuth-Token die technische Berechtigung bereits enthält.
Autonome Agenten brauchen eigene Rechte
Ein Agent, der ohne angemeldeten Benutzer arbeitet, benötigt eine Maschinenidentität. In Microsoft Entra sind Anwendungen, Service Principals und Managed Identities etablierte Workload Identities. Eine Managed Identity hat einen entscheidenden Vorteil: Auf Azure muss kein Client Secret im Code oder in einer Konfigurationsdatei verwaltet werden. Die Plattform stellt Tokens für die Identität bereit.
Das macht die Identität sicherer, aber nicht automatisch die Berechtigung. Eine secretlose Identität mit zu breiten Rollen bleibt zu mächtig. Deshalb sollte ein Agent nicht mit einem zentralen „AI-Service-Account“ für alle Prozesse arbeiten. Besser sind fachlich getrennte Identitäten: ein Agent für Angebotsentwürfe, einer für Supportklassifikation und einer für Deployment-Status. Ein kompromittierter oder fehlgeleiteter Agent kann dann nicht ohne Weiteres in eine andere Domäne wechseln.
Wo Azure Managed Identities nicht verfügbar sind, ist Workload Identity Federation meist stärker als ein langlebiges Secret. Zertifikate sind ebenfalls besser kontrollierbar als Passwörter. Statische Client Secrets sollten die Ausnahme sein, kurz leben, sicher gespeichert und rotierbar bleiben.
Agent Identity: eine neue, sinnvolle Kategorie
Microsoft Entra Agent ID trennt Agenten zunehmend von klassischen Anwendungen. Eine Agentenidentität ist dort ein besonderer Service Principal, der über ein Blueprint-Modell erzeugt wird. Der Blueprint bündelt gemeinsame Eigenschaften und Berechtigungen eines Agententyps; einzelne Agenten erhalten eine eigene Identität. Ein Sponsor dokumentiert, welcher Mensch oder welche Gruppe verantwortlich ist.
Das ist mehr als neue Terminologie. Agenten können dynamischer und kurzlebiger sein als klassische Enterprise-Anwendungen. Ein Agent kann für einen einzelnen Auftrag entstehen, viele Werkzeuge koordinieren und danach wieder verschwinden. Werden solche Instanzen alle durch denselben Service Principal repräsentiert, verliert das Unternehmen genau die Information, die für Audit, Incident Response und Lifecycle wichtig ist: Welcher Agent hat gehandelt?
Gleichzeitig ist die Technologie noch Preview. Ich würde sie daher nicht als allgemeine Voraussetzung formulieren. Die Architekturidee ist aber bereits richtig: Agenten sollten erkennbar, einem Verantwortlichen zugeordnet, gruppenweise steuerbar und sauber deaktivierbar sein. Bis spezialisierte Agentenidentitäten im eigenen Zielsystem belastbar verfügbar sind, müssen getrennte Workload Identities, eindeutige Run-IDs und vollständige Audit-Logs diese Aufgabe übernehmen.
Zero Trust beginnt nach der Anmeldung
Die drei Zero-Trust-Prinzipien von Microsoft sind für Agenten besonders passend: explizit prüfen, mit geringstmöglichen Rechten arbeiten und von einer Kompromittierung ausgehen. Ein gültiger Token beantwortet nur die Frage, ob eine Identität authentifiziert wurde. Er beweist nicht, dass die geplante Aktion fachlich richtig ist.
Für einen produktiven Agenten würde ich deshalb mehrere Grenzen kombinieren:
Meine Entscheidungsregel für die Praxis
Ich würde mit einer einfachen Frage beginnen: Wessen fachliche Verantwortung wird durch diese Aktion ausgeübt? Ist es eine persönliche Handlung, sollte der Agent delegiert und im klaren Benutzerkontext arbeiten. Ist es ein definierter Unternehmensprozess, braucht er eine eigene Workload Identity mit engem fachlichem Zuschnitt. Ist der Agent selbst ein verwaltetes Objekt mit eigenem Lifecycle, dynamischen Instanzen oder autonomer Verantwortung, wird eine echte Agentenidentität sinnvoll.
Danach folgen fünf Architekturfragen: Welche Ressource ist nötig? Welche kleinste Aktion reicht? Wie lange muss der Zugriff gelten? Wer genehmigt eine riskante Wirkung? Und wie lässt sich im Nachhinein beweisen, welche Identität welchen Schritt ausgelöst hat? Wenn eine dieser Fragen offenbleibt, ist der Agent noch nicht bereit für mehr Autonomie.
Praktische Leitlinie: Erst Identität, dann Berechtigung, dann Tool. Nicht umgekehrt. Ein Agent sollte niemals durch ein mächtiges Tool indirekt mehr dürfen, als seine Identität im Zielsystem ausdrücklich erlaubt.
Mein Fazit
Die Identität eines KI-Agenten ist keine technische Randfrage. Sie ist die Verbindung zwischen Autonomie und Verantwortung. Delegierte Rechte sind richtig, wenn ein Agent einen Menschen bei dessen eigener Arbeit unterstützt. Workload Identities sind richtig, wenn ein klar definierter Prozess autonom läuft. Spezialisierte Agentenidentitäten werden wichtig, wenn Agenten selbst zu verwalteten, sichtbaren und kurzlebigen Akteuren im Unternehmen werden.
Zero Trust bedeutet dabei nicht, Agenten grundsätzlich zu misstrauen. Es bedeutet, Vertrauen nicht aus einem erfolgreichen Login abzuleiten. Jeder Zugriff braucht einen Zweck, eine enge Berechtigung, eine fachliche Grenze und eine nachvollziehbare Identität. Erst dann kann ein Agent mehr tun als antworten, ohne dass Kontrolle und Verantwortlichkeit verschwinden.
Weiterführende Quellen
- Microsoft Learn: What are agent identities? zur Abgrenzung von Agenten-, Anwendungs- und Benutzeridentitäten.
- Microsoft Learn: Agent identities in Microsoft Entra Agent ID zu Blueprints, Sponsor, Tokens und Lifecycle. Microsoft kennzeichnet die Funktion aktuell als Preview.
- Microsoft Learn: Authorization in Microsoft Entra Agent ID zu Least Privilege und eingeschränkten Hochprivilegien.
- Microsoft Learn: What are workload identities? zu Anwendungen, Service Principals, Managed Identities und Federation.
- Microsoft Learn: OAuth 2.0 On-Behalf-Of flow zum delegierten Zugriff über eine API-Kette.
- Microsoft Learn: Zero Trust security guidance zu expliziter Prüfung, geringstmöglichen Rechten und Assume Breach.