Publiziert: Zuletzt aktualisiert:

Maschinen- und Agentenidentitäten

Jede technische Handlung braucht eine Identität

Jede Maschine, jede Workload und jeder Software-Agent handelt unter einer Identität. Wenn diese Akteure als eigene Principals behandelt werden, also begrenzt, zurechenbar und widerrufbar, wird Non-Human Identity zur Erweiterung von Identity/SSO und Zero Trust.

Nicht-menschliche Identitäten sind keine Nebenform von Benutzerkonten. Sie tragen Deployments, Schnittstellen, Pipelines, Integrationen, Automatisierung und zunehmend KI-Agenten. Je autonomer solche Akteure handeln, desto wichtiger wird die Trennung zwischen Identität, Berechtigung und Kontext.

Warum Non-Human Identity zählt

Non-Human Identity beantwortet zuerst die Frage nach der Zurechenbarkeit: Welcher technische Akteur hat welche Handlung ausgeführt? Ohne eigene Identität verschwinden Aktionen hinter geteilten Schlüsseln, generischen Servicekonten oder implizitem Vertrauen zwischen Systemen. Das macht Audits schwach und Vorfälle schwer rekonstruierbar.

Der zweite Punkt ist Least Privilege. Jede Maschine, jede Workload und jeder Agent braucht nur die Rechte, die zur aktuellen Aufgabe passen. Ein Build-Job braucht andere Rechte als ein produktiver Service, ein Datenimport andere als ein Agent, der Dokumente klassifiziert. Gemeinsame Konten verwischen diese Grenzen und machen Rechte breiter, als die Aufgabe verlangt.

Der reale Aufwand liegt im Betrieb: Identitäten müssen bereitgestellt, an Workloads gebunden und widerrufen werden; Tokens, Schlüssel und Zertifikate müssen rotiert und überwacht werden. Jede nicht-menschliche Identität braucht eine benannte fachliche oder technische Owner-Rolle, die Zweck, Rechte, Review-Zyklus, Rotation und Widerruf verantwortet. Sonst bleiben alte Tokens und Servicekonten als offene Zugriffe bestehen. Non-Human Identity ist deshalb weniger ein Login-Thema als ein Betriebsmodell für technische Akteure.

Für jede technische Identität müssen mindestens Owner, Zweck, Laufzeit, erlaubte Ressourcen, Scopes, Rotationsregel und Logspur dokumentiert sein.

Für einen Verein heisst das konkret: Ein Wissensassistent, ein Import-Skript oder eine Website-Automation erhält ein eigenes Konto mit klar begrenzten Rechten. Wird der Zweck nicht mehr gebraucht, wird dieser Zugriff wieder abgeschaltet.

Das Schichtenmodell

Eine belastbare Architektur trennt drei Schichten, die im Alltag oft vermischt werden.

  1. Principal: Wer handelt. Der Principal ist der technische Akteur, dessen Identität authentifiziert wird: Maschine, Workload, Service, Pipeline oder Software-Agent. Diese Schicht beantwortet die Frage, ob der Akteur echt ist.
  2. Autorisierung: Was erlaubt ist. Rollen, Gruppen, Policies und Scopes bestimmen, welche Ressourcen der Principal nutzen darf. Diese Schicht beantwortet die Frage, ob die Handlung erlaubt ist.
  3. Kontext: Wo und wie es passiert. Laufzeitumgebung, Deployment, Gerät, Netzwerk, Uhrzeit, Aufgabe und Freigabe sind Metadaten zur Entscheidung und Nachvollziehbarkeit. Diese Schicht beantwortet die Frage, unter welchen Bedingungen die Handlung stattgefunden hat.

Der Fehler entsteht, wenn der Einsatzort zur Identität gemacht wird. Eine Identität wie production-importer-eu-west wirkt zunächst praktisch, koppelt aber den Principal an eine Momentaufnahme der Infrastruktur. Sobald die Workload verschoben, repliziert oder anders betrieben wird, passt der Name nicht mehr. Standort, Umgebung und Ausführungsart sind Attribute. Sie gehören in den Kontext, nicht in die Identität.

Besser ist ein stabiler Principal wie invoice-importer. Umgebung, Region und Deployment stehen als Kontextattribute im Token, in der Policy oder im Log.

flowchart LR
    P["Principal<br/>Maschine, Workload, Agent"] --> IDP["Identity-Provider<br/>Authentifizierung"]
    IDP --> AUTH["Rollen, Gruppen, Policies<br/>Autorisierung"]
    AUTH --> RES["Ressourcen<br/>APIs, Daten, Systeme"]
    RES --> LOG["Audit-Log<br/>Handlung und Ergebnis"]
    CTX["Kontext-Metadaten<br/>Ort, Laufzeit, Aufgabe"] -.-> AUTH
    CTX -.-> LOG

Das Modell hält die Identität stabil und die Entscheidung flexibel. Der gleiche Principal kann unter unterschiedlichen Kontexten unterschiedlich bewertet werden, ohne dass für jeden Standort oder jede Laufzeit eine neue Identität erfunden wird.

KI-Agenten als Principals

KI-Agenten machen das Thema sichtbar, weil sie nicht nur lesen, sondern Aufgaben ausführen: Dokumente bearbeiten, Tickets anlegen, Code vorschlagen, Commits vorbereiten oder Arbeit an andere Akteure übergeben. Jeder Agent braucht dafür eine eigene Identität mit begrenzten Rechten und nachvollziehbaren Scopes. Aktionen bleiben so über Dokumente, Commits, Aufgaben und Freigaben hinweg zurechenbar.

Diese Zurechenbarkeit ersetzt keine menschliche Verantwortung. Ein Agent kann in einer RASCI-Matrix Responsible, Consulted oder Informed sein: Er führt Arbeit aus, liefert Kontext oder wird über Ereignisse informiert. Accountable bleibt eine benannte menschliche Rolle. Nur ein Mensch kann die Rechenschaft für Ergebnis, Freigabe und Risiko tragen.

In der Praxis führt das zu einfachen Regeln: kein geteiltes Agentenkonto, keine pauschalen Adminrechte, keine langlebigen Geheimnisse ohne Rotation, keine Aktion ohne Logspur. Agenten werden wie andere technische Principals behandelt, aber wegen ihrer Handlungstiefe strenger beobachtet.

Referenzen

Verwandte Themen

KI fragen

Diese Links öffnen externe KI-Dienste, die Unterhaltung und deren Inhalt werden dabei an den jeweiligen Anbieter übertragen.