Das Machine-JML-Problem: Ein Joiner-Mover-Leaver-Lifecycle für KI-Agenten und Service-Accounts

Ihr HRIS löst ein Joiner-Event aus, sobald ein New Hire seinen Arbeitsvertrag unterzeichnet. Es löst ein Mover-Event aus, wenn er das Team wechselt. Und es löst ein Leaver-Event aus, sobald er kündigt. Diese drei Signale steuern in einem gut aufgestellten Identity-Programm alle nachgelagerten Provisionierungs- und Deprovisionierungsaktionen - und sie bilden das Fundament von Idens Ansatz für den vollständigen JML-Lifecycle.

Das Problem: KI-Agenten unterzeichnen keine Arbeitsverträge. Service-Accounts tauchen nicht in Workday auf. MCP-Server-Zugangsdaten erzeugen kein Leaver-Event, wenn das Projekt, für das sie erstellt wurden, eingestellt wird. Und dennoch häufen sich diese Machine-Identities in Ihrer Umgebung in einem Tempo an, das Ihre menschliche Belegschaft bei weitem übersteigt.

Forschungsergebnisse von Rubrik Zero Labs beziffern das Verhältnis nicht-menschlicher Identitäten (NHIs) zu menschlichen Identitäten im modernen Unternehmen auf 45:1 - und für Cloud-native- und DevOps-Umgebungen setzt die H1-2025-Studie von Entro Labs diesen Wert sogar auf 144:1. ^[1] Die Governance-Infrastruktur für diese Identitäten? Nahezu vollständig absent.

Dieser Beitrag überträgt das klassische JML-Framework auf Machine-Identities - Agenten, Service-Accounts, API-Keys, OAuth-Token, MCP-Server-Zugangsdaten - und zeigt, wie automatisierte Lifecycle-Governance aussieht, wenn Sie jede Machine-Identity mit derselben Sorgfalt behandeln wie menschliche Identitäten.

Warum Machine-Identities ein JML-Modell brauchen

Das JML-Framework funktioniert für Menschen, weil es ein System of Record gibt - das HRIS -, das Lifecycle-Events erzeugt. Diese Events lösen Provisionierungs-Workflows, Access-Reviews und Deprovisionierungsaktionen aus. Die Governance-Kette ist geschlossen.

Bei Machine-Identities ist die Kette an jedem Glied offen. Mehr als 16 % der Organisationen geben an, die Erstellung neuer KI-bezogener Identitäten überhaupt nicht zu verfolgen, wodurch ein wachsender Teil von Token und Service-Accounts außerhalb jedes formalen Inventars bleibt. ^[2] Eine WEF-Analyse aus dem Jahr 2025 ergab, dass 51 % der Organisationen keine klare Eigentümerschaft für KI-Identitäten definiert haben. ^[3]

Das Ergebnis ist eine Population von Identitäten, die ohne Autorisierungs-Gates entstehen, im Scope driften, ohne überprüft zu werden, und nie sauber stillgelegt werden. Jede Phase lässt sich direkt einem JML-Versagensmuster zuordnen.

Phase 1 - Das Joiner-Problem: Wer hat diesen Agenten autorisiert?

Wenn ein Entwickler einen KI-Agenten startet oder einen Service-Account anlegt, gibt es in der Regel kein Äquivalent zum HR-Onboarding-Workflow. Kein Approval-Gate. Keinen definierten Eigentümer. Keinen definierten Scope. Kein Ablaufdatum. Die Zugangsdaten existieren einfach... so.

Der GitGuardian State of Secrets Sprawl Report verzeichnete im Jahr 2025 insgesamt 28.649.024 neu exponierte Secrets in öffentlichen GitHub-Commits - ein Anstieg von 34 % gegenüber dem Vorjahr und der größte jährliche Zuwachs in der Geschichte des Reports. ^[4] Ein wesentlicher Treiber: KI-gestütztes Programmieren. Commits, die 2025 gemeinsam mit Claude Code auf öffentlichem GitHub erstellt wurden, enthielten Secrets mit etwa doppelt so hoher Rate wie der Basiswert. ^[4] Entwickler bauen Projekte auf, verdrahten Integrationen, testen API-Aufrufe und committen funktionierende Prototypen, bevor irgendjemand gefragt hat, wo die Zugangsdaten gespeichert werden sollen, wer sie verantwortet oder wie sie rotiert werden.

Das MCP-Ökosystem macht das konkret. Astrix Research analysierte über 5.200 einzigartige Open-Source-MCP-Server-Implementierungen und stellte fest, dass 88 % Zugangsdaten erfordern, aber mehr als die Hälfte (53 %) auf unsichere, langlebige statische Secrets wie API-Keys und Personal Access Tokens setzt - während moderne Authentifizierungsmethoden wie OAuth nur von 8,5 % der Server genutzt werden. ^[5] Gleichzeitig fehlte bei fast 38 % der mehr als 500 MCP-Server, die Adversa AI im April 2026 scannte, jegliche Authentifizierung. ^[6]

Was ein Machine-Joiner-Prozess erfordert:

• Autorisierungs-Gate - wer hat die Erstellung dieses Agenten genehmigt, und welche fachliche Begründung wurde dokumentiert?
• Eigentümerzuweisung - eine namentlich genannte Person, die für das Verhalten und den Lifecycle der Identität verantwortlich ist
• Scope-Definition - explizite, minimale Berechtigungen, die der tatsächlichen Funktion des Agenten entsprechen (nicht "Admin", weil es einfacher war)
• Ablauf-Policy - eine Standard-TTL für Zugangsdaten, deren Verlängerung eine erneute Genehmigung erfordert
• Registry-Eintrag - die Identität wird in einem zentralen Inventar mit Eigentümer, Zweck, Authentifizierungsmethode, Berechtigungen und Erstellungsdatum erfasst

Ohne diese fünf Elemente bei der Entstehung haben Sie keine verwaltete Identität. Sie haben Zugangsdaten in freier Wildbahn.

Phase 2 - Das Mover-Problem: Scope-Drift und Privilege Accumulation

Das klassische Mover-Problem bei Menschen ist gut dokumentiert: Wenn ein Mitarbeiter die Rolle wechselt, werden neue Zugriffe hinzugefügt, aber alte selten entfernt. Privilege Creep wächst in beide Richtungen - horizontal (mehr Applikationen) und vertikal (höhere Berechtigungsstufen) - mit jedem Wechsel.

Machine-Identities haben dasselbe Problem, nur verstärkt. Ein Agent, der ursprünglich Slack-Nachrichten für einen Customer-Support-Workflow lesen sollte, wird erweitert, um in Jira zu schreiben. Dann fügt jemand "nur für diesen Sprint" eine GitHub-Integration hinzu. Dann übernimmt ein neues Team den Agenten und ergänzt Salesforce-Zugriff. Jede Erweiterung ist für sich genommen begründet. Kumulativ hält der Agent nun Berechtigungen, die keinem einzelnen Menschen ohne formalen Access-Review gewährt würden.

OWASP stuft Privilege Escalation durch Scope Creep als MCP02:2025 ein - das zweitkritischste Risiko in MCP-Deployments - und stellt fest, dass kleine, kumulative Scope-Erweiterungen eine risikoarme Automatisierung in eine hochgradig gefährliche Angriffsfläche verwandeln können. ^[7] Der Blast Radius ist erheblich größer als bei menschlichen Accounts, weil KI-Agenten Sequenzen von Aktionen ausführen, externe APIs aufrufen, Sub-Agenten starten, Code schreiben und ausführen sowie zur Laufzeit dynamisch neue Berechtigungen erwerben können. ^[1]

Das Audit-Trail-Problem verschärft dies zusätzlich. Wenn ein KI-Agent eine Aktion mit gemeinsam genutzten Zugangsdaten ausführt, zeigen die Logs die Zugangsdaten - nicht den spezifischen Agenten oder die Entscheidung, die die Aktion ausgelöst hat. Regulatorisch verwertbare Audit-Trails werden damit nahezu unmöglich zu erstellen.

Was ein Machine-Mover-Prozess erfordert:

• Scope-Change-Approval - jede Berechtigungserweiterung wird als neues Autorisierungsereignis behandelt, nicht als stilles Konfigurations-Update
• Privilege Reconciliation - wenn sich der Zweck eines Agenten ändert, werden alte Scopes explizit entzogen, nicht nur ergänzt
• Drift Detection - kontinuierliches Monitoring auf Berechtigungserhöhungen gegenüber der dokumentierten Baseline des Agenten
• Per-Agent Identity Binding - keine gemeinsamen Service-Accounts über Agenten oder Teams hinweg; jeder Agent erhält eine eigene Identität, damit Scope-Änderungen zuordenbar sind
• Regelmäßige Entitlement-Reviews - Machine-Identities werden in Access-Certification-Zyklen einbezogen, nicht nur menschliche Accounts

Phase 3 - Das Leaver-Problem: Verwaiste Agenten und die Decommissioning-Lücke

Hier wird das Governance-Versagen zu einem direkten Sicherheitsrisiko. OWASP stuft unsachgemäßes Offboarding als das größte Risiko bei nicht-menschlichen Identitäten ein, weil veraltete Identitäten, die an abgekündigte Services gebunden sind, vergessen werden, aktiv bleiben und zu einem stillen Zugangspfad für Angreifer werden. ^[8]

Das Muster ist konsistent: Ein Projekt endet, eine Lieferantenbeziehung ändert sich, ein Entwickler verlässt das Unternehmen. Der Agent oder Service-Account, den er erstellt hat, bleibt bestehen. Nur 20 % der Organisationen verfügen über formale Prozesse für das Offboarding und den Entzug von API-Keys - und noch weniger haben Verfahren für deren Rotation. ^[9] Die H1-2025-Studie von Entro Security ergab, dass 47 % der NHIs seit mehr als einem Jahr unverändert geblieben waren. ^[3]

Die TeamPCP-Kampagne im März 2026 ist ein anschauliches Beispiel dafür, was passiert, wenn das Offboarding von Machine-Identities unvollständig ist. Ein autonomer Bot nutzte einen falsch konfigurierten GitHub-Actions-Workflow im Trivy-Projekt von Aqua Security aus, um ein privilegiertes Zugriffstoken zu stehlen. Aqua rotierte die Zugangsdaten - aber die Rotation war unvollständig, und der Angreifer behielt den Zugriff. ^[6] Mit den verbliebenen Zugangsdaten überschrieb der Angreifer 76 von 77 Trivy-Action-Versions-Tags, sodass sie auf bösartige Commits zeigten - jede CI/CD-Pipeline, die an diesem Tag Trivy ausführte, führte damit stillschweigend Credential-stealing-Malware aus.

Unvollständiges Offboarding ist kein theoretisches Risiko. Es ist der Angriffsvektor.

Was ein Machine-Leaver-Prozess erfordert:

• Decommission-Trigger - ein definiertes Ereignis (Projektabschluss, Lieferantenwechsel, Abgang des Eigentümers), das automatisch den Offboarding-Workflow initiiert
• Credential Revocation - alle zugehörigen Token, API-Keys und OAuth-Berechtigungen werden entzogen, nicht nur die primären Zugangsdaten
• Dependency Mapping - vor der Stilllegung werden alle Systeme identifiziert, die diese Identität aufrufen, damit nichts stillschweigend bricht
• Rotationsverifizierung - bestätigen, dass die Rotation vollständig abgeschlossen ist, nicht nur initiiert wurde (die Lektion aus TeamPCP)
• Audit-Nachweis - dokumentierter Beleg, dass die Identität stillgelegt wurde, wann und durch wen

Das Eigentümerproblem: Wer ist für eine Maschine verantwortlich?

Menschliche Identitäten haben klare Eigentümer - den Mitarbeiter selbst, seine Führungskraft, seinen HR-Datensatz. NHIs haben häufig geteilte oder unklare Eigentümerschaft, was die Durchsetzung von Verantwortlichkeit erschwert. ^[10] Das ist keine geringfügige operative Unannehmlichkeit. Es ist die Ursache jedes oben beschriebenen Lifecycle-Versagens.

Wenn kein Mensch für das Verhalten eines Agenten verantwortlich ist, wird niemand bemerken, wenn sein Scope driftet. Niemand wird die Stilllegung einleiten, wenn das Projekt endet. Niemand wird Zugangsdaten rotieren, wenn der verantwortliche Entwickler das Unternehmen verlässt. Die Identität wird zum Geist - aktiv, mit Zugangsdaten versehen und unüberwacht.

Das Governance-Modell für Machine-Identities muss für jede Identität im Registry sechs Fragen beantworten:

Wenn ein Feld leer ist, haben Sie keine Governance. Sie haben Inventar-Folklore.

Den Machine-JML-Lifecycle automatisieren

Der menschliche JML-Prozess funktioniert, weil er automatisiert ist - HRIS-Events lösen Provisionierungs-Workflows ohne manuellen Eingriff aus. Dasselbe Prinzip gilt für Machine-Identities, aber der Auslöser ist kein HRIS-Event. Es ist eine Policy-Engine.

Das Automatisierungsmodell spiegelt das menschliche JML wider, ersetzt aber HRIS-Signale durch policy-gesteuerte Events:

Genau das liefert Idens Ansatz für das Identity-Management für KI-Agenten: policy-gesteuerte Lifecycle-Automatisierung, die einheitlich auf menschliche und nicht-menschliche Identitäten angewendet wird - mit feingranularer Kontrolle bis auf Kanal-, Repository- und Projektebene, nicht nur grobe SCIM-Provisionierung, die den langen Schwanz der Machine-Zugangsdaten übersieht.

Die Machine-Identity-JML-Checkliste

Nutzen Sie dies als operativen Ausgangspunkt. Jede Machine-Identity in Ihrer Umgebung sollte jeden Punkt beantworten können.

Joiner (Entstehung)

• Erstellung durch eine namentlich genannte Person mit dokumentierter fachlicher Begründung genehmigt
• Eigentümer zugewiesen - eine konkrete Person, kein Team oder keine Rolle
• Berechtigungen auf die minimal erforderliche Funktion beschränkt, vor der Ausstellung überprüft
• Credential-TTL definiert; Verlängerung erfordert erneute Genehmigung
• Identität im zentralen Inventar mit allen sechs Governance-Feldern erfasst

Mover (Scope-Änderung)

• Berechtigungserweiterungen erfordern explizite Genehmigung, keine stillen Konfigurations-Updates
• Alte Scopes werden entzogen, wenn sich der Zweck ändert - nicht nur ergänzt
• Drift Detection aktiv gegen die genehmigte Berechtigungs-Baseline
• Per-Agent Identity Binding durchgesetzt - keine gemeinsamen Service-Accounts
• Machine-Identities in vierteljährliche Access-Certification-Zyklen einbezogen

Leaver (Stilllegung)

• Decommission-Trigger definiert für: Projektabschluss, Abgang des Eigentümers, TTL-Ablauf, Lieferantenwechsel
• Alle zugehörigen Zugangsdaten entzogen - Token, API-Keys, OAuth-Berechtigungen, Zertifikate
• Dependency Map vor der Stilllegung überprüft
• Rotation als vollständig abgeschlossen verifiziert, nicht nur initiiert
• Audit-Nachweis mit Zeitstempel, Akteur und Umfang der Stilllegung erstellt

Die Rechnung ist einfach. Nur 15 % der Organisationen sind sehr zuversichtlich, NHI-Angriffe verhindern zu können, während 69 % Bedenken dazu äußern. ^[9] Die Lücke zwischen Bedenken und Zuversicht ist eine Governance-Lücke - und es ist dieselbe Lücke, die das JML-Framework vor einem Jahrzehnt für menschliche Identitäten geschlossen hat.

Machine-Identities sind keine neue Kategorie von Problemen. Es ist dasselbe Lifecycle-Problem, angewendet auf eine Population, die zehnmal schneller wächst als Ihre menschliche Belegschaft - ohne HRIS, das Versäumnisse auffängt. Die Organisationen, die diese Lücke als erste schließen, werden es tun, indem sie dieselbe policy-gesteuerte, automatisierte Lifecycle-Disziplin, die sie bereits auf Menschen anwenden, auf Maschinen ausweiten - nicht indem sie ein separates, paralleles Programm für Maschinen aufbauen.