Autonome Agenten im Identitätsmanagement Wenn KI zur Nutzergruppe wird

Ein Gastbeitrag von Peter Ganten 5 min Lesedauer

Anbieter zum Thema

Autonome KI-Agenten handeln immer selbstständiger. Nutzen sie dazu die Konten echter, menschlicher Mitarbeiterinnen und Mitarbeiter, erben sie oft mehr Rechte als nötig. Eigene, eng begrenzte Identitäten schaffen die nötige Kontrolle.

KI-Agenten brauchen eigene Identitäten mit benannten Verantwortlichen und lückenloser Protokollierung, damit jede Aktion zurechenbar bleibt.(Bild: ©  Arnab Dey - stock.adobe.com / KI-generiert)
KI-Agenten brauchen eigene Identitäten mit benannten Verantwortlichen und lückenloser Protokollierung, damit jede Aktion zurechenbar bleibt.
(Bild: © Arnab Dey - stock.adobe.com / KI-generiert)

Im Identity- und Access-Management (IAM) wird meist zwischen menschlichen Konten und technischen Konten für Dienste, Server oder Skripte unterschieden. KI-Agenten passen nur bedingt in dieses Raster und Service-Accounts sind für weitgehend vorhersehbare Abläufe vorgesehen. Agenten reagieren hingegen auf wechselnde Eingaben, wählen Werkzeuge aus und treffen kontextabhängige Entscheidungen.

Deshalb läuft ein KI-Agent in der Praxis häufig im Kontext der Berechtigungen seines Erstellers. Die Einrichtung ist einfach, doch die Folgen werden erst im Betrieb sichtbar. Denn ein menschliches Konto bündelt Rechte für viele Aufgaben, während ein Agent meist einen viel enger gefassten Zweck verfolgt. Übernimmt er das vollständige Rechteprofil seines „Auftraggebers“, erhält er unnötige Zugriffsmöglichkeiten, die bei Fehlverhalten oder einem Angriff zum Risiko werden können.

Zu viele Rechte vergrößern den Schaden

Das OWASP GenAI Security Project veröffentlichte im Dezember 2025 den Risikokatalog „OWASP Top 10 for Agentic Applications for 2026“ speziell für agentische Systeme. Zwei der zehn Kategorien sind für das Rechtemodell besonders relevant: zum einen die Zweckent­fremdung von Werkzeugen und zum anderen der Missbrauch von Identitäten und Privilegien. Die zweite Kategorie beschreibt den hier diskutierten Fall, da sie unter anderem Szenarien erfasst, in denen ein KI-Agent mehr Rechte erhält, als seine Aufgabe verlangt, oder eine geteilte Identität nutzt, sodass sich seine Aktionen nicht mehr eindeutig zuordnen lassen.

Für eine solche Ausnutzung vorhandener Berechtigungen ist nicht zwingend eine klassische Softwarelücke nötig. Bei einer indirekten Prompt Injection kann eine fremde Anweisung etwa in einem Dokument, auf einer Webseite oder in einer Systemantwort stecken. Verarbeitet der KI-Agent sie als legitimen Auftrag, kann er sie mit den ihm zugewiesenen Rechten ausführen.

Ein weiterer Risikopfad führt über das Konto, unter dem der KI-Agent arbeitet. Der Bericht „Enisa Threat Landscape 2025“ analysiert Vorfälle aus dem Zeitraum Juli 2024 bis Juni 2025. Unter den beobachteten initialen Angriffswegen entfielen rund 60 Prozent auf Phishing. Die Enisa beschreibt zudem, dass Sprachmodelle für überzeugendere Phishing-Mails eingesetzt werden und KI die Skalierbarkeit bösartiger Aktivitäten erhöht. Wird das vom Agenten genutzte Konto auf diesem Weg kompromittiert, kann der Angreifer die daran geknüpften Berech­ti­gungen missbrauchen. Phishing kann also den Zugang eröffnen, während der Rechteumfang maßgeblich beeinflusst, wie weit der Zugriff reicht.

Ohne eigene Agenten-Identität fehlt die Spur

Nutzt ein KI-Agent ein Konto eines echten Benutzers, erscheint in den Log-Dateien schlimmstenfalls nur die betreffende Person als Urheber. Folglich lässt sich später kaum noch unterscheiden, ob eine kritische Änderung vom Mitarbeitenden selbst, von „seinem“ Agenten oder von einer manipulierten Agentenaktion ausging. Das erschwert Audits, forensische Analysen und die Zuordnung von Verantwortung.

Darüber hinaus verlängert sich bei Multi-Agenten-Systemen die Zurechnungskette. Ein KI-Agent delegiert, ein zweiter ruft ein Werkzeug auf, ein dritter verändert Daten. Fehlen eigene Kennungen und ein durchgängiger Vorgangsbezug, lassen sich die einzelnen Schritte im Audit nur dem ursprünglichen Konto zuordnen. Das Bitkom-Whitepaper „Security of AI Agents“ unterscheidet für solche Systeme syntaktische, semantische und funktionale Validierungen.

Geprüft wird dabei zunächst, ob eine Übergabe formal korrekt verarbeitet werden kann. Ebenso wichtig ist, ob die Entscheidung zum vorgesehenen Auftrag passt und ob das Zusammenspiel der KI-Agenten in realistischen Szenarien sicher funktioniert. Für jeden Übergang ist deshalb festzulegen, welcher Agent den Vorgang übernimmt, welche Informationen er erhält und in welchem Kontext er weiterarbeitet. Die beteiligten Agenten werden authentifiziert, autorisiert und fortlaufend überwacht. Außerdem sollten Übergaben kryptografisch signiert und Zwischenergebnisse so gespeichert werden, dass ihre Herkunft nachvollziehbar bleibt. Delegationen müssen technisch begrenzt und über Systemgrenzen hinweg nachvollziehbar sein. Andernfalls können sie unbemerkt den Berechti­gungs­umfang erweitern oder die Verantwortung in der Kette verwischen.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Eigene Identitäten schaffen Kontrolle

Ein tragfähiges Modell behandelt jeden produktiven KI-Agenten als eigenständigen digitalen Akteur mit eindeutiger Identität, eigenen Zugangsdaten und einem benannten Ver­ant­wort­lichen. Die Identität kann einer Person oder Organisationseinheit untergeordnet sein. Dabei ist entscheidend, dass sie nicht mit einem menschlichen Konto verschmilzt und zentral verwaltet wird.

Auf dieser Grundlage lässt sich das Least-Privilege-Prinzip auf die Aufgabe anwenden: Ein KI-Agent zur Rechnungsprüfung benötigt keinen Schreibzugriff auf ein Quellcode-Repository und ein Agent, der nur interne Dokumente zusammenfasst, braucht keinen freien Internetzugang. Wird eine eng zugeschnittene Identität manipuliert, bleibt ihr Wirkungskreis begrenzt.

Mehr Konten bedeuten nicht mehr Chaos

Eigene Identitäten erhöhen die sichtbare Zahl der Konten, ohne die zugrunde liegende Komplexität zu vergrößern. Diese entsteht bereits durch verschiedene Aufgaben, Datenzugriffe, Werkzeuge und Zuständigkeiten. Gemeinsame Konten verschleiern sie lediglich und verlagern den Aufwand in Incident Response, Audit und Bereinigungen.

Aus diesem Grund gehören Agentenidentitäten in einen regulären Lebenszyklus, der fachliche und technische Verantwortliche, Namensregeln, automatisiertes Provisioning und De­pro­visioning, kurzlebige Zugangsdaten sowie Standardrollen pro Aufgabe umfasst. Endet der Auftrag oder wechselt der Verantwortliche, werden Rechte entzogen oder neu bestätigt.

Autonomie braucht klare Grenzen

Im IAM müssen Zweck, erlaubte Systeme und Abschaltweg hinterlegt werden. Grundlage der Berechtigungen ist allein der Arbeitsauftrag, unabhängig vom Profil des Erstellers. Zudem begrenzen kurzlebige Token und befristete Rollen liegengebliebene Rechte. Ändern sich Aufgabe, Werkzeug oder Verantwortliche, ist eine neue Freigabe nötig.

Auch die technische Umgebung muss dem engen Auftrag folgen. Positivlisten bestimmen erlaubte Schnittstellen, Methoden, Datenquellen und Ziele, während Netzwerkzugriffe auf notwendige Verbindungen beschränkt werden. Das verhindert Datenabfluss zwar nicht in jedem Fall, reduziert aber mögliche Wege und erleichtert die Überwachung. Außerdem gelten für Agentenketten feste Grenzen bei Tiefe, Laufzeit, Kosten und Werkzeugaufrufen. Zu guter Letzt verbindet eine Vorgangskennung alle Aktionen. Abbruchbedingungen und ein zentraler Abschaltmechanismus müssen auch bei Fehlern von Unteragenten greifen.

Des Weiteren sollten KI-Agenten in getrennten Laufzeitumgebungen mit eigenen Zugangsdaten und Ressourcenlimits arbeiten, da die zentrale Protokollierung so Identität, Auftrag, delegierende Instanz, Werkzeug und Ergebnis erfasst. Bei der Deaktivierung werden Zugangsdaten gesperrt und offene Sitzungen beendet. So lassen sich Kontrollen im Betrieb prüfen und im Vorfall belastbar nachweisen.

Zurechenbarkeit beginnt vor dem Start

Fehlende Identitäten und Protokolle lassen sich nach einem Vorfall nicht ergänzen. Ob eine Aktion aufgeklärt werden kann, entscheidet sich maßgeblich bei Architektur, Berechtigungs­ver­gabe und Produktivsetzung. Auch bei einem hohen Maß an Autonomie bleibt die Verantwortung bestehen und verlangt eindeutige Zuständigkeiten.

Wer KI-Agenten von Beginn an eigene, eng begrenzte Identitäten gibt, kann Abweichungen erkennen, Schäden eingrenzen und Entscheidungen belegen. Fehlt diese Trennung, bleibt im Ernstfall ein menschliches Konto als Urheber stehen, obwohl kein Mensch die Handlung bewusst ausgelöst hat.

Über den Autor: Peter Ganten ist Geschäftsführer bei der Univention GmbH.

(ID:50997356)