Ein Mensch folgt in der Regel einem vorhersagbaren Aufgabenpfad. Ein Agent verkettet Aufgaben, wählt Werkzeuge dynamisch aus und komponiert Aktionen, die keine Berechtigungsprüfung vorweggenommen hat. Die OWASP Top 10 für Anwendungen mit großen Sprachmodellen benennen dieses Fehlerbild als „exzessive Handlungsvollmacht“ (LLM06): Ein Agent mit weit gefassten Funktionen, Rechten oder Autonomie handelt über seine genehmigte Aufgabe hinaus. Statische Rollenzuweisung kann dieses Verhalten nicht begrenzen, Konfigurationsprüfungen können es nicht messen.
Fehlkonfiguration ist dabei nicht automatisch Ausnutzbarkeit. Die tatsächliche Exposition hängt von den Rechten ab, die der Agentenidentität wirklich anhängen, von den aus ihrem Ausführungskontext erreichbaren Systemen und von den Laufzeitbedingungen. Konfigurationsbefunde beschreiben Möglichkeiten, Telemetrie beschreibt Geschehenes.
Agentenidentitäten entstehen meist durch Infrastrukturautomatisierung, Deployment-Pipelines oder Anwendungsteams — nicht durch HR-getriebene Lebenszyklusereignisse. Sie umgehen damit jene Governance-Abläufe, die bei menschlichen Zugriffen Auffälligkeiten fangen, und sammeln sich außerhalb des Inventars an, auf dem Compliance-Berichte beruhen.
Die Bausteine eines Agenten-Frameworks gliedern sich sauber: feststellen, wer der Agent ist, begrenzen, was er darf, und nachweisen, was er getan hat. Jeder Agent braucht eine eigene, zurechenbare Identität — nie ein geteiltes Dienstkonto, nie eine geliehene menschliche Zugangskennung. Bei den Zugangsdaten sind Workload Identity Federation sowie kurzlebige, automatisch rotierte Credentials eingebetteten Geheimnissen vorzuziehen. Handelt ein Agent im Auftrag eines Nutzers, liefert OAuth 2.0 Token Exchange (RFC 8693) Semantiken für Delegation und Impersonation, die zwischen der eigenen Identität des Agenten und der geliehenen Autorität unterscheiden. Diese Unterscheidung verschwindet, sobald ein Agent schlicht das Sitzungs-Token des Nutzers weiterverwendet.
Authentifizierung stellt Identität fest, Autorisierung bestimmt die Reichweite eines Schadens. Die Zugriffskontroll-Familie (AC) in NIST SP 800-53 Rev. 5 gilt unverändert auch für Agentenidentitäten, einschließlich geringster Rechte (AC-6), Aufgabentrennung (AC-5) und expliziter Autorisierungsgrenzen. Der Durchsetzungspunkt muss allerdings näher an der Aktion liegen als ein Login-Gateway.
Das NIST AI Risk Management Framework (AI 100-1) behandelt Rechenschaft und Transparenz als Vertrauenswürdigkeitsmerkmale, die von nachvollziehbarem Systemverhalten abhängen; die Audit-Familie (AU) in SP 800-53 setzt Aufzeichnungen voraus, die eine Handlungsfolge rekonstruierbar machen — nicht bloß den Nachweis, dass eine Policy existierte. Überwachung muss deshalb verhaltensbasiert sein: Identitätsangriffe wie der Missbrauch gültiger Konten (T1078) und die in MITRE ATT&CK katalogisierten Techniken zur Rechteausweitung erzeugen unauffällige Authentifizierungsprotokolle, weil die Zugangsdaten legitim sind.
In Evaluationen werden ausgerechnet Widerrufsgeschwindigkeit und Beweisqualität am häufigsten übersprungen, weil sich Provisionierungsfunktionen leichter vorführen lassen. Für Unternehmen mit bestehendem Identity-Governance-Programm ist das Erweitern der vorhandenen IAM-Plattform der naheliegende Ausgangspunkt; Governance-Plattformen wie SailPoint und Saviynt adressieren die Entwurfszeit-Hälfte und haben Funktionen für nichtmenschliche und Agentenidentitäten veröffentlicht, deren Abdeckung sich jedoch von Release zu Release ändert. Eigenbau lohnt dort, wo Agenten-Frameworks proprietär sind und Autorisierung in die Laufzeit eingebettet werden muss; zugekauft wird typischerweise die Entdeckung von Agentenidentitäten direkt aus Anwendungen und Infrastruktur sowie die Prüfung, ob die Ausführung der Absicht entsprach.
Drei Beispiele zeigen die Lücke: Ein Betriebsagent für Support-Tickets erzeugt im Identity Provider wenige unauffällige Anmeldungen am Tag, fragt in den Anwendungen aber Kundendatensätze ab, exportiert Daten und ändert Berechtigungen. Ein Beschaffungsagent soll Lieferantenpreise abrufen, besitzt Rechte auf der gesamten Beschaffungs-API und löst womöglich Bestellungen aus, weil die Aufgabenkette sich dorthin argumentiert hat — Absicht, Berechtigung und Ausführung sind drei getrennte Artefakte, und nur das dritte beschreibt das tatsächliche Geschehen. Ein Agent zur Code-Auslieferung mit Control-Plane-Identität schließlich benötigt weitreichende Rechte und kann im kompromittierten Zustand die Umgebung samt der Kontrollen umbauen, die ihn entdecken sollen.
Auf dieser dritten Stufe setzt Orchid Security an: Das Unternehmen entdeckt Identitäten direkt aus Anwendungen und Infrastruktur statt allein aus IAM-Konfigurationsdaten und ergänzt bestehende IAM-Plattformen um eine Verifikations- und Behebungsschicht. Die Abdeckung hängt davon ab, welche Anwendungen und Infrastrukturen angebunden sind.
Schwieriger wird es, sobald Agenten einander autorisieren: Delegiert ein Agent eine Teilaufgabe, wandert Autorität durch eine Kette, die kein Mensch Schritt für Schritt genehmigt hat. Maschinenlesbare Policies sowie laufende Standardisierungsarbeiten zu überprüfbaren Agenten-Credentials und eingeschränkter Delegation sind erste Antworten, doch die Interoperabilität zwischen Agenten-Frameworks ist ungeklärt. MITRE ATLAS katalogisiert Taktiken und Techniken gegen KI-gestützte Systeme und dient als Referenz dafür, wie solche Ketten angegriffen werden dürften. Kontinuierliche Autorisierung ersetzt die einmalige Zulassungsentscheidung durch eine fortlaufende Neubewertung — funktioniert aber nur dort, wo Verhaltenssignale existieren.