Agent Identity und Delegation

Viele AI-Agent-Projekte beantworten die Identitätsfrage zu grob. Ein Agent “hat Zugriff” oder “nutzt das User-Token”. Für produktive Systeme ist das zu wenig. Agent Identity beschreibt, mit welcher technischen Identität ein Agent auftritt. Delegation beschreibt, in wessen Auftrag er handelt und wie weit dieser Auftrag reichen darf. Erst zusammen machen beide Ebenen agentische Zugriffe kontrollierbar.

Warum Agent Identity mehr ist als ein API-Key

Ein KI-Agent ist keine normale Backend-Funktion. Er plant dynamisch, kann Werkzeuge wechseln, Kontext persistent nutzen und Aktionen in mehreren Systemen auslösen. Wenn so ein System mit geteilten Credentials, pauschalen Service Accounts oder unsichtbarer Nutzerdelegation arbeitet, fehlt später jede belastbare Aussage darüber, wer eigentlich gehandelt hat.

Genau deshalb sollten produktive AI Agents als Non-Human Identities modelliert werden. Sie brauchen einen klaren Zweck, definierte Rechte, einen nachvollziehbaren Lebenszyklus und sauber protokollierte Entscheidungen. Das ist nicht nur ein IAM-Thema, sondern Grundlage für Governance, Incident Response und sichere Tool-Nutzung.

Die eigentliche Schwierigkeit ist die Delegationskette

In agentischen Systemen ist Zugriff selten eindimensional. Häufig sieht die Kette eher so aus: Nutzer startet Auftrag, Supervisor-Agent plant, ein Tool-Runner ruft eine API auf, ein MCP-Server greift auf ein Drittsystem zu und ein zweiter Agent führt den nächsten Schritt aus. Jeder dieser Übergänge verändert den Vertrauenskontext.

Deshalb reicht die Frage “Ist der Agent authentisiert?” nicht aus. Relevanter ist:

• Handelt der Agent aus eigenem Workload-Recht oder im Namen eines Nutzers?
• Für welchen Auftrag und welchen Scope gilt diese Delegation?
• Darf die Delegation an Sub-Agents, Tools oder externe Server weitergereicht werden?
• Was passiert, wenn sich Risiko, Zielsystem oder Aufgabentyp während des Runs ändern?

Ohne diese Präzisierung entsteht leicht ein confused-deputy-artiges Muster: Ein Agent nutzt formal gültige Rechte, aber im falschen Kontext, für den falschen Nutzer oder für eine zu breite Anschlussaktion.

Typische Fehlmuster bei Agent Identity und Delegation

Das häufigste Fehlmuster sind Shared Credentials. Wenn mehrere Agenten oder Environments dasselbe Token nutzen, gehen Attribution, Revocation und differenzierte Policies verloren.

Ebenfalls kritisch ist sticky delegation. Der Agent erhält zu Beginn eines Workflows ein starkes Nutzerrecht und trägt dieses anschließend über mehrere Schritte, Tools oder Stunden weiter, obwohl spätere Aktionen eigentlich neue Prüfung oder Step-up brauchen würden.

Ein drittes Problem ist privilege laundering. Dabei liest ein Agent mit breiten Rechten Daten oder führt Aktionen aus, die der ursprüngliche Auftraggeber selbst nie direkt hätte auslösen dürfen. Die Delegationskette existiert technisch, aber die Fachgrenze ist verschwunden.

Besonders gefährlich wird das in Multi-Agent-Systemen oder bei MCP-basierten Tool-Landschaften. Dort kann sich eine unklare Identity- und Delegationslogik schnell über mehrere Komponenten verteilen, bis am Ende niemand mehr sagen kann, ob eine Aktion aus User-Willen, Agentenlogik oder Tool-Seiteneffekt entstanden ist.

Praktische Designregeln für produktive AI Agents

Ein belastbares Modell folgt einigen einfachen Prinzipien.

Jeder produktive Agent braucht eine eigene technische Identität. Nutzerdelegation sollte explizit, kurzlebig und auf konkrete Aufträge, Ressourcen oder Aktionsklassen begrenzt werden. Sub-Agents dürfen Rechte nicht stillschweigend erben, sondern brauchen entweder eigene Identitäten oder einen klar dokumentierten Delegationspfad.

Wichtig ist außerdem die Trennung zwischen Authentisierung, Autorisierung und Auftragsbindung. Ein Agent kann technisch bekannt sein und trotzdem für den aktuellen Datensatz, den aktuellen Tenant oder die aktuelle High-Impact-Aktion unzulässig handeln. Deshalb müssen Resource Binding, Audience, Laufzeitkontext und Auftrag gemeinsam geprüft werden.

Reife Teams definieren zudem, wann Delegation endet. Ein guter Standard ist: Nach sensiblen Zustandswechseln, Rollenwechseln, Zielsystemwechseln oder längeren Unterbrechungen wird Delegation neu bewertet oder explizit widerrufen.

Review-Fragen für Agent Identity und Access Control

Für Architektur- und Security-Reviews helfen diese Fragen:

• Welche Non-Human Identities existieren pro Agent, Tool-Runner und Environment?
• Welche Aktionen sind nur mit Nutzerdelegation erlaubt und welche nie?
• Welche Rechte dürfen an Sub-Agents, MCP-Server oder externe APIs weitergegeben werden?
• Wie schnell lassen sich riskante Delegationen widerrufen?
• Welche Logs zeigen später die effektive Identität, den Auftraggeber und den Scope einer Aktion?

Wenn diese Fragen nicht sauber beantwortbar sind, ist die Sicherheitsarchitektur meist nicht wirklich identity-aware, sondern nur oberflächlich authentisiert.

Wie dieses Insight den Content-Cluster unterstützt

Wer die operative Umsetzung sucht, landet von hier aus logisch bei Context-aware Authentication, Least Privilege & Tool Security und Multi-Agent Security. Das strategische Ziel dieses Insights ist davor angesiedelt: Es macht sichtbar, warum Agent Identity, Delegation, Workload Identity und Access Control bei AI Agents nicht als Randthema behandelt werden dürfen.

Gerade für Suchanfragen rund um AI agent identity, non-human identity, delegated authorization, agent authentication oder access control for LLM agents bildet diese Seite die begriffliche Brücke zwischen IAM, Runtime Security und agentischer Systemarchitektur.