Non-Human Identity: die Agenten steuern, die für Sie handeln
Agenten authentifizieren sich als Maschinenidentitäten, nicht als Personen. Warum Non-Human Identity heute eine Kernkontrolle ist — und wie man sie inventarisiert, eingrenzt und rotiert.
Definition
Eine Non-Human Identity (NHI) ist die digitale Identität eines maschinellen Akteurs — eines Agenten, Dienstes oder Workloads — statt einer Person. Agenten authentifizieren sich mit Schlüsseln, Tokens oder Zertifikaten; das NHI-Management regelt, wie diese Credentials zugeordnet, eingegrenzt, rotiert und auditiert werden.
Jeder autonome Agent, der reale Arbeit leistet, muss nachweisen, wer er ist. Er tut das als Non-Human Identity — ein maschineller Akteur mit Schlüsseln und Tokens, keine Person mit Passwort. Diese Identitäten ernst zu nehmen, ist heute eine der wirkungsvollsten Kontrollen der Agenten-Sicherheit.
Warum passt menschliches IAM nicht?
Identitätsprogramme wurden für Menschen gebaut: Onboarding, Rollenwechsel, Offboarding, interaktive Logins, MFA. Ein Agent erfüllt keine dieser Annahmen. Er wird durch ein Deployment erzeugt, authentifiziert sich nicht-interaktiv gegen eine API und läuft womöglich lange weiter, nachdem das Team, das ihn baute, weitergezogen ist. Agenten an ein menschenzentriertes System anzuflanschen, lässt sie standardmäßig ungesteuert.
Das Ergebnis ist die Identitätskrise, die der Aufstieg von MCP offenlegte: Tausende Maschinen-Credentials — langlebig, zu weit gefasst und nicht zugeordnet.
| Dimension | Menschliche Identität | Non-Human Identity (Agent) |
|---|---|---|
| Erzeugt durch | Onboarding / HR | Ein Deployment oder einen anderen Agenten |
| Authentifiziert sich | Interaktiver Login plus MFA | Schlüssel, Tokens oder Zertifikate, nicht-interaktiv |
| Lebenszyklus | Eintritt, Wechsel, Austritt | Oft keiner; überdauert evtl. das Projekt |
| Typische Anzahl | Hunderte | Tausende, und wachsend |
| Standardmäßig gesteuert durch | IAM, Access Reviews | Meist nichts |
Die drei Versäumnisse
- Keine Zuordnung. Ein Credential, das niemandem gehört, wird von niemandem rotiert oder widerrufen. Jede Maschinenidentität braucht einen verantwortlichen Menschen oder ein Team.
- Zu weiter Geltungsbereich. Agenten erben weit mehr Zugriff, als ihre Aufgabe braucht, sodass eine Kompromittierung zum Vorfall wird. Grenzen Sie jede Identität auf Least Privilege ein.
- Langlebigkeit. Statische, langlebige Schlüssel sind eine dauernde Belastung. Bevorzugen Sie kurzlebige, automatisch rotierte Credentials.
Eine Kontrollschleife für Non-Human Identity
- Inventarisieren Sie jede Agenten- und Dienst-Identität und ihre Reichweite.
- Grenzen Sie jede auf das Minimum ein, pro Tool und pro Aktion.
- Rotieren Sie automatisch; beseitigen Sie statische Secrets, wo möglich.
- Autorisieren zur Laufzeit, damit der Besitz einer Identität nicht dem Handeln-Dürfen gleichkommt — siehe MCP-Sicherheit.
- Auditieren pro Identität mit signierten Aufzeichnungen, damit jede Aktion zuordenbar ist.
Warum das auch eine Governance-Kontrolle ist
Der EU AI Act und die DSGVO fragen im Kern: Wer hat das getan und durfte er das? Bei einem Agenten ist die Antwort eine Non-Human Identity. Ohne Zuordnung pro Identität lässt sich weder Aufsicht noch Rechenschaft nachweisen — siehe Governance. Identität ist der Punkt, an dem Sicherheit und Compliance dasselbe Projekt werden.
Beginnen Sie mit dem Inventar. Zu benennen, was in Ihrem Auftrag handelt, ist die Voraussetzung, es zu kontrollieren. Begriffe stehen im Glossar.
Häufige Fragen
Warum können wir Agenten nicht mit unserem bestehenden IAM verwalten?
Die meisten Identitätsprogramme beruhen auf zwei Annahmen, die Agenten verletzen: dem menschlichen Lebenszyklus aus Eintritt, Wechsel und Austritt sowie interaktiven Logins mit Passwort und MFA. Ein Agent hat beides nicht. Er wird durch ein Deployment statt einen HR-Prozess erzeugt, authentifiziert sich nicht-interaktiv gegen eine API mit Schlüssel oder Token und kann lange weiterlaufen, nachdem das Team, das ihn baute, weitergezogen ist — es gibt also kein Austrittsereignis, das ein Aufräumen auslöst. Rollenbasierte Modelle setzen zudem voraus, dass hinter jeder Identität eine Person steht, während ein Agent viele kurzlebige Identitäten erzeugen oder eine über Aufgaben teilen kann. Die praktische Folge: Agenten an ein menschenzentriertes IAM anzuflanschen, lässt sie standardmäßig ungesteuert — frei erzeugt, selten geprüft, nie offgeboardet. Sie brauchen Eigentum, Geltungsbereich, Rotation und Audit für Maschinen modelliert, und genau das leistet NHI-Management.
Was macht Non-Human Identities riskant?
Skalierung gepaart mit Vernachlässigung. Organisationen häufen Maschinen-Credentials weit schneller an als menschliche Konten — jeder Dienst, jede Integration und jeder Agent braucht mindestens eines — und weil kein Eintritt-Wechsel-Austritt-Prozess sie steuert, sind sie meist langlebig, weit gefasst und niemandem zugeordnet. Jede dieser Eigenschaften ist für sich eine Belastung; zusammen sind sie der klassische Wegbereiter eines Einbruchs. Ein einziger geleakter oder kompromittierter Schlüssel gibt einem Angreifer genau das, was der Agent durfte, und das ist meist weit mehr, als die unmittelbare Aufgabe verlangte — und weil dasselbe Credential oft über mehrere Tools wiederverwendet wird, kann ein Leak kaskadieren. Die Gefahr verstärkt die Unsichtbarkeit: Die meisten Teams können nicht sagen, wie viele Maschinenidentitäten sie haben oder was jede erreicht, sodass ein verwaistes, überprivilegiertes Credential monatelang unbemerkt bleiben kann. Das Risiko ist selten ein exotischer Exploit; es ist ein gewöhnlicher vergessener Schlüssel mit zu viel Macht.
Was ist der erste Schritt?
Ein Inventar, ausnahmslos, denn jede spätere Kontrolle hängt davon ab. Listen Sie jede Agenten- und Dienst-Identität, die Credentials, die sie hält, wer sie besitzt, was sie erreicht und wann sie zuletzt genutzt wurde. Man kann nicht eingrenzen, rotieren oder widerrufen, was man nie erfasst hat, und fast jede Organisation, die diese Übung durchführt, findet Überraschungen — Schlüssel ohne Eigentümer, Credentials, die beim Projektende hätten widerrufen werden müssen, Identitäten mit weit mehr Zugriff, als sich jemand erinnert, gewährt zu haben. Das Inventar verwandelt zudem eine vage Sorge in eine priorisierte Arbeitsliste: Sobald Sie die langlebigen, zu weit gefassten und nicht zugeordneten Identitäten sehen, beheben Sie diese zuerst. Es ist unglamourös und oft mühsam, doch zu benennen, was in Ihrem Auftrag handelt, ist die Voraussetzung der Steuerung — und es zahlt sich meist schon beim ersten Durchgang aus, indem es eine Handvoll wirklich gefährlicher Credentials zutage fördert.
Wie unterscheidet sich eine Non-Human Identity von einem Dienstkonto?
Ein Dienstkonto ist eine Art Non-Human Identity, aber der Begriff NHI ist bewusst breiter und spiegelt, wie sehr sich die Landschaft verändert hat. Klassische Dienstkonten waren relativ wenige, langlebig und an eine bestimmte Anwendung gebunden, und viele Organisationen verwalteten sie — wenn auch unvollkommen — als bekannten Bestand. Moderne Non-Human Identities umfassen Agenten, Workloads, CI-Jobs, Funktionen und ephemere Tokens, die ständig, oft automatisch, erzeugt und zerstört werden, in einem Maßstab, der das alte Dienstkonten-Inventar in den Schatten stellt. Agenten als bloß weitere Dienstkonten zu behandeln, scheitert meist, weil die alten manuellen Prozesse Menge und Fluktuation nicht überstehen. Die NHI-Sicht behält den richtigen Instinkt — Eigentümer benennen, eng eingrenzen, rotieren, auditieren —, setzt aber Automatisierung, kurze Lebensdauern und Erzeugung in Maschinengeschwindigkeit als Norm voraus. Kurz: Jedes Dienstkonto ist eine NHI, aber nicht jede NHI sieht aus oder verhält sich wie die Dienstkonten, um die herum die meisten IAM-Tools entworfen wurden.