Verstecken Sie einen autonomen Agenten nicht hinter den Zugangsdaten eines Menschen oder einem gemeinsam genutzten Service Account. Ein eingesetzter Agent braucht eine eigene Identität, einen klar verantwortlichen Sponsor, begrenzte Delegation, angemessen kurzlebigen Zugriff, nachvollziehbare Aktionen und Lifecycle-Kontrollen. Sonst weiß das Unternehmen womöglich, dass etwas gehandelt hat, kann aber nicht erklären, welcher Agent es war, in wessen Auftrag und mit welchen Berechtigungen.
Authentisierung und Autorisierung fallen dadurch nicht zusammen. Agenten machen ihre Beziehung jedoch schwerer erkennbar. Das System muss den Workload authentisieren, gegebenenfalls den delegierten Kontext eines Menschen oder Service erhalten, die konkrete Tool-Aktion autorisieren und genug Kontext protokollieren, um sie später untersuchen zu können.
Das Identitätsdesign ergibt sich aus dem Erkennungsproblem bei Shadow Agents, dem Betriebsmodell für agentische KI und den Eskalationsstufen einer Minimum-Viable-KI-Governance.
Die Verantwortungslücke in der Automatisierung
Wer Autorität an Software delegiert, delegiert damit nicht die Verantwortung. In einem menschlichen Prozess kann eine Führungskraft meist feststellen, wer eine Aufgabe freigegeben und wer sie ausgeführt hat. Ein agentischer Prozess muss diese Kette bewusst in Identitäten, Sponsorship, Freigaben und Logs verankern.
Ein Agent könnte eine Finanztransaktion ausführen, Produktionscode ändern oder auf sensible personenbezogene Daten zugreifen. Microsofts Entra-Ankündigungen vom November 2025 sind ein Marktsignal dafür, dass Agentenidentitäten bei Lifecycle und Zugriff als eigenständige Objekte behandelt werden müssen. Die nützliche Designfrage lautet nicht, ob Agenten bestehende Zero-Trust-Prinzipien ersetzen. Entscheidend ist, wie diese Prinzipien für einen Workload gelten, der zur Laufzeit zwischen Tools und Aktionen wählen kann.
Handelt ein Agent unter einem generischen Service Account, können Ermittler ihn möglicherweise nicht von anderer Automatisierung unterscheiden. Handelt er direkt mit den Zugangsdaten einer Person, kann das Protokoll fälschlich so aussehen, als hätte diese Person jede Aktion selbst ausgeführt. Ein Sponsor genehmigt nicht jede Laufzeitentscheidung. Er verantwortet aber Zweck, Grenzen und die fortdauernde Berechtigung zum Betrieb des Agenten.
Identität wird zum neuen Perimeter
Identität ist eine der wichtigsten Control Planes für Agenten, die über APIs und Umgebungen hinweg arbeiten. Die OWASP Top 10 for Agentic Applications führen den Missbrauch von Identitäten und Privilegien als veröffentlichtes Risiko. Deshalb sollte die Beziehung zwischen Agentenidentität, delegierter Autorität, Tool-Berechtigungen und Lifecycle vor dem Produktionseinsatz gestaltet werden.
Betrachten Sie den Lebenszyklus einer Agentenaktion. Er beginnt mit der Authentisierung: Das System weist nach, welcher Workload handelt und gegebenenfalls in wessen Namen. Bevorzugen Sie Credentials, deren Lebensdauer und Scope zur Aufgabe passen. Langlebige Secrets erhöhen die Persistenz nach einer Kompromittierung; extrem kurze Laufzeiten können Probleme für Zuverlässigkeit und Wiederherstellung verursachen. Die richtige Wahl hängt von der Aktion und der Identity-Plattform ab.
Hier treffen Performance und Security aufeinander. Kurzlebige Tokens verursachen Overhead, langlebige Tokens erhöhen das Risiko. Die Lösung liegt darin, Identity Checks in jeden Tool-Aufruf einzubauen. Bei jedem Aufruf einer externen API oder Zugriff auf eine Datenbank muss der Agent seinen konkreten Autorisierungsumfang nachweisen. So wird aus einem statischen Perimeter ein dynamischer Verifikationsprozess, der mit der Komplexität der Agentenoperationen skaliert.
Begrenzte Delegation und Least Privilege
Die zweite Säule ist begrenzte Delegation. Ein Agent sollte nur die Privilegien erhalten, die er für seine Aufgabe, deren Dauer und Kontext benötigt. Das ist der bekannte Zielkonflikt zwischen Least Privilege und Nutzbarkeit – dynamischer als bisher, weil ein Agent Tools auswählen und Aktionen zur Laufzeit anordnen kann.
Muss ein Agent Kundendaten lesen und Berichte schreiben, braucht er nicht zusätzlich die Berechtigung, Konten zu löschen oder Abrechnungsdaten zu verändern. Kopieren Sie nicht den gesamten Berechtigungssatz des Sponsors in langlebige Agenten-Credentials. Besser sind eine explizite, zeitlich begrenzte Delegation und Autorisierungsprüfungen, die Ressource, Aktion, Sponsor und Workflow-Kontext berücksichtigen.
Behandeln Sie Agenten als Workloads mit eigenen Zugriffsrichtlinien. RBAC kann weiterhin sinnvoll sein; Attribute, Ressourcenkontext, Aktionsrisiko und delegierter Benutzerkontext ermöglichen eine präzisere Autorisierung. Autorisieren Sie nicht anhand einer vom Modell selbst beschriebenen Absicht, sondern prüfen Sie die konkrete Tool-Operation gegen die Richtlinie.
Aktionsprovenienz und Nachvollziehbarkeit
Neben Authentisierung und Autorisierung brauchen wir einen Mechanismus, der erklärt, was nach der Entscheidung geschehen ist. Hier kommt die Aktionsprovenienz ins Spiel. Sie verbindet Input und Output des Agenten zu einer auditierbaren Spur, die beantwortet: Wer hat das angestoßen? Welche Daten wurden verwendet? Und warum ist es geschehen?
Logs sind häufig über Model Gateway, Orchestrator, Identity Provider, Tool und Zielsystem verteilt. Eine Untersuchung braucht eine Korrelations-ID und genug Kontext, um diese Einträge zu verbinden. Die internen Schlussfolgerungen eines Modells zu rekonstruieren ist weder immer möglich noch das Ziel. Rekonstruierbar sein müssen Anweisung, Identität, Autorisierung, Tool-Anfrage, Ergebnis und die daraus folgende Zustandsänderung.
Erfassen Sie Zeitstempel, Agentenidentität, Sponsor oder verantwortlichen Service, auslösende Anweisung oder Workflow-Referenz, delegierten Kontext, Autorisierungsentscheidung, Tool-Aktion, Ziel und Ergebnis. Schützen Sie sensible Prompt- und Dateninhalte im Log, statt sie wahllos zu kopieren. Ein Entzug kann künftigen Zugriff verhindern, aber keine irreversible Aktion rückgängig machen. Deshalb gehören Provenienz und begrenzte Autorität zusammen.
Sechs Tests für das Identitätsdesign
Prüfen Sie mit diesen sechs Tests, ob Ihre Organisation für agentische Workloads bereit ist. Wer einen davon nicht besteht, hat noch keinen ausreichenden Ansatz für autonome Systeme.
- Test auf eine eigene Identität: Hat jeder Agent eine eindeutige Identität, getrennt von Menschen und anderen Agenten?
- Test auf einen verantwortlichen Sponsor: Ist klar definiert, welcher Mensch oder welche Organisationseinheit die Aktionen und Ergebnisse des Agenten verantwortet?
- Test auf begrenzte Delegation: Kann der Agent ausschließlich auf Ressourcen zugreifen, die er für seine konkrete Aufgabe benötigt?
- Test auf kurzlebigen Zugriff: Passt die Lebensdauer der Credentials zur Aufgabe, und begrenzt sie die Persistenz nach einer Kompromittierung?
- Test auf Aktionsprovenienz: Können Ermittler Anweisung, Identität, Autorisierung, Tool-Aktion und die resultierende Änderung korrelieren?
- Test auf Lifecycle-Kontrolle: Sind Anlage, Verantwortungswechsel, Zugriffsprüfungen, Suspendierung und Stilllegung definiert und durchgesetzt?
Diese Tests machen aus „Agentenidentität“ mehr als ein Produktetikett: eine operative Fähigkeit. Identity-Teams, Application Owner, Security und Audit brauchen ein gemeinsames Design für Ausgabe, Delegation, Korrelation, Entzug und Evidenz. Automatisierung hilft beim Skalieren. Das Richtlinien- und Verantwortungsmodell muss jedoch verständlich sein, bevor es automatisiert wird.
Mit dem Agenten mit der größten Autorität beginnen
Erfassen Sie alle Agenten, die Geld, Produktion, Kundendaten, Identitäten oder regulierte Entscheidungen verändern können. Wählen Sie den Agenten mit dem größten Auswirkungsradius und führen Sie die sechs Tests durch. Die Lücken zeigen, ob die nächste Investition in Identity-Plattform, Agentendesign, Logging, Freigabepfad oder Lifecycle-Prozess gehört.
Tun Sie das, bevor Sie Agenten zählen. Zehn sauber begrenzte Agenten können leichter zu steuern sein als eine gemeinsam genutzte Automatisierungsidentität mit weitreichendem Zugriff und ohne Sponsor.
