Wofür IAM verantwortlich ist
IAM ist kein einzelnes Produkt, sondern eine Steuerungsebene, die fortlaufend zwei Fragen beantwortet: Wer ist das? und Was darf diese Person tun? Die erste ist Authentifizierung — die Überprüfung, dass eine Identität die ist, die sie zu sein vorgibt. Die zweite ist Autorisierung — die Entscheidung, welche Ressourcen und Aktionen diese verifizierte Identität erreichen darf. Alles andere in IAM existiert, um diese beiden Entscheidungen zuverlässig, prüfbar und widerrufbar zu machen.
Ein ausgereiftes IAM-Programm ist aus mehreren ineinandergreifenden Komponenten aufgebaut.
Identity-Lifecycle-Management
Jede Identität hat einen Lebenszyklus: Sie wird bereitgestellt (provisioniert), wenn eine Person eintritt oder ein Dienst erstellt wird, sie wird bei Rollenänderungen angepasst und deprovisioniert, wenn der Zugriff endet. Provisioning gewährt den initialen Satz an Berechtigungen; Deprovisioning entfernt sie. Die Lücke zwischen dem Zeitpunkt, zu dem der Zugriff widerrufen werden sollte, und dem, zu dem er tatsächlich widerrufen wird — verwaiste Konten, verbleibende Dienstanmeldedaten — ist eine der häufigsten Ursachen für Sicherheitsvorfälle. Automatisierte Joiner-Mover-Leaver-Workflows schließen diese Lücke.
Authentifizierung und MFA
Authentifizierung stellt die Identität am Zugriffspunkt fest. Passwörter allein reichen nicht aus, daher ergänzt modernes IAM eine Multi-Faktor-Authentifizierung (MFA) — die Kombination von etwas, das die Identität weiß, hat oder ist — und zunehmend phishing-resistente Methoden wie Passkeys und Hardware-Token. Single Sign-On (SSO) zentralisiert die Authentifizierung, sodass eine starke, gut verwaltete Anmeldung Dutzende schwache, ungemanagte ersetzt.
Autorisierungsmodelle
Sobald eine Identität authentifiziert ist, bestimmt die Autorisierung, was sie tun darf. Zwei dominierende Modelle regeln dies:
- Role-Based Access Control (RBAC) weist Berechtigungen Rollen zu und Rollen Identitäten. Eine Rolle "Billing Analyst" trägt einen festen Satz an Berechtigungen; jeder in dieser Rolle erbt sie. RBAC ist einfach zu durchschauen, aber grobkörnig — es stößt an Grenzen, wenn der Zugriff vom Kontext abhängen sollte.
- Attribute-Based Access Control (ABAC) wertet Richtlinien gegen Attribute der Identität, der Ressource und der Umgebung aus — Abteilung, Datenklassifizierung, Tageszeit, Gerätezustand. ABAC ist ausdrucksstärker und kontextbewusst, aber schwerer zu erstellen und zu prüfen.
Least Privilege und privilegierter Zugriff
Das Prinzip der geringsten Rechte (Least Privilege) besagt, dass jede Identität nur den Zugriff haben sollte, der zur Erfüllung ihrer Funktion erforderlich ist — keine dauerhaften Berechtigungen "für alle Fälle". Privileged Access Management (PAM) wendet dies auf risikoreiche Konten an: Administrator-, Root- und Dienstidentitäten, die, falls kompromittiert, weitreichende Kontrolle gewähren. PAM verwahrt Anmeldedaten in einem Vault, gibt sie just-in-time aus, beschränkt sie auf eine Sitzung und protokolliert ihre Nutzung.
Governance und Rezertifizierung
Identity Governance and Administration (IGA) sitzt über der Mechanik und liefert die Audit- und Aufsichtsebene. Periodische Zugriffs-Rezertifizierung zwingt Führungskräfte, erneut zu bestätigen, dass jeder Mitarbeitende den ihm zustehenden Zugriff weiterhin benötigt. Funktionstrennungsrichtlinien (Segregation of Duties) verhindern toxische Kombinationen von Berechtigungen. Governance ist die Art, wie IAM im Laufe der Zeit korrekt bleibt, statt in angehäufte, ungeprüfte Privilegien abzudriften.
Menschliche Identitäten versus AI-Agenten-Identitäten
IAM wurde rund um einen Menschen an einer Tastatur konzipiert: Eine Person authentifiziert sich einmal, hält eine relativ stabile Rolle und handelt mit menschlicher Geschwindigkeit und in menschlichem Umfang. Nicht-menschliche Identitäten belasteten dieses Modell bereits — Dienstkonten und API-Schlüssel übersteigen in den meisten Organisationen die Zahl menschlicher Nutzer. Autonome AI-Agenten brechen es weiter auf, denn ein Agent ist nicht nur eine Anmeldeinformation, sondern ein Akteur, der entscheidet, was er mit dem ihm delegierten Zugriff tut.
| Menschliche Identität | AI-Agenten-Identität | |
|---|---|---|
| Authentifizierung | Interaktives Login, MFA, SSO | Delegierte Token, Dienstanmeldedaten, OAuth-Scopes |
| Zugriffsmuster | Stabile Rolle, Aktionen in Menschentempo | Dynamische, hochvolumige Tool-Calls in Maschinengeschwindigkeit |
| Autorisierung | RBAC/ABAC an eine Person gebunden | Geerbte oder delegierte Berechtigungen, oft zu weit gefasst |
| Verantwortlichkeit | Benannter Nutzer, klare Zuordnung | Diffus — welcher Mensch verantwortet die Aktionen des Agenten? |
| Primäres Risiko | Gestohlene Anmeldedaten, Privilege Creep | Übermäßige Handlungsmacht — Missbrauch rechtmäßig gewährten Zugriffs |
Das definierende neue Risiko ist übermäßige Handlungsmacht (excessive agency): Ein AI-Agent hält Berechtigungen, die technisch gültig, aber weit umfassender sind, als es eine einzelne Aufgabe erfordert, und traditionelles IAM hat keine native Möglichkeit, einzuschränken, was der Agent damit tut. Der Agent authentifiziert sich erfolgreich, also winkt IAM ihn durch — selbst wenn seine Folge von Tool-Calls auf ein Verhalten hinausläuft, das keinem menschlichen Bediener gestattet wäre.
Warum AI das IAM-Problem verändert
Traditionelles IAM regelt den Zugriff an der Tür: Es entscheidet, ob eine Identität ein System betreten darf. Es regelt nicht, was innerhalb geschieht, sobald ein delegierter Agent zu handeln beginnt. Ein Agent mit Lesezugriff auf ein CRM und Sendezugriff auf eine E-Mail-API hat isoliert betrachtet zwei vernünftige Berechtigungen — doch kombiniert und autonom ermöglichen sie eine Datenexfiltration, die keine Rezertifizierungsprüfung erfassen würde, weil jede einzelne Gewährung harmlos aussah.
Diese Lücke zu schließen, erfordert, die IAM-Prinzipien auf die Agent-Runtime auszuweiten: jede Anmeldeinformation auf die engstmögliche Aufgabe zu beschränken, sie sitzungsgebunden statt dauerhaft auszugeben und jede Aktion des Agenten gegen die Richtlinie zu prüfen, bevor sie ausgeführt wird. Die Identität bleibt das Fundament — doch für AI ist die Authentifizierung an der Perimetergrenze nicht mehr ausreichend. Die Governance muss zum Handlungspunkt vorrücken.
Fragen, die IAM für AI beantworten sollte
- Welche AI-Modelle und -Oberflächen darf diese Identität nutzen? — Zugriffssteuerung über Modelle und Tools pro Nutzer und pro Rolle.
- Welche Berechtigungen wurden diesem Agenten delegiert, und sind sie auf seine Aufgabe beschränkt? — Least-Privilege-, sitzungsgebundene Anmeldedaten statt dauerhafter Gewährungen.
- Was hat dieser Agent tatsächlich mit seinem Zugriff getan? — Ein Audit-Trail pro Aktion über jeden Tool-Call, den der Agent ausführte.
- Wer verantwortet die von dieser autonomen Identität ausgeführten Aktionen? — Klare Verantwortlichkeit, die Agenten-Aktivität auf einen Menschen oder eine Rolle zurückführt.
