IAM

Wenn KI selbstständig handelt: Warum Identity Management allein nicht mehr ausreicht

Identitaet-KI

Die Security-Branche hat viel Energie darauf verwendet, der Frage nachzugehen, welche Art von Identität ein autonomer KI-Agent tatsächlich besitzt. Das ist keine triviale Frage und es gibt auch keine einfachen Antworten darauf.

KI-Agenten sind nicht wirklich Nutzer, handeln jedoch in deren Auftrag. Um Teilaufgaben zu erledigen, APIs aufzurufen, auf Daten zuzugreifen und Workflows auszulösen, generieren sie weitere Agenten. In manchen Architekturen kommunizieren sie sogar mit anderen Agenten, die im Auftrag ganz anderer Nutzer agieren. Herkömmliche Identity-Frameworks sind dafür nicht ausgelegt. Die grundlegende Frage der Zugriffskontrolle in Unternehmen „Wer oder was führt diese Aktion tatsächlich aus?“ lässt sich deshalb von Tag zu Tag schwerer beantworten.

Anzeige

Doch wer Agentic AI primär als Identitätsproblem einordnet, lenkt den Blick auf die falsche Ebene. Das Identitätsmanagement, die Ausstellung von Zugangsdaten und die Mechanismen der Authentifizierung gehören zum Aufgabenbereich von sogenannten IAM-Plattformen (Identity Access Management). Die für Security-Teams folgenreichere Frage ist, was passiert, nachdem die Identität feststeht – wenn ein Agent also authentifiziert ist und seine Zugriffsrechte definiert sind. Setzt die umgebende Richtlinienlandschaft diesen Zugriff dann tatsächlich wie beabsichtigt durch? Gibt es Zugriffspfade, die das Zugriffsmodell nie vorgesehen hat? Und verfügt das Unternehmen über einen klaren, belastbaren Überblick darüber, was auf jeder Durchsetzungsebene, mit der der Agent in Berührung kommt, erlaubt ist?

Genau hier schauen die meisten Unternehmen bislang nicht genau hin. Und genau dort liegt auch das größte Risiko.

Least Privilege ist nicht nur eine IAM-Frage

Das Prinzip der minimalen Rechtevergabe gilt für KI-Agenten genauso unmittelbar wie für menschliche Nutzer: Es werden nur die Mindestzugriffsrechte vergeben, die für die Ausführung der definierten Funktion erforderlich sind – nicht mehr. Schwierig wird es dort, wo Organisationen dieses Prinzip als IAM-Konfigurationsaufgabe behandeln – als etwas, das mit der korrekten Vergabe von Berechtigungen als erledigt gilt. Dies ist zwar ein notwendiger Ausgangspunkt, aber keine vollständige Lösung.

Anzeige

Der tatsächliche Zugriff eines KI-Agenten wird nicht allein durch seine IAM-Berechtigungen bestimmt. Vielmehr ergibt er sich aus dem Zusammenspiel dieser Berechtigungen mit dem gesamten, ihn umgebenden Richtlinienumfeld, zu dem Firewall-Regeln, Cloud-Zugriffskontrollen und Mikrosegmentierungsgrenzen gehören. Diese legen fest, was der KI-Agent im Netzwerk tatsächlich erreichen, durchqueren und ausführen kann. Ein Agent kann in IAM sauber eingegrenzt sein, während die umgebende Policy-Landschaft Zugriffspfade zulässt, die seinen vorgesehenen Wirkungsradius deutlich überschreiten. Ursache dafür können veraltete und nie außer Kraft gesetzte Firewall-Regeln, Cloud-Richtlinien, die für eine bestimmte Workload erstellt und bei deren Änderungen nie aktualisiert wurden oder Mikrosegmentierungsgrenzen, die längst kein Zugriffsmodell mehr widerspiegeln, das jemand bewusst so entwerfen würde, sein. Auf dem Papier war der Agent nach dem Prinzip Least Privilege konfiguriert. In der Praxis hatte er jedoch erheblich mehr Spielraum als beabsichtigt.

Diese Diskrepanz ist ein Problem der Policy-Governance, das bei den meisten Implementierungen agentischer KI noch nicht systematisch angegangen wird.

Governance entscheidet, was wirklich erlaubt ist

Gefragt ist daher vor allem ein Blick auf die Policy-Ebene. Sie entscheidet letztlich darüber, welche Zugriffe ein KI-Agent in der Praxis tatsächlich ausüben kann. Für Unternehmen stellt sich dabei eine zentrale Frage: Entspricht der effektive Zugriff dem ursprünglich definierten Zugriffsmodell oder haben sich durch Richtlinien, Ausnahmen und Änderungen zusätzliche Zugriffspfade ergeben? Entscheidend ist zudem, ob diese Zusammenhänge transparent und nachvollziehbar sind.

Dafür benötigen Security-Teams ein verlässliches und aktuelles Bild davon, welche Zugriffe über die gesamte Richtlinienlandschaft tatsächlich erlaubt sind. Änderungen sollten vor ihrer Umsetzung darauf geprüft werden, ob sie der vorgesehenen Zugriffsabsicht entsprechen oder unbeabsichtigte Zugriffspfade schaffen. Ebenso wichtig ist die kontinuierliche Überwachung schleichender Abweichungen („Drift“), bei denen sich die Richtlinienlandschaft durch zahlreiche Einzeländerungen zunehmend vom ursprünglich definierten Zustand entfernt. Hinzu kommen belastbare Compliance-Nachweise, die belegen, dass Zugriffe auch im Laufe der Zeit den Unternehmensvorgaben entsprechen. Mit der wachsenden Zahl von KI-Agenten und Zugriffsentscheidungen gewinnt diese Governance-Ebene weiter an Bedeutung. Sie entscheidet darüber, ob Least Privilege dauerhaft nachweisbar bleibt oder mit der Zeit zur bloßen Annahme wird.

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.

Ein Regelwerk, was bereits vor der KI ausuferte

Die Herausforderung besteht nicht nur darin, dass Agentic AI neue Zugriffsanforderungen mitbringt. Sondern darin, dass sie auf eine Umgebung trifft, die die meisten Unternehmen bis heute nicht vollständig im Griff haben. Regelwerke mit Tausenden, über die Jahre angesammelten Einträgen, von denen viele nie überprüft wurden und manche einander widersprechen, sind in der Praxis keine Ausnahme. Die Lücke zwischen den Zugriffskontrollen, von denen ein Team glaubt, sie etabliert zu haben, und dem, was die Richtlinienlandschaft tatsächlich erlaubt, erweist sich bei ehrlicher Prüfung oft als Kluft. Und sie hat die unangenehme Eigenschaft, eher zu wachsen, als sich von selbst zu schließen.

Agentic AI verschärft dieses Problem noch auf besondere Weise. Ein menschlicher Nutzer mit überzogenen Rechten fällt früher oder später auf, sei es durch ungewöhnliche Anfragen oder Zugriffsmuster, die verdächtig wirken. Ein KI-Agent hingegen, der außerhalb seines vorgesehenen Zugriffsbereichs agiert, sendet möglicherweise kein solches Signal. Er erfüllt seine Funktion und nutzt dabei die Zugriffe, die die Richtlinienumgebung erlaubt, anstatt die, die das Zugriffsmodell vorsieht. Der Drift zwischen beabsichtigtem und tatsächlichem Zugriff kann sich schrittweise aufbauen. Er entsteht über mehrere Agenten und unterschiedliche Durchsetzungsebenen hinweg, Oft wird die Abweichung erst sichtbar, wenn sie bereits erheblich geworden ist.

Nachweisbarkeit statt nur Risiko

Für Unternehmen, die der DSGVO, NIS2 oder DORA unterliegen, geht es um mehr als nur Sicherheitsrisiken. Unkontrollierte Zugriffspfade von Agenten bergen zwar das Risiko eines Sicherheitsvorfalls, machen Unternehmen aber auch auf andere Weise angreifbar. Insbesondere dann, wenn sie gegenüber Aufsichtsbehörden, einem Prüfer oder dem eigenen Vorstand nicht nachweisen können, dass die Zugriffe stets den Unternehmensvorgaben entsprachen, dass Richtlinienänderungen vor ihrer Aktivierung geprüft wurden und dass die Zugriffsumgebung durchgängig einheitlich geregelt war. DSGVO, NIS2 und DORA verlangen belastbare Nachweise. Entscheidend ist nicht, ob ein Unternehmen von einer korrekten Zugriffskonfiguration ausgegangen ist, sondern ob es deren Wirksamkeit kontinuierlich belegen kann.

Fazit

Agentic AI erschwert den Nachweis des Prinzips der geringsten Berechtigungen. Die in IAM definierten Rechte eines KI-Agenten entsprechen nicht zwangsläufig den Zugriffen, die er in der Praxis tatsächlich ausüben kann. Mit zunehmender Komplexität und Zahl der Agenten wächst diese Diskrepanz.

Lösen lässt sich dies nur durch konsequente Policy-Governance: wissen, was tatsächlich erlaubt ist; Änderungen prüfen, bevor sie wirksam werden; Abweichungen erkennen, bevor sie sich aufstauen. Und all das muss jederzeit belegbar sein. Die meisten Unternehmen setzen Agentic AI bereits produktiv ein, unabhängig davon, ob ihre Governance dafür bereit ist oder nicht. Den Unterschied macht am Ende, ob Least Privilege ein bewiesener Zustand ist oder eine bloße Annahme.

Koehncke

Peter

Köhncke

Country Manager DACH & Central Europe

FireMon

Peter Köhncke ist Country Manager DACH & Central Europe bei FireMon. Er verfügt über eine fast 30-jährige Erfahrung in der Network-Security-Industrie und verantwortete in dieser Zeit unter anderem den Aufbau und die Skalierung von Vertriebs- und Partnerstrukturen sowie die erfolgreiche Markteinführung innovativer Security-Plattformen im europäischen Enterprise-Umfeld.
Anzeige

Artikel zu diesem Thema

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.