Eine Frage, die die meisten Führungsteams nicht beantworten können
Fragen Sie eine CTO oder eine CISO, wie viele Mitarbeiter ihr Unternehmen hat, kommt die Antwort sofort. Fragen Sie dieselbe Person, wie viele nicht-menschliche Identitäten gerade in ihrer Umgebung existieren, folgt in den meisten Organisationen Schweigen. Dienstkonten. API-Schlüssel. OAuth-Token. Automatisierungsskripte. Zugangsdaten für CI/CD-Pipelines. Und zunehmend autonome KI-Agenten, die sich anmelden, handeln und ganz eigenständig weitere Agenten erzeugen.
Branchenstudien aus dem Jahr 2026 zeichnen ein unbequemes Gesamtbild. Je nach Studie übertreffen nicht-menschliche Identitäten menschliche mittlerweile im Verhältnis von 80 zu 1 in einem typischen Unternehmen bis hin zu deutlich über 140 zu 1 in cloud-nativen Umgebungen, und dieses Verhältnis hat sich in weniger als zwei Jahren annähernd verdoppelt. Manche Analysen setzen den durchschnittlichen Cloud-Bestand eines Unternehmens bei über einer Viertelmillion nicht-menschlicher Identitäten an, von denen die große Mehrheit mehr Rechte besitzt, als die jeweilige Aufgabe tatsächlich erfordert. KI-Agenten sind das am schnellsten wachsende Segment dieser Population, mit einem prognostizierten Wachstum, das sowohl Maschinenidentitäten im Allgemeinen als auch den menschlichen Personalbestand deutlich übertrifft.
Das ist kein Nischenthema der Infrastruktur. Es ist die Identitätsebene unter jeder digitalen Transformation, jedem KI-Einführungsprogramm und jeder Cloud-Migration, die gerade läuft, und in den meisten Organisationen besitzt niemand die Verantwortung dafür durchgängig.
Die unbequeme Wahrheit: Die am schnellsten wachsende Kategorie von „Benutzern" in Ihrem Unternehmen ist gerade keine Person. Sie nimmt an keinem Onboarding teil, wird bei Projektende nicht offboarded und taucht in keinem Organigramm auf. Sie sammelt sich einfach an.
Wie es dazu kam: drei Wellen der Automatisierung
Nicht-menschliche Identitäten sind nicht neu. Was sich geändert hat, ist das Tempo, die Autonomie und das Ausmaß der beteiligten Berechtigungen.
Welle 1: Dienstkonten und Skripte
Die erste Welle war überschaubar: Ein geplanter Job benötigt ein Datenbank-Anmeldedatum, ein Monitoring-Tool braucht Lesezugriff auf Logs, ein Backup-Skript benötigt Schreibzugriff auf Speicher. Diese Konten wurden bewusst angelegt, meist einzeln, und obwohl sie häufig überprivilegiert und selten rotiert wurden, hatte zumindest ein Mensch die bewusste Entscheidung getroffen, jedes einzelne davon zu erstellen.
Welle 2: Cloud-native und CI/CD-Wildwuchs
Die zweite Welle kam mit Microservices, Containern und kontinuierlicher Bereitstellung. Jeder Dienst muss sich nun gegenüber jedem anderen authentifizieren. Jede Pipeline-Stufe benötigt eigene Zugangsdaten. Infrastructure-as-Code-Vorlagen erzeugen als Nebeneffekt eines Deployments neue Rollen und Dienstprinzipale, oft ohne dass jemand die zugehörigen Berechtigungen prüft. Diese Welle hat die Anzahl nicht-menschlicher Identitäten von „mehr als die Belegschaft" auf „um Größenordnungen mehr als die Belegschaft" getrieben.
Welle 3: Agentische KI
Die dritte Welle findet gerade jetzt statt und unterscheidet sich qualitativ von den ersten beiden. Ein KI-Agent ist kein statisches Anmeldedatum, das ruhig in einer Konfigurationsdatei liegt. Er ist ein autonomer Akteur, der Berechtigungen dynamisch zur Laufzeit anfordert, aus eigener Initiative externe APIs aufruft, Code schreibt und ausführt und in zunehmend gängigen Architekturen Unteragenten erzeugt, um Teile seiner Aufgabe zu erledigen. Ein einziger genehmigter KI-Coding-Assistent, Deployment-Agent oder Kundenservice-Bot kann eine Kaskade nachgelagerter Identitäten erzeugen, die niemand ausdrücklich bereitgestellt hat und die niemand ausdrücklich verfolgt.
Genau auf dieser Ebene ist die Governance am weitesten hinter der Realität zurückgeblieben. Aktuelle Branchenumfragen zeigen, dass ein bedeutender Anteil der Organisationen die Erstellung KI-bezogener Identitäten überhaupt nicht verfolgt, und eine große Mehrheit der Sicherheitsverantwortlichen gibt zu, kein Vertrauen in ihre Fähigkeit zu haben, einen Angriff zu verhindern, der eine solche Identität missbraucht.
Warum das ein Geschäftsproblem ist, nicht nur eine Fußnote der Sicherheitsabteilung
Es liegt nahe, die Ausbreitung nicht-menschlicher Identitäten unter „soll die Sicherheitsabteilung regeln" abzulegen. Diese Einordnung verkennt das Ausmaß der Exposition. Das Thema liegt genau an der Schnittstelle von Technologiearchitektur, operativer Resilienz und Kostenkontrolle, und genau deshalb gehört es auf dieselbe Tagesordnung wie Ihre Cloud-Strategie und Ihre KI-Roadmap, nicht in einen separaten Compliance-Ordner.
Ein Architekturproblem
Wie Sie Ihre KI-Agenten, Ihre Microservices und Ihre Cloud-Infrastruktur gestalten, bestimmt, wie viele nicht-menschliche Identitäten Sie erzeugen und welchen Umfang an Rechten jede davon trägt. Teams, die agentische KI ohne vorhandene Identitätsarchitektur einführen, treffen faktisch jede Woche Hunderte ad hoc Entscheidungen zur Zugriffskontrolle, ohne Überprüfungsprozess. Das ist ebenso sehr ein Fehler in der Technologiegestaltung wie ein Sicherheitsfehler, und wir stellen ihn wiederholt fest, wenn wir Cloud-Umgebungen und CI/CD-Pipelines von Kunden prüfen.
Ein Problem der operativen Resilienz
2026 hat bereits eine Erinnerung geliefert: Die zugrunde liegende Cloud-Infrastruktur, auf die sich alle verlassen, ist nicht unfehlbar. Ein Berechtigungsfehler in der Abrechnungskonsole eines großen Hyperscalers legte kontoübergreifende Kosten- und Nutzungsdaten gegenüber Kunden offen, die diese nie hätten sehen dürfen. Europäische Regulatoren haben darauf reagiert, indem sie die größten Cloud-Anbieter formell als kritische Drittparteien einstufen, die einer direkten Aufsicht über die operative Resilienz unterliegen, genau weil ein so großer Teil der Wirtschaft, einschließlich weiter Teile des Finanzsektors, inzwischen von einer Handvoll Anbieter abhängt. Jede nicht-menschliche Identität, die Ihre Organisation in dieser gemeinsam genutzten Infrastruktur erzeugt, ist ein Faden, der Ihre operative Resilienz mit deren Resilienz verbindet. Je mehr solcher Fäden ohne Verantwortlichen existieren, desto schwerer wird es, eine einfache regulatorische Frage zu beantworten: Was passiert mit unserem Betrieb, wenn dieses Anmeldedatum, dieser Anbieter oder dieser Dienstleister ausfällt?
Ein Kostenproblem
Jede unverwaltete nicht-menschliche Identität, jedes verwaiste Dienstkonto, jeder KI-Agent, der in einer Wiederholungsschleife still eine kostenpflichtige API aufruft, ist zugleich ein blinder Fleck bei der Kostenkontrolle. Finanzabteilungen berichten zunehmend von KI-bezogenen Cloud-Ausgaben, die schneller gewachsen sind als jedes Modell vorhergesagt hatte, nicht zuletzt weil niemand ein sauberes Inventar dessen besitzt, was tatsächlich was aufruft.
Ein Problem der Software-Lieferkette
Im selben Zeitraum entstand eine kritische, weitverbreitet ausgenutzte Schwachstellenkette, die Hunderte Millionen auf gängigen Plattformen aufgebaute Websites betrifft, sowie ein monatlicher Herstellerpatchzyklus, der weit über 500 einzelne Schwachstellen adressierte. Jedes dieser Systeme authentifiziert sich gegenüber etwas anderem mittels einer nicht-menschlichen Identität. Patch-Management, sichere Entwicklungspraxis und Identitätsgovernance sind keine drei getrennten Disziplinen; es sind drei Blickwinkel auf ein und dieselbe zugrunde liegende Exposition.
Wie ein Ausfall in der Praxis tatsächlich aussieht
Ausfälle nicht-menschlicher Identitäten sehen selten wie ein Hollywood-Hack aus. Sie wirken banal, bis genau der Moment kommt, in dem sie es nicht mehr sind.
Szenario 1: Der überprivilegierte Coding-Assistent
Ein Entwicklungsteam führt einen KI-Coding-Assistenten mit Zugriff auf die Quellcode-Repositories des Unternehmens ein, um die Lieferung zu beschleunigen, eine für sich genommen durchaus vernünftige Entscheidung. Dem Assistenten wird „um Reibung zu vermeiden" ein weitreichendes Zugriffstoken gewährt, statt eines eng auf die Aufgabe zugeschnittenen. Monate später legt eine fehlkonfigurierte Integration oder ein kompromittierter Entwickler-Laptop dieses Token offen. Da es nie eingeschränkt wurde, umfasst der Wirkungsradius nicht ein Repository, sondern jedes Repository, auf das der Assistent zugreifen konnte, plus jedes darin hartkodierte Geheimnis. Allein Scans öffentlicher Repositories fanden 2025 zig Millionen offengelegter Geheimnisse, und KI-gestützte Coding-Tools haben dieses Leck messbar beschleunigt, genau weil Agenten schnell darin sind, Anmeldedaten zu finden und wiederzuverwenden, bei denen ein menschlicher Entwickler vielleicht innegehalten hätte.
Szenario 2: Der stille Unteragent
Eine Organisation setzt einen autonomen Agenten ein, um Kundensupport-Tickets zu sichten und weiterzuleiten. Um einen Teil der Anfragen zu bearbeiten, ist der Agent so ausgelegt, dass er einen spezialisierten Unteragenten mit Zugriff auf Abrechnungssysteme erzeugt. Niemand registriert den Unteragenten als eigenständige Identität, sodass er die weitreichenden Berechtigungen seines übergeordneten Agenten erbt, statt eines eng zugeschnittenen eigenen Satzes. Achtzehn Monate später deckt ein interner Audit auf, dass der Unteragent die ganze Zeit aktiv war, seine Berechtigungen nie überprüft wurden und niemand in der Organisation mit Sicherheit sagen kann, wer dafür verantwortlich ist, worauf er zugegriffen hat.
Szenario 3: Die vergessene Drittanbieter-Integration
Eine Finanzabteilung verbindet ein Tabellenkalkulations-Automatisierungstool über einen API-Schlüssel mit einer Cloud-Buchhaltungsplattform, einmalig erzeugt während eines Proof-of-Concept vor zwei Jahren. Der Projektverantwortliche hat das Unternehmen inzwischen verlassen. Der Schlüssel funktioniert noch immer. Er wurde nie rotiert, nie auf reinen Lesezugriff beschränkt und nie einem Verantwortlichen zugeordnet, der einen Missbrauch bemerkt hätte. Genau diese Art verwaister Anmeldedaten haben aktuelle Vorfälle bei großen Beratungsunternehmen und Support-Plattformen gezeigt, nach denen Angreifer aktiv suchen: nicht die Haustür, sondern die Nebentür, von der niemand mehr wusste, dass sie unverschlossen war.
Warum klassisches Identitätsmanagement dieses Problem nicht löst
Die meisten Programme für Identitäts- und Zugriffsmanagement wurden für Menschen konzipiert: Eine Person tritt ein, ein Vorgesetzter genehmigt den Zugriff, die Personalabteilung löst das Offboarding aus, und periodische Zugriffsüberprüfungen erfassen Abweichungen. Wendet man dieses Modell auf nicht-menschliche Identitäten an, bricht es bei fast jeder Annahme zusammen.
- Es gibt keinen HR-Auslöser. Ein Dienstkonto oder ein KI-Agent wird nicht durch einen von jemandem überwachten Prozess „eingestellt" oder „gekündigt". Es wird durch ein Deployment-Skript erzeugt und überlebt oft das Projekt, das Team oder sogar die Anbieterbeziehung, die es begründet hat.
- Multi-Faktor-Authentifizierung greift nicht. Eine Maschine kann um 2 Uhr nachts nicht nach einem zweiten Faktor gefragt werden. Nicht-menschliche Identitäten stützen sich typischerweise auf statische Geheimnisse, weshalb hier Secrets Management, nicht Passwortrichtlinien, die entscheidende Kontrolle ist.
- Verantwortlichkeit wird bei der Erstellung selten zugewiesen. Ein menschliches Konto hat von Tag eins einen benannten Eigentümer. Ein Dienstprinzipal, der als Nebeneffekt einer Infrastrukturvorlage entsteht, hat das häufig nicht, und wenn irgendwann jemand fragt „wem gehört das", lautet die ehrliche Antwort oft „das weiß niemand".
- Berechtigungen werden dynamisch angefordert, nicht einmalig bereitgestellt. Ein autonomer Agent kann zur Laufzeit neue Berechtigungen erwerben, während er Aufgaben aneinanderreiht, was bedeutet, dass eine heute durchgeführte Zugriffsüberprüfung binnen Tagen erheblich veraltet sein kann.
Ein praxistaugliches Governance-Framework für nicht-menschliche Identitäten
Wir arbeiten mit Kunden über Technologie- und Sicherheitsfunktionen hinweg zusammen, um diese Lücke mit einem Framework zu schließen, das um fünf praktische Dimensionen herum aufgebaut ist, bewusst so gestaltet, dass ein Technologieteam und ein Sicherheitsteam es gemeinsam umsetzen können statt in getrennten Arbeitssträngen.
Dimension 1: Entdeckung und Inventar
Man kann nicht steuern, was man nicht sieht. Ausgangspunkt ist immer ein vollständiges Inventar: jedes Dienstkonto, jeder API-Schlüssel, jede OAuth-Berechtigung, jeder Dienstprinzipal und jeder KI-Agent, über alle genutzten Cloud-Konten, SaaS-Plattformen und CI/CD-Systeme hinweg. Die meisten Organisationen, die diese Übung zum ersten Mal durchführen, sind über die Anzahl überrascht, und selten angenehm.
Dimension 2: Eigentümerschaft und Lebenszyklus
Jede nicht-menschliche Identität sollte einen benannten menschlichen oder Team-Eigentümer, einen dokumentierten Zweck und einen definierten Lebenszyklus haben: ein Erstellungsdatum, ein geplantes Überprüfungsdatum und einen Deprovisionierungsauslöser, der an das Projekt oder System gebunden ist, das sie unterstützt. Eine Identität ohne Eigentümer ist eine Identität, deren Missbrauch niemand bemerken wird.
Dimension 3: Geringstes Privileg und Just-in-Time-Zugriff
Beschränken Sie sich standardmäßig auf den engsten Umfang, den eine Aufgabe erfordert, und bevorzugen Sie kurzlebige, Just-in-Time bereitgestellte Anmeldedaten gegenüber langlebigen statischen, wo immer die Architektur dies zulässt. Für KI-Agenten bedeutet das speziell explizite Berechtigungsgrenzen pro Agent und pro Unteragent, wobei Aktionen mit hoher Auswirkung standardmäßig einer menschlichen Genehmigung unterliegen statt automatisch gewährt zu werden.
Dimension 4: Secrets Management und Rotation
Hartkodierte Anmeldedaten in Quellcode, Konfigurationsdateien oder CI/CD-Pipelines sollten als bevorstehender Vorfall behandelt werden, denn die Daten zeigen durchgängig, dass genau das der Fall ist. Ein verwalteter Secrets-Tresor mit automatisierter Rotation schließt die größte einzelne Lücke, die wir in Kundenumgebungen sehen.
Dimension 5: Überwachung und Verhaltens-Baselines
Die Überwachung menschlicher Identitäten sucht nach anomalen Anmeldungen. Die Überwachung nicht-menschlicher Identitäten muss nach anomalem Verhalten suchen: ein Dienstkonto, das plötzlich außerhalb seines üblichen Musters auf Daten zugreift, ein KI-Agent, der APIs aufruft, die er nie zuvor verwendet hat, ein Anmeldedatum, das sich von einem unerwarteten Ort oder in unerwartetem Umfang authentifiziert. Genau hier verschmelzen Cyber-Überwachung und KI-Governance tatsächlich zu einer einzigen Fähigkeit.
Wo Sie in der Praxis anfangen sollten
- Führen Sie eine Erkennung nicht-menschlicher Identitäten über Ihren gesamten Cloud- und SaaS-Bestand durch. Betrachten Sie das erste Ergebnis als Basislinie, nicht als Ziel; es geht darum, die wahre Anzahl zu kennen, bevor Sie versuchen, sie zu reduzieren.
- Identifizieren und beheben Sie zuerst verwaiste Anmeldedaten. Konten ohne klaren Eigentümer sind die risikoreichste, aufwandsärmste Korrektur: deaktivieren, rotieren oder löschen.
- Machen Sie die Zuweisung von Eigentümerschaft künftig zur zwingenden Voraussetzung. Kein neues Dienstkonto, keine neue Integration und kein neuer KI-Agent sollte ohne benannten Eigentümer und dokumentierten Zweck bereitgestellt werden, durchgesetzt durch Ihren Deployment-Prozess, nicht durch ein Richtliniendokument, das niemand liest.
- Binden Sie die Bereitstellung von KI-Agenten in denselben Governance-Prozess ein wie jedes andere Produktivsystem. Würde ein neuer Microservice eine Architekturprüfung erfordern, sollte das auch für einen neuen KI-Agenten mit Systemzugriff gelten.
- Setzen Sie einen Secrets-Manager ein, falls noch nicht geschehen. Dies ist einer der Schritte mit dem höchsten Ertrag und der geringsten Störung, der verfügbar ist, und sollte nicht auf die Konzeption eines umfassenderen Programms warten.
- Erweitern Sie die Überwachung auf nicht-menschliches Verhalten, nicht nur auf menschliche Anmeldungen. Wenn Ihr aktueller Überwachungsstapel die Frage „was hat dieses Dienstkonto diese Woche anders gemacht" nicht beantworten kann, ist das eine Lücke, die es zu schließen lohnt, bevor sie durch einen Vorfall geprüft wird.
Der luxemburgische und europäische Kontext
Für Organisationen, die im luxemburgischen Finanzdienstleistungs-, Fondsverwaltungs- und Dienstleistungssektor tätig sind, ist die Governance nicht-menschlicher Identitäten keine abstrakte Best Practice, sie überschneidet sich zunehmend direkt mit aufsichtsrechtlichen Erwartungen. Die IKT-Risikomanagementanforderungen von DORA gelten für die Systeme und Anmeldedaten, auf die sich Ihre KI-Agenten und automatisierten Pipelines stützen, nicht nur für die Anwendungen, bei denen sich Ihre Mitarbeiter manuell anmelden. Während europäische Regulatoren die Aufsicht über die Hyperscale-Cloud-Anbieter formalisieren, die den Großteil dieser Infrastruktur beherbergen, und während das breitere Streben der EU nach technologischer Souveränität neu gestaltet, wo sensible Workloads laufen dürfen, sind Organisationen, die bereits ein sauberes, mit Eigentümern versehenes Inventar ihrer nicht-menschlichen Identitäten besitzen, schlicht besser aufgestellt, um die Fragen zu beantworten, die ein Regulator, ein Prüfer oder ein Versicherer irgendwann stellen wird.
Dasselbe gilt für die wachsende Zahl luxemburgischer Unternehmen, die die KI-Einführung beschleunigen, unter anderem über das Förderprogramm SME Package AI. Ein gut gesteuerter KI-Einsatz und ein gut gesteuerter Bestand nicht-menschlicher Identitäten sind in der Praxis dasselbe Projekt, nur aus zwei Blickwinkeln betrachtet.
Technologie und Sicherheit, nicht Technologie oder Sicherheit
Die Governance nicht-menschlicher Identitäten liegt genau dort, wo auch unsere eigene Praxis ansetzt: an der Schnittstelle zwischen dem Aufbau der Technologie (Cloud-Architektur, DevSecOps-Pipelines, Bereitstellung von KI-Agenten) und deren Absicherung (Identitätsgovernance, Risikobewertung, Überwachung). Diese als getrennte, von getrennten Teams betriebene Projekte zu behandeln, ist genau der Weg, auf dem Organisationen am Ende bei 250.000 unverwalteten Identitäten landen und keine klare Antwort auf die Frage „wem gehört das" haben.
Wenn Ihre Organisation KI-Agenten einführt, ihre Cloud-Infrastruktur ausbaut oder derzeit schlicht nicht sagen kann, wie viele nicht-menschliche Identitäten in ihrer Umgebung existieren, ist das ein Gespräch, das es sich lohnt zu führen, bevor ein Audit, ein Vorfall oder ein Regulator die Frage erzwingt. Wir helfen Ihnen gerne dabei, die Exposition zu erfassen und ein Governance-Programm aufzubauen, das zu der Art passt, wie Ihre Technologieteams tatsächlich arbeiten.
