KI-Agenten brauchen eine Identität: Warum menschliche Nutzerrechte nicht mehr ausreichen

KI-Agenten verschieben gerade die Grenze zwischen Mensch und System. Was KI-Agenten technisch und konzeptionell wirklich sind — und wie sie sich von klassischen Automatisierungen unterscheiden — ist eine Vorfrage, die das Identitätsproblem erst vollständig verständlich macht. Was in IAM-, OAuth- oder Zero-Trust-Modellen lange relativ klar war, wird dadurch unsauberer: Menschen haben Identitäten, Rollen und Rechte. Agenten handeln dagegen oft nur indirekt über den Kontext eines menschlichen Nutzers.

Das eigentliche Problem bei KI-Agenten ist nicht, dass sie zu viel „denken“. Das Problem ist, dass sie anfangen zu handeln.

Solange ein Modell nur Text erzeugt, bleibt die Verantwortung klar: Ein Mensch liest das Ergebnis und entscheidet, was passiert. Sobald ein Agent aber selbst Tools nutzt, Systeme verändert, Pull Requests anlegt, Workflows ausführt oder Cloud-Ressourcen anspricht, reicht dieses Modell nicht mehr aus.

Denn dann stellt sich eine einfache, aber folgenreiche Frage: Wer hat das eigentlich getan?

In vielen aktuellen Setups lautet die technische Antwort noch immer: der eingeloggte Nutzer. Genau das wird zum Problem. Wenn Agenten mit denselben Rechten arbeiten wie Menschen, verschwimmen Identität, Verantwortung und Zugriffskontrolle. Für experimentelle Demos mag das noch genügen. Für produktive Systeme reicht es nicht.

Das strukturelle Problem

Agenten handeln heute oft im Namen eines Nutzers, aber technisch ist nicht immer sauber sichtbar, ob eine Aktion vom Menschen selbst ausgelöst wurde oder von einem Agenten in seinem Kontext.

Das klingt zunächst nach einem Detail. In der Praxis ist es aber eine zentrale Governance-Frage.

Wenn in einem Repository ein Pull Request auftaucht, in einer Cloud-Umgebung eine Konfiguration geändert wird oder in Microsoft 365 ein Workflow Dokumente verschiebt, reicht es nicht zu wissen, welcher Account angemeldet war. Man muss wissen:

war es der Mensch selbst?
war es ein Agent?
mit welchem Auftrag?
mit welchen erlaubten Grenzen?
und auf wessen Verantwortung hin?

Genau diese Trennung fehlt in vielen heutigen Setups noch.

Warum das jetzt relevant wird

Das Thema war lange zweitrangig, weil KI-Systeme vor allem Vorschläge gemacht haben. Jetzt ändert sich der Einsatzkontext.

Drei Entwicklungen treiben das Thema nach vorn:

Mehr Autonomie
Agenten arbeiten nicht mehr nur turn-by-turn, sondern führen mehrstufige Aufgaben aus.

Mehr Tool-Zugriffe
Repos, Ticketsysteme, Datenbanken, Cloud-Konfigurationen, Office-Umgebungen und interne APIs werden direkt angebunden. Was dabei an Sicherheitsproblemen durch unkontrollierte Tool-Zugriffe entsteht, ist ein eigenes Thema — direkt verbunden mit der Frage, unter welcher Identität ein Agent handelt.

Mehr produktive Einsätze
KI verlässt den Demo-Modus. Sobald echte Änderungen in produktiven Systemen möglich sind, werden Identität und Rechte zu Architekturfragen.

Je mehr Agenten handeln dürfen, desto weniger tragfähig ist das Modell „läuft halt unter dem User“.

In vielen Unternehmen ist Zero Trust längst Standard, aber primär für menschliche Nutzer und klassische Service-Zugriffe. Agenten dehnen dieses Prinzip auf maschinelles Handeln aus und brauchen dafür eigene Tokens, Scopes und überprüfbare Grenzen.

Was eine Agent Identity lösen soll

Eine Agent Identity ist nicht einfach nur ein zusätzlicher Login. Sie löst drei konkrete Probleme.

1. Nachvollziehbarkeit

Es muss sichtbar sein, ob eine Aktion vom Menschen oder vom Agenten ausgeführt wurde.

Nicht nur im Audit-Log, sondern idealerweise auch im Fachsystem selbst:

dieser PR wurde von einem Agenten erstellt
diese Änderung lief über ein delegiertes Agent-Token
diese Freigabe wurde vom Nutzer erteilt, die Ausführung vom Agenten übernommen

Ohne diese Trennung wird spätere Analyse unnötig unklar.

Für Compliance ist das nicht nur eine technische, sondern auch eine regulatorische Frage. Wenn ein Agent Daten verarbeitet, Systeme verändert oder produktive Workflows ausführt, muss sich nachvollziehen lassen, wer oder was verantwortlich war. Ohne eigene Identität bleibt das nur schwer auditierbar.

2. Rechtebegrenzung

Ein Agent sollte nicht automatisch alles dürfen, was sein Nutzer darf.

Das ist das Kernproblem vieler heutiger Integrationen. Ein Nutzer hat oft absichtlich breite Rechte, weil er in verschiedenen Situationen flexibel handeln muss. Ein Agent braucht genau diese Breite aber meist nicht.

Agent Identity bedeutet deshalb: eigene, enger geschnittene Rechte statt geerbter Vollzugriff.

3. Trennung zwischen Mensch und Agent

Ein Mensch entscheidet anders als ein Agent.

Menschen können Kontext wechseln, implizites Wissen einbringen, Risiken abwägen, rechtliche oder politische Folgen mitdenken. Agenten arbeiten auf Basis von Auftrag, Toolzugriff und Systemgrenzen.

Diese Unterschiedlichkeit muss sich auch technisch abbilden. Sonst behandelt das System beide so, als wären sie dieselbe Akteurklasse. Genau das ist langfristig nicht haltbar.

Praxisbeispiele

Pull Requests

Ein Agent analysiert Issues, ändert Code und öffnet einen Pull Request.

Ohne Agent Identity erscheint der Vorgang oft so, als hätte der Nutzer selbst alles getan. Das ist unpräzise. Eigentlich braucht es eine klarere Trennung: Mensch delegiert Aufgabe, Agent arbeitet unter begrenztem Repo- und Branch-Zugriff, PR wird als Agent-Aktion gekennzeichnet, Merge bleibt eventuell beim Menschen.

Cloud-Änderungen

Ein Agent darf Infrastruktur lesen, Konfigurationen prüfen und bestimmte Änderungen anstoßen.

Wenn er dabei unter denselben Rechten läuft wie ein Administrator, ist das riskant. Denn dann hängt die Sicherheitsgrenze nicht an der Aufgabe, sondern an der maximalen Macht des Nutzers.

Besser ist ein Modell, in dem der Agent nur delegierte Teilrechte erhält: lesen ja, bestimmte Änderungen ja, produktive Löschungen nein, Eskalation nur über explizite Freigabe.

Office- und M365-Workflows

Ein Agent sortiert Mails, erzeugt Zusammenfassungen, verschiebt Dateien oder stößt Freigaben an.

Gerade in Office-Umgebungen ist die Versuchung groß, einfach „im Namen des Users“ zu handeln. Das ist bequem, aber problematisch. Denn dann kann später kaum noch sauber unterschieden werden, ob ein Mensch selbst gehandelt hat oder ein Agent automatisch.

Warum „gleiche Rechte wie der Nutzer“ zu viel ist

Das Standardmuster heutiger Agentensysteme ist oft implizit: Wenn der Nutzer darf, darf der Agent auch.

Das ist bequem, aber architektonisch schwach. Nutzerrechte entstehen meist nicht nach dem Prinzip minimaler Präzision, sondern nach praktischer Breite. Menschen brauchen im Alltag Spielraum. Agenten brauchen dagegen klar begrenzte Handlungsräume.

Daraus folgt ein Grundsatz: Ein Agent sollte nicht die Identität des Nutzers simulieren, sondern mit delegierten Rechten unter eigener Identität arbeiten.

Least Privilege statt Komfortmodell

Das Sicherheitsprinzip dahinter ist nicht neu. Es heißt Least Privilege.

Neu ist nur, dass es jetzt auch auf Agenten angewendet werden muss. Ein Agent braucht genau die Rechte, die für seine Aufgabe nötig sind: nicht mehr, nicht global, nicht dauerhaft, nicht implizit.

Damit rückt auch ein zweites bekanntes Prinzip stärker in den Vordergrund: Just-in-Time Access. Viele Agenten brauchen Rechte nicht dauerhaft, sondern nur für eine klar umrissene Aufgabe und für eine begrenzte Zeit. Genau das passt besser zu delegierten Agent-Identitäten als zu geerbten Nutzerrechten.

Das bedeutet oft auch:

zeitlich begrenzte Delegation
task-spezifische Berechtigungen
approvals für kritische Aktionen
getrennte Audit-Spuren

Delegation statt Stellvertretung

Der bessere Architekturgedanke ist deshalb Delegation, nicht Stellvertretung.

Ein Nutzer sagt nicht einfach: „Handle als ich.“ Sinnvoller ist ein Modell wie: „Für diese Aufgabe darfst du unter diesen Grenzen genau diese Dinge tun.“

Das ist ein fundamentaler Unterschied. Stellvertretung imitiert den Menschen. Delegation definiert einen beschränkten Aktionsraum.

Genau dort beginnt Agent Identity als ernstzunehmender Baustein: nicht als zusätzlicher Account, sondern als saubere Trennung zwischen Auftrag, Rechten und Ausführung.

Technisch erinnert das an Service Accounts, OAuth-Scopes oder temporäre Cloud-Credentials. Der Unterschied ist, dass Agenten nicht nur einen festen Systemzweck erfüllen, sondern auf wechselnde Aufträge reagieren. Gerade deshalb muss ihre Identität stärker an Policies, Freigaben und Laufzeiten gekoppelt sein.

Was OpenAI, Google und Anthropic bereits andeuten

Die Idee einer eigenen Agent Identity ist keine reine Theorie mehr. Die großen Anbieter bewegen sich sichtbar in diese Richtung, wenn auch mit unterschiedlicher Klarheit.

Google: Agent Identity als explizites Produktkonzept

Google formuliert das am deutlichsten. In Vertex AI Agent Engine gibt es Agent Identity als eigenes IAM-Konzept: pro Agent eine eigene Identität, an den Lebenszyklus des Agenten gebunden, mit Least-Privilege-Ausrichtung und Governance über bestehende IAM-Kontrollen. Für delegierte Flows beschreibt Google zudem, dass Logs sowohl die Nutzer- als auch die Agenten-Identität ausweisen.

Das ist mehr als eine vage Sicherheitsidee. Es ist ein konkretes Modell dafür, Agenten nicht nur als Tool-Aufruf im Nutzerkontext zu behandeln, sondern als eigenständige, kontrollierbare Akteure.

OpenAI: Governance, Auditierbarkeit und task-begrenzter Zugriff

OpenAI spricht öffentlich weniger detailliert über ein eigenes IAM-Modell, geht aber klar in dieselbe Richtung. Im Frontier-Programm beschreibt OpenAI agent identity & access management als Teil von Enterprise-Governance: Agenten sollen Zugriff genau für die jeweilige Aufgabe erhalten, mit Sichtbarkeit, Auditierbarkeit und ohne unnötige Überprivilegierung.

Auch OpenAIs eigener interner Data Agent folgt diesem Muster. Dort läuft der Agent als kontrollierte Interface-Schicht mit pass-through permissions, also nur auf Daten, auf die der jeweilige Nutzer ohnehin Zugriff hat.

Die Einordnung daraus: OpenAI formuliert noch kein so ausgebautes Agent-Identity-Modell wie Google, bestätigt aber sehr klar die zugrunde liegende Richtung: Agenten brauchen begrenzten, nachvollziehbaren und aufgabenbezogenen Zugriff.

Anthropic: Permission-Architektur statt voll geerbter Nutzerrechte

Anthropic setzt öffentlich den stärksten Akzent auf Permission-Modelle. In Claude Code gilt standardmäßig ein read-only-Modell; für Bash, Dateischreiben oder andere risikoreichere Aktionen sind explizite Freigaben nötig. Dazu kommen feinere Regeln wie allow, ask und deny, Team-Policies und zusätzliche Schutzschichten wie Sandboxen oder Auto Mode.

Anthropic spricht damit weniger über Agent Identity im engen IAM-Sinn als über kontrollierte Handlungsräume. Inhaltlich stützt das denselben Kernpunkt: Autonome Agenten sollten nicht einfach mit den vollen Rechten eines Nutzers laufen.

Forschung und Expertenmeinungen

Auch außerhalb der Produktdokumentation zeigt sich dieselbe Tendenz. Google Research nennt in seinem Papier zu sicheren AI Agents drei Kernprinzipien: klar definierte menschliche Verantwortlichkeit, begrenzte Befugnisse und beobachtbare Aktionen. Das passt direkt zu der These dieses Artikels.

Auf der Praxisseite meldete die Cloud Security Alliance am 24. März 2026, dass 68 Prozent der befragten Organisationen menschliche und agentische Aktivitäten nicht klar unterscheiden können. Das ist kein theoretisches Problem mehr, sondern eine operative Lücke in IAM, Governance und Auditierung.

Einordnung

Solange KI nur Vorschläge macht, reichen menschliche Nutzerrechte oft noch aus. Sobald Agenten aber selbst handeln, Systeme verändern und produktive Workflows ausführen, wird dieses Modell zu grob.

Die entscheidende Frage ist dann nicht mehr nur, was ein Agent kann. Die entscheidende Frage ist, unter welcher Identität, mit welchen Rechten und in welcher Nachvollziehbarkeit er handelt.

Genau deshalb dürfte Agent Identity vom Nice-to-have zum Pflichtbaustein werden.

Nicht als Zusatzfeature für Security-Teams, sondern als Grundvoraussetzung dafür, dass autonome Agenten in echten Arbeitsumgebungen verantwortbar eingesetzt werden können.

Wahrscheinlich werden Agenten künftig mit eigenen, auditierbaren Tokens, delegierten Rechten und klaren Ablaufzeiten arbeiten: verwaltet ähnlich wie Service Accounts, aber gesteuert über Policy-Layer, die auf agentisches Verhalten zugeschnitten sind. Genau dort dürfte sich entscheiden, ob KI-Agenten in Unternehmen nur experimentell bleiben oder zu einer belastbaren operativen Schicht werden.