Zero Trust für KI-Agenten: Delegation, Identitäts- und Zugriffskontrolle

Warum die Identität von KI-Agenten relevant ist

KI-Agenten gelten längst nicht mehr nur als passive Werkzeuge. Sie übernehmen zunehmend Aufgaben wie das Abrufen von Dokumenten, das Planen von Besprechungen, das Abfragen von APIs oder sogar das Treffen von Entscheidungen im Auftrag von Menschen. Mit wachsender Verantwortung stellt sich jedoch die Frage: In welcher Rolle handeln diese Agenten, und was geschieht, wenn Fehler auftreten?

Im Unterschied zu klassischer Software agieren KI-Agenten mit einer Kombination aus Autonomie und Delegation. Das macht Identitäts- und Zugriffskontrollen zu einem zentralen Sicherheits- und Geschäftsrisiko. Wenn ein Agent auf sensible Daten zugreift oder mit anderen Systemen interagiert, muss gewährleistet sein, dass dies nur mit den vorgesehenen Berechtigungen geschieht – und nicht darüber hinaus.

Der Artikel erklärt, wie die Definition, Delegierung und Durchsetzung der Identitäten von KI-Agenten Unternehmen schützt, sichere Zusammenarbeit ermöglicht und neue Funktionen freischaltet, ohne die Kontrolle zu verlieren.

Das Risiko der Delegation bei KI-Agenten

Delegation kann effizient, aber auch gefährlich sein. Wird ein KI-Agent mit zu weitreichenden oder unklaren Befugnissen ausgestattet, droht der Verlust von Transparenz und Kontrolle. Dies kann zu unbeabsichtigten Datenfreigaben, falschen Aktionen oder Sicherheitslücken führen, über die sich lateral in Systeme bewegen lässt.

Sichere Delegation erfordert klare Vorgaben: Was darf ein Agent tun, in wessen Namen und unter welchen Bedingungen? Wie bei menschlichen Nutzern oder Dienstkonten sind überprüfbare und widerrufbare Delegierungsmechanismen nötig, die Identität und Absicht des Agenten widerspiegeln.

Eine etablierte Lösung sind sogenannte Delegierungstoken. Diese Berechtigungsnachweise mit begrenztem Umfang ermöglichen es einem Agenten, im Namen eines Benutzers oder eines anderen Agenten zu handeln. RFC 8693 beschreibt einen formalen Standard für einen strukturierten Token-Austausch, der mehrschichtige Identitäten abbildet.

Die reine Ausgabe eines Tokens ist jedoch nur der Anfang. Entscheidender ist die Autorisierung: Wer legt fest, was ein Agent darf, in welchem Kontext, und wie werden diese Entscheidungen umgesetzt und überprüft? Ohne strenge Kontrollen verwandelt sich Delegation schnell in blindes Vertrauen – mit Risiken für Missbrauch oder unbeabsichtigte Aktionen.

Delegierung über Token-Austausch (RFC 8693)

Bevor ein Agent im Namen eines anderen handeln darf, muss die Identität beider Parteien eindeutig dargestellt werden. Der Token-Austausch ermöglicht dies, indem er ein Delegierungstoken erzeugt, das die Beziehung zwischen ursprünglichem Subjekt und handelnder Partei abbildet:

• Subjekt-Token: Repräsentiert die ursprüngliche Identität, zum Beispiel den Benutzer.

Grafik Quelle: CyberArk

• Akteur-Token: Repräsentiert die handelnde Partei, etwa einen KI-Agenten oder eine Anwendung, die im Auftrag des Subjekts agiert.

Grafik Quelle: CyberArk

Das resultierende Delegierungstoken enthält beide Identitäten, sodass der Agent im Namen des Subjekts handeln kann.

Grafik Quelle: CyberArk

Ein Beispiel:

Alice ist Benutzerin. Der KI-Agent „Agent A“ möchte im Auftrag von Alice einen Dienst kontaktieren, etwa um einen Flug zu buchen. Der Ablauf:

1. Alice authentifiziert sich, ihre Identität wird in ein Subjekt-Token umgewandelt.

2. Agent A verfügt über sein Akteur-Token.

3. Agent A beantragt ein Delegierungstoken beim Authentifizierungsserver, indem er beide Tokens übermittelt.

4. Der Server gibt ein Delegierungstoken zurück, das sowohl die Identität des Subjekts als auch die des Akteurs enthält.

Dienst B kann so erkennen, dass die Anfrage von Agent A im Auftrag von Alice stammt.

Token-Austausch und Delegierung: Grenzen und Kontrolle

Während eines Token-Austauschs prüft der Autorisierungsserver mehrere Sicherheitsaspekte, bevor er ein neues Token ausgibt. Delegierungstoken unterstützen zwar robuste Anwendungsfälle, schränken aber nicht automatisch die ursprünglichen Berechtigungen von Benutzer (Subjekt) oder KI-Agent (Akteur) ein. Ohne zusätzliche Einschränkungen können sie unbeabsichtigte Zugriffe ermöglichen.

Grafik Quelle: CyberArk

OAuth2-Föderationen treffen meist einfache, feste Entscheidungen auf Basis von Token-Details wie Benutzer-ID oder Rollen. Komplexe, kontextbasierte Autorisierungen werden nicht unterstützt. So gleicht etwa AWS IAM Token-Ansprüche statisch ab, ohne dynamische Analyse.

Die Berechtigungen eines Delegierungstokens sollten idealerweise die Überschneidung von Benutzer- und Agentenrechten widerspiegeln. In manchen Fällen, wie beim kontrollierten Zugriff auf Plattformen, kann ein Token jedoch gezielt erweiterte, vertrauenswürdige Rechte enthalten, um KI-Agenten Aufgaben im Auftrag eines verifizierten Benutzers ausführen zu lassen.

Unkontrollierte Delegation birgt Risiken: Ein Agent könnte seine Privilegien ausweiten oder unbeabsichtigte Aktionen durchführen. Es gibt keine automatische Garantie, dass das Prinzip der geringsten Privilegien eingehalten wird.

Zur Durchsetzung dynamischer Zugriffsrichtlinien kann eine Policy Engine wie der Open Policy Agent (OPA) eingesetzt werden. OPA erlaubt die Definition flexibler Regeln in einer deklarativen Sprache, die sowohl die Identität des Benutzers als auch des KI-Agenten berücksichtigt. So lassen sich Aktionen, Bereiche und Ressourcenzugriffe in Echtzeit kontrollieren und sicherstellen, dass KI-gesteuerte Aufgaben innerhalb der vorgesehenen Grenzen bleiben.

Grafik Quelle: CyberArk

Beispiel: OPA-Autorisierungsantrag

Grafik Quelle: CyberArk

Just-In-Time-Zugriff (JIT) bedeutet, dass Berechtigungen nur bei Bedarf und nur für die erforderliche Dauer gewährt werden. In Sicherheits- und Cloud-Systemen reduziert dies Risiken, begrenzt die Auswirkungen kompromittierter Anmeldedaten und ermöglicht die dynamische Umsetzung des Prinzips der geringsten Privilegien.

Just-Enough-Access (JEA) sorgt dafür, dass Agenten oder Nutzer nur die minimalen Berechtigungen erhalten, die sie für ihre Aufgaben benötigen. So kann ein KI-Agent mit Lese-Rechten nicht versehentlich Daten löschen und mit Zugriff auf einen einzelnen Ordner nicht das gesamte System einsehen.

Kombiniert man JIT und JEA, werden Rollen dynamisch zugewiesen und kurzlebige Tokens erstellt. Ein KI-Agent erhält so nur die Rechte, die er tatsächlich für die aktuelle Aufgabe braucht.

Dieser Ansatz legt klare, überprüfbare Grenzen fest. Statt auf starre Regeln zu setzen, steuert er den Zugriff des Agenten dynamisch anhand der ursprünglichen Benutzerrechte, der Rollen, Fähigkeiten und weiterer definierter Richtlinien. Das gewährleistet eine sichere, präzise und nachvollziehbare Delegierung.

Auch interessant?

---