Das übliche Identity Lifecycle Management ist als ereignisgesteuertes Kontrollsystem aufgebaut. Sein Fundament ist die Annahme, dass jede Identität einer Person zugeordnet ist, deren organisatorischer Status sich über dokumentierte HR-Ereignisse ändert. Systeme wie Workday, SAP SuccessFactors oder ServiceNow HR fungieren dabei als führende Quelle: Neueinstellungen stoßen Provisionierung in Active Directory oder Azure AD an, Abteilungswechsel führen zu neuen Rollenattributen und Entitlement-Berechnungen, Austritte lösen Deprovisionierungs-Workflows aus.
Die Stärke dieses Modells liegt in seiner Deterministik. Zugriffsrechte lassen sich an verifizierbare Organisationsfakten koppeln, etwa Rolle, Team und Vorgesetztenbeziehung. Darauf bauen Role-based Access Control, Rezertifizierungskampagnen, Separation-of-Duties-Kontrollen und Audit-Protokolle auf, die wiederum Nachweise für Rahmenwerke wie SOX, HIPAA und PCI DSS liefern.
Bei KI-Agenten greifen diese Annahmen jedoch nicht mehr. Sie kommen nicht über HR ins Unternehmen, sondern entstehen durch Entwickler, Orchestrierungs-Frameworks oder automatisierte Deployment-Pipelines. Genannt werden unter anderem LangChain, AutoGen und AWS Bedrock Agents. Provisionierung geschieht etwa über Konfigurationsdateien, API-Aufrufe oder Terraform-Deployments. Solche Ereignisse berühren laut Text keine IGA-Plattform und erzeugen keinen Provisionierungsdatensatz mit klar definiertem Eigentümer.
Hinzu kommt, dass Agenten häufig bereits mit Zugangsdaten starten: mit manuell angelegten Service-Accounts, API-Schlüsseln in Umgebungsvariablen oder OAuth-Freigaben aus Entwickler-Consent-Flows. Falls eine IGA-Plattform diese Zugangsdaten überhaupt sieht, behandelt sie sie als statische Maschinenidentität mit festem Zweck. Tatsächlich, so die Beschreibung, handelt es sich aber um einen autonomen Principal, der Zugriffsentscheidungen trifft, API-Grenzen überschreitet und sein Verhaltensspektrum dynamisch erweitert.
Genau hier stößt das klassische Rollenmodell an Grenzen. Bei menschlichen Nutzern sind Aufgaben und Berechtigungen zumindest in gewissem Rahmen vorhersagbar. KI-Agenten arbeiten dagegen nicht zwangsläufig innerhalb fester Funktionsgrenzen. Ein Agent zur Zusammenfassung interner Dokumente kann über Tool-Aufrufe oder RAG-Abrufe APIs ansprechen, für die er nicht ausdrücklich vorgesehen war, Daten in Speichersysteme außerhalb seines ursprünglichen Umfangs schreiben oder Aktionen über mehrere Unternehmenssysteme hinweg verketten. Die Zugriffsfläche wächst zur Laufzeit statt nur an bekannten Übergangspunkten.
Auch die Architektur verteilter Agentensysteme verschärft das Problem. Ein menschlicher Benutzer existiert an einem Ort, ein KI-Agent kann parallel in Dutzenden Instanzen über Cloud-Umgebungen, containerisierte Workloads und SaaS-API-Oberflächen hinweg laufen. In Multi-Agenten-Architekturen können Orchestrator-Agenten zudem Unteragenten erzeugen, Aufgaben delegieren und Zugangsdaten zwischen Ausführungskontexten weiterreichen. Für ein solches Forken, Delegieren und Rekombinieren von Rechten gibt es im herkömmlichen Identity- und Access-Management-Lebenszyklus laut Text kein natives Modell.
Das führt entlang des gesamten Joiner-Mover-Leaver-Schemas zu blinden Flecken. Beim „Joiner“ fehlt schon das Startsignal: Der Agent geht per Deployment in Produktion, ohne dass ein IGA-Workflow startet, ein Zugriffsantrag gestellt oder eine Genehmigungskette durchlaufen wird. Beim „Mover“ bleibt jede Änderung unsichtbar, wenn ein Agent neue Datenquellen, zusätzliche APIs oder andere Umgebungen erhält. Und beim „Leaver“ gibt es kein HR-Äquivalent, das die Stilllegung eines Workflows oder Projekts zuverlässig an angeschlossene Systeme meldet.
Die Folge sind laut Text überprivilegierte und verwaiste Zugänge. Entwickler vergeben Berechtigungen oft breit genug, damit der Agent seine Aufgabe sicher erfüllen kann. Als Beispiele nennt der Text weit gefasste AWS-IAM-Richtlinien mit Wildcards, OAuth-Consent-Flows, die alle angeforderten Scopes gewähren, sowie die Erstellung von Service-Accounts in Azure AD oder Google Workspace ohne eingebaute Entitlement-Governance-Prüfung. Wird ein Agent später eingestellt, bleiben Service-Accounts in Active Directory oder Entra ID, API-Schlüssel in Secrets Managern und OAuth-Freigaben auf Autorisierungsservern bestehen.
Als notwendige Erweiterung fordert der Leitfaden deshalb kein Nachrüsten klassischer HR-Workflows, sondern ein anderes Governance-Modell. Erforderlich seien kontinuierliche, automatisierte Erkennung in den Umgebungen, in denen Agenten tatsächlich leben, etwa über IAM-Richtlinien in AWS und Azure, OAuth-Client-Registrierungen, Kubernetes-Service-Accounts und API-Schlüssel in Laufzeitkonfigurationen. Zusätzlich brauche es ein anderes Attributmodell mit verantwortlichem Team, dokumentiertem Einsatzzweck, erlaubten Systemen und APIs, Deployment-Zeitpunkt, erwarteter Lebensdauer sowie beobachteten Verhaltensmustern.
An die Stelle periodischer Rezertifizierung soll verhaltensbasierte Dauerüberwachung treten: Welche APIs ruft ein Agent tatsächlich auf, weichen beobachtete Zugriffe vom provisionierten Entitlement-Satz ab, und wann bleibt ein Credential über längere Zeit ungenutzt? Solche Signale sollen Governance-Ereignisse auslösen und über integrierte Widerrufs-Workflows etwa mit AWS Secrets Manager, Azure Key Vault oder HashiCorp Vault verbunden werden.
Als Anbieter, der genau diese Lücke adressieren will, nennt der Text Orchid Security. Orchid setze leichtgewichtige Orchestratoren ein, die Anwendungen direkt instrumentieren und Authentifizierungsflüsse, Autorisierungslogik, Kontokonfigurationen und Muster der Credential-Speicherung aus verwalteten und nicht verwalteten Umgebungen extrahieren. Daraus entstehe ein fortlaufend aktualisiertes Identitätsinventar einschließlich Agentenidentitäten, Service-Accounts und API-Credentials, die nie einen IGA-Intake-Prozess durchlaufen haben. Laut Darstellung verknüpft der Identitätsgraph von Orchid Principals mit den tatsächlich genutzten Authentifizierungsflüssen, Entitlements und Anwendungszugriffspfaden und ergänzt damit bestehende IAM-, PAM- und IGA-Infrastrukturen, statt sie zu ersetzen.