KI-Agenten handeln. Aber wessen Rechte benutzen sie?

Ein KI-Agent liest ein Postfach, sucht Kundendaten, aktualisiert einen Datensatz und verschickt anschließend eine Nachricht. Technisch kann jeder einzelne Schritt korrekt autorisiert sein.

Trotzdem bleibt eine unangenehme Frage: Wer hat hier eigentlich gehandelt?

Der Mensch, der den Auftrag gestartet hat? Der Agent, der die einzelnen Schritte geplant hat? Ein Servicekonto, dessen Zugangsdaten im Hintergrund verwendet wurden? Und wenn später etwas schiefläuft: Lässt sich noch nachvollziehen, welche Rechte für genau diese Aufgabe delegiert waren?

Bei klassischen Assistenten ist diese Frage oft zweitrangig. Sie erzeugen einen Text, den ein Mensch weiterverarbeitet. Agentische Systeme verändern die Lage, weil sie selbst Tools aufrufen und damit Systemzustände verändern können.

Deshalb wird Identity & Access Management plötzlich zu einem Agentic-AI-Thema.

Sobald ein Agent handelt, reicht „der User war eingeloggt“ nicht mehr

NIST hat das Problem 2026 ungewöhnlich direkt formuliert. Ein Konzeptpapier des National Cybersecurity Center of Excellence behandelt für Software- und KI-Agenten getrennt Identifikation, Authentifizierung, Autorisierung, Delegation, Auditierbarkeit und Non-Repudiation.

Das Papier ist noch kein fertiger Standard. Es ist ein Entwurf für ein mögliches Demonstrationsprojekt. Gerade deshalb ist interessant, welche Fragen NIST überhaupt für offen genug hält, um sie gesondert zu untersuchen.

Wie wird ein Agent in einer Unternehmensarchitektur identifiziert? Wie lässt sich Least Privilege anwenden, wenn seine konkreten Aktionen nicht vollständig vorhersehbar sind? Wie beweist ein Agent, dass er eine bestimmte Aktion ausführen darf? Wie wird „on behalf of“ abgebildet? Und wie lässt sich eine Agentenaktion später wieder auf menschliche Autorisierung zurückführen?

Das sind keine Prompt-Fragen.

Sie entstehen erst, sobald ein System nicht nur etwas vorschlägt, sondern unter einer bestimmten Autorität tatsächlich handelt.

„On behalf of“ sind zwei Identitäten, nicht eine

Für diese Trennung muss die IT-Welt nicht bei null anfangen.

OAuth 2.0 Token Exchange beschreibt bereits seit Jahren Delegationsfälle, in denen zwei Rollen auseinandergehalten werden können. Vereinfacht gesagt steht der Subject für die Partei, in deren Namen gehandelt wird. Der Actor ist die Partei, die tatsächlich handelt.

RFC 8693 sieht dafür unter anderem ein Token für das Subject und optional eines für den Actor vor. Bei JWTs kann das Feld act zudem eine Delegationskette repräsentieren.

Für Agenten ist dieses Denkmodell ausgesprochen nützlich.

Ein Mitarbeiter kann einen Auftrag auslösen, ohne dass der Agent deshalb technisch zu diesem Mitarbeiter werden muss. Der Mensch bleibt der Principal, dessen Autorität den Vorgang ermöglicht. Der Agent bleibt als eigener Actor sichtbar.

Das klingt nach einer kleinen technischen Unterscheidung. Für Audit, Widerruf und Fehlersuche ist sie groß.

Diese vier Fragen sind kein neuer Identity-Standard. Sie verdichten nur, was NIST und bestehende OAuth-Mechanismen für delegierte Aktionen bereits getrennt behandeln.

Least Privilege wird bei Agenten zur Laufzeitfrage

Bei einem klassischen Servicekonto lässt sich relativ statisch überlegen, welche Rechte eine Anwendung benötigt.

Ein Agent kann schwieriger sein. Er bekommt ein Ziel, wählt abhängig vom Kontext Werkzeuge aus und entscheidet möglicherweise erst während der Ausführung, welche Ressource als Nächstes relevant wird.

Damit wächst die Versuchung, ihm vorsorglich ein breites Berechtigungsset zu geben.

Genau dagegen steht ein alter Sicherheitsgrundsatz. RFC 9700, die aktuelle Best Current Practice für OAuth 2.0 Security, empfiehlt, die mit einem Access Token verbundenen Rechte auf das für den jeweiligen Anwendungsfall notwendige Minimum zu begrenzen. Tokens sollen außerdem möglichst auf bestimmte Ressourcen beziehungsweise Audiences beschränkt werden. Sender-constrained Tokens können den Missbrauch gestohlener Tokens zusätzlich erschweren.

Für Agenten entsteht daraus keine einfache Regel „jede Aktion braucht einen neuen Token“. Die passende technische Umsetzung hängt vom System ab.

Die Architekturfrage wird aber klarer: Welche Autorität braucht dieser Agent für diese Aufgabe wirklich – und wie lange?

Ein Agent, der eine Rechnung aus einem Postfach lesen soll, braucht nicht automatisch dieselben Rechte wie der Mitarbeiter auf sein gesamtes Postfach. Ein Agent, der einen CRM-Entwurf erzeugt, braucht nicht zwingend das Recht, Kundenstammdaten zu löschen.

Least Privilege ist hier weniger eine einmalige Rollenmatrix als eine Grenze um den ausführbaren Auftrag.

Prompt Injection ist auch ein Berechtigungsproblem

Das wird besonders sichtbar, wenn der Agent falsch gelenkt wird.

Prompt Injection wird häufig als Modellproblem diskutiert: Ein Agent verarbeitet manipulierten Inhalt und folgt einer unerwünschten Anweisung. Doch selbst wenn sich solche Fehlsteuerung nicht vollständig verhindern lässt, entscheidet die Berechtigungsebene darüber, was daraus praktisch werden kann.

Eine 2026 veröffentlichte Studie von Md. Motaleb Hossen Manik und Ge Wang untersucht genau diesen Zusammenhang in sicherheitskritischen Workflow-Agenten. Das Haupttestfeld ist ein deterministischer Simulator; ergänzt wird es durch eine begrenzte Validierung mit einem realen lokalen Tool-Agenten in Sandbox-Szenarien aus radiologischen Daten.

Unter permissiven Bedingungen führten breitere Berechtigungen zu größerem realisierten Vertraulichkeits- und Integritätsschaden. Strengere Berechtigungsgrenzen und Policy Gating wirkten dabei komplementär. Die Autoren implementierten außerdem ein hash-verkettetes Append-only-Log, mit dem nachträgliche Manipulationen der Ausführungshistorie erkennbar wurden.

Der Kontext ist eng. Daraus lässt sich keine universelle Prozentzahl für Unternehmensagenten ableiten.

Der Mechanismus ist trotzdem relevant: Ein fehlgeleiteter Agent kann nur innerhalb dessen handeln, was die Infrastruktur tatsächlich zulässt. Das Modell darf deshalb nicht seine eigene Sicherheitsgrenze sein.

Ein Auditlog braucht mehr als einen Benutzernamen

Viele Systeme können heute hervorragend protokollieren, dass ein API-Aufruf stattgefunden hat.

Bei Agenten reicht das möglicherweise nicht.

Wenn im Log nur steht, dass das Konto „andreas@unternehmen.de“ einen Datensatz geändert hat, bleibt offen, ob Andreas selbst geklickt hat oder ob ein Agent in seinem Namen handelte. Wird stattdessen nur ein Servicekonto protokolliert, verschwindet womöglich der auslösende Mensch.

NIST nennt deshalb neben Agentenidentität ausdrücklich Access Delegation sowie Logging und Transparenz. Aktionen sollen der nichtmenschlichen Identität zugeordnet werden können; zugleich soll die Verbindung zur delegierenden Identität erhalten bleiben.

Ein brauchbares Audit muss deshalb nicht die komplette interne Gedankenkette eines Modells speichern. Es muss die relevante Ausführung rekonstruierbar machen.

Wer hat autorisiert? Welcher Agent hat gehandelt? Mit welcher Berechtigung? Auf welche Ressource? Welche Aktion wurde ausgeführt? Und welcher technische Kontrollpunkt hat sie erlaubt?

Das ist deutlich wertvoller als ein gigantischer Log-Ordner, in dem alle Einzelereignisse vorhanden sind, aber ihre Delegationsbeziehung fehlt.

MCP zeigt, dass Authorization kein Prompt-Thema ist

Wie praktisch diese Fragen geworden sind, zeigt die Entwicklung des Model Context Protocol.

Die MCP-Spezifikation vom 28. Juli 2026 hat ihre Authorization-Schicht weiter gehärtet. Dazu gehören unter anderem die Validierung des ausstellenden Authorization Servers und die Bindung von Client Credentials an den Issuer, der sie ausgegeben hat.

Auch Methoden- und Tool-Namen werden im aktuellen Protokoll so transportiert, dass Gateways, Rate Limiter oder andere Infrastruktur sie für Routing und Autorisierungsentscheidungen verwenden können.

Das beweist nicht, dass MCP der künftige Universalstandard für Agenten wird. Es zeigt etwas Nüchterneres: Sobald Agenten produktiv auf externe Werkzeuge zugreifen, landet Sicherheit sehr schnell bei bekannten Infrastrukturthemen wie OAuth, Issuer-Vertrauen, Credentials, Ressourcen und Policy Enforcement.

Der schönste Systemprompt ersetzt davon nichts.

Gegenposition: Dafür gibt es doch längst IAM

Der Einwand ist richtig.

Ein KI-Agent ist Software. Unternehmen verwalten seit Jahrzehnten Service Accounts, Workload Identities, API-Zugänge und delegierte Benutzerrechte. Nicht jedes Agentenprojekt braucht deshalb einen neuen Identitätstyp oder ein neues Protokoll.

Auch NIST formuliert sein Projekt ausdrücklich als Anwendung bestehender Identity-Standards und Best Practices. MCP baut bei Authorization auf OAuth und OpenID Connect auf. RFC 8693 besitzt bereits Delegationssemantik. RFC 9700 besitzt bereits Least-Privilege- und Token-Sicherheitsregeln.

Die Agentenwelle macht diese Grundlagen nicht obsolet. Eher das Gegenteil.

Neu ist vor allem die Häufigkeit, mit der Software dynamisch zwischen Ressourcen und Aktionen wechseln kann. Dadurch werden schlechte Abkürzungen schneller problematisch: ein gemeinsamer API-Key, ein breit berechtigtes Servicekonto, komplette Übernahme der Nutzerrechte oder Logs, in denen Agent und Mensch nicht getrennt erscheinen.

Die vernünftige Frage lautet deshalb nicht: Welchen neuen Agent-Identity-Standard müssen wir kaufen?

Sie lautet: Kann unsere bestehende Identity-Architektur Principal, Actor, delegierte Autorität und ausgeführte Aktion sauber auseinanderhalten?

Der bessere Test ist eine Delegationskette, die sich erklären lässt

Vor einem produktiven Agentenbetrieb sollte sich eine konkrete Aktion rückwärts erklären lassen.

Ein Mitarbeiter startet einen Vorgang. Daraus entsteht eine begrenzte Autorität. Ein identifizierbarer Agent nutzt sie für einen definierten Zugriff. Ein technischer Policy-Punkt erlaubt oder verweigert die Aktion. Danach bleibt ein Auditpfad erhalten, der den Zusammenhang sichtbar macht.

Wie genau das umgesetzt wird, kann unterschiedlich aussehen. OAuth Token Exchange kann passen. Eine Plattform kann eigene Agent Identities verwalten. Manche Prozesse brauchen zusätzliche Freigaben oder kurzlebige Credentials.

Die Architektur muss nicht überall gleich sein.

Das Ziel ist einfacher: Wenn ein Agent etwas im Unternehmen verändert, sollte später nicht nur feststehen, dass ein gültiger Zugang verwendet wurde.

Es sollte auch erklärbar sein, wer wen wozu autorisiert hat.