Delegationsketten und der Confused Deputy in der Agenten-Identität: sichere Identitätsübernahme, Token-Austausch und Audit-Trail

Sobald ein KI-Agent im Auftrag eines Menschen handelt und dabei einen zweiten Dienst aufruft, entsteht eine Delegationskette. Genau an dieser Kette zerbrechen die meisten Sicherheitsarchitekturen: Der Agent besitzt mehr Rechte als der ursprüngliche Nutzer und führt fremde Anweisungen mit diesen Rechten aus. Das ist der klassische Confused Deputy – nur dass der „verwirrte Stellvertreter“ diesmal ein autonomes System ist, das Werkzeuge aufruft, Tickets schließt und Datenbanken abfragt.

Was ist die kurze Antwort auf das Problem?

Eine Delegationskette ist sicher, wenn an jedem Glied drei Dinge erhalten bleiben: wer ursprünglich gehandelt hat (die Identität des Nutzers), wer gerade handelt (die Identität des Agenten) und mit welchen Rechten dieser Aufruf erlaubt ist. Der Confused Deputy entsteht, sobald eines dieser drei Dinge verloren geht – meistens, weil der Agent ein hochprivilegiertes Dienstkonto nutzt und die ursprüngliche Nutzeridentität unterwegs verschwindet.

Die Lösung besteht aus drei zusammengehörigen Bausteinen: einem Token-Austausch (Token Exchange), bei dem ein breit gültiges Token gegen ein eng zugeschnittenes eingetauscht wird; einer sauber modellierten Identitätsübernahme (Impersonation oder, präziser, Delegation), die den Nutzer und den handelnden Agenten getrennt mitführt; und einem lückenlosen Audit-Trail, der die gesamte Kette nachvollziehbar macht. Wer diese drei Bausteine konsequent umsetzt, schließt die Lücke, durch die ein Agent zum verwirrten Stellvertreter wird.

Was genau ist der Confused Deputy bei Identität?

Das Confused-Deputy-Problem ist kein neues Phänomen der KI-Ära. Der Begriff geht auf eine Arbeit von Norm Hardy aus dem Jahr 1988 zurück und beschreibt eine Situation, in der ein Programm mit erhöhten Rechten dazu gebracht wird, eine Aktion auszuführen, die der eigentliche Auftraggeber nie ausführen dürfte. Der „Stellvertreter“ ist nicht bösartig – er ist nur verwirrt darüber, in wessen Auftrag und mit welcher Befugnis er gerade arbeitet.

Bei KI-Agenten verschärft sich das Problem aus zwei Gründen. Erstens handeln Agenten oft mit einem Dienstkonto, das deutlich mehr Rechte besitzt als jeder einzelne Nutzer. Zweitens entscheiden Agenten dynamisch, welche Werkzeuge sie aufrufen – und diese Entscheidung kann durch manipulierte Eingaben beeinflusst werden. Eine Prompt Injection in einem eingelesenen Dokument kann den Agenten anweisen, eine API mit seinen eigenen, weiten Rechten aufzurufen, statt mit den begrenzten Rechten des Nutzers, der die Aufgabe gestellt hat.

Konkret heißt das: Ein Nutzer aus der Buchhaltung bittet den Agenten, eine Rechnung zusammenzufassen. Im Dokument steht versteckt die Anweisung, alle Gehaltsdaten aus dem HR-System abzurufen. Wenn der Agent mit einem Dienstkonto arbeitet, das HR-Zugriff hat, und die Identität des Buchhaltungs-Nutzers unterwegs verloren geht, dann führt er die Abfrage aus. Der Nutzer hätte die Daten nie sehen dürfen – der Agent als verwirrter Stellvertreter holt sie trotzdem.

Wie entsteht der Confused Deputy in einer Delegationskette?

Eine Delegationskette beschreibt den Weg einer Berechtigung durch mehrere Dienste hindurch. Der Nutzer authentifiziert sich gegenüber der Anwendung, die Anwendung ruft den Agenten auf, der Agent ruft ein Werkzeug auf, das Werkzeug ruft eine Datenbank auf. An jedem Übergang muss entschieden werden, in wessen Namen der nächste Aufruf erfolgt.

Drei Antimuster führen verlässlich zum Confused Deputy:

• Das Ambient-Privileg. Der Agent läuft mit einem festen Dienstkonto, dessen Rechte für alle Nutzer ausreichen. Jeder Aufruf erbt diese maximalen Rechte, unabhängig davon, wer die Aufgabe gestellt hat. Die Nutzeridentität ist reine Dekoration.
• Der Identitätsverlust an der Grenze. Beim ersten Hop wird die Nutzeridentität noch mitgeführt, aber das Werkzeug ruft den nächsten Dienst mit seinem eigenen Token auf. Spätestens am dritten Glied der Kette weiß niemand mehr, dass ursprünglich ein bestimmter Mensch die Aktion ausgelöst hat.
• Das überdimensionierte Token. Der Agent erhält ein Token mit weitem Geltungsbereich (etwa read:all), obwohl die konkrete Aufgabe nur read:invoice benötigt. Eine manipulierte Anweisung kann dann den gesamten Geltungsbereich missbrauchen.

Allen dreien ist gemeinsam, dass die Berechtigung des Aufrufs nicht mehr an die ursprüngliche Absicht gekoppelt ist. Sicheres Delegieren bedeutet, diese Kopplung über jedes Glied der Kette hinweg zu erhalten.

Was unterscheidet Identitätsübernahme von Delegation?

In der Praxis werden „Impersonation“ und „Delegation“ oft synonym verwendet – sicherheitstechnisch sind es zwei sehr unterschiedliche Modelle, und die Verwechslung ist selbst eine Ursache für Probleme.

Bei der reinen Identitätsübernahme (Impersonation) gibt sich der Agent vollständig als der Nutzer aus. Nachgelagerte Dienste sehen nur noch den Nutzer; dass ein Agent dazwischengeschaltet war, ist unsichtbar. Das ist bequem, weil keine bestehende Berechtigungsprüfung angepasst werden muss – und genau deshalb gefährlich: Der Audit-Trail verliert die Information, dass eine Maschine gehandelt hat, und der nachgelagerte Dienst kann keine agentenspezifischen Einschränkungen durchsetzen.

Bei der Delegation dagegen bleiben beide Identitäten sichtbar: „Agent X handelt im Auftrag von Nutzer Y.“ Der nachgelagerte Dienst kann seine Entscheidung an beiden Identitäten ausrichten, etwa indem er einem Agenten engere Rechte zugesteht als dem Menschen selbst. Genau dafür gibt es im OAuth-2.0-Token-Exchange-Standard (RFC 8693) zwei getrennte Felder: subject_token für die delegierte Identität und act als Claim für die handelnde Partei (den Akteur). Das Modell wird dadurch explizit, statt implizit zu verschwinden.

Für Agenten-Architekturen gilt fast immer: Delegation ist der sichere Standard, Identitätsübernahme die Ausnahme, die einer ausdrücklichen Begründung bedarf. Sobald eine Maschine im Spiel ist, sollte der Audit-Trail das auch festhalten.

Aspekt	Identitätsübernahme (Impersonation)	Delegation
Sichtbare Identität nachgelagert	nur der Nutzer	Nutzer und Agent
act-Claim (RFC 8693)	nicht gesetzt	gesetzt (handelnde Partei)
Agentenspezifische Rechte durchsetzbar	nein	ja
Nachvollziehbarkeit im Audit-Trail	Maschine unsichtbar	volle Kette
Empfohlener Einsatz	seltene Ausnahme mit Begründung	Standard für Agenten

Wie schließt der Token-Austausch die Lücke?

Der Token-Austausch ist das technische Herzstück sicherer Delegationsketten. Die Idee: Ein Dienst tauscht ein vorhandenes Token gegen ein neues ein, das für den nächsten Schritt passgenau zugeschnitten ist – mit engerem Geltungsbereich, kürzerer Lebensdauer und einem act-Claim, der den handelnden Agenten benennt.

Standardisiert ist dieses Verfahren in RFC 8693 (OAuth 2.0 Token Exchange). Ein Dienst sendet sein eingehendes Token als subject_token an den Autorisierungsserver und erhält ein neues Token zurück, dessen Rechte für den konkreten nachgelagerten Aufruf zugeschnitten sind. Der entscheidende Gewinn: Das hochprivilegierte Ausgangstoken verlässt nie die vertrauenswürdige Zone, und jedes Glied der Kette arbeitet mit dem kleinstmöglichen Recht (Prinzip der geringsten Berechtigung).

Drei Eigenschaften machen den Token-Austausch wirksam gegen den Confused Deputy. Erstens verengt er den Geltungsbereich bei jedem Hop, sodass eine manipulierte Anweisung nur das missbrauchen kann, was für die aktuelle Aufgabe ohnehin erlaubt ist. Zweitens bindet er das Token an einen Empfänger (über den audience-Parameter), sodass ein abgefangenes Token nicht bei einem anderen Dienst wiederverwendbar ist. Drittens dokumentiert er die Delegationskette über verschachtelte act-Claims, die genau festhalten, wer in wessen Auftrag handelt.

Eine sinnvolle Ergänzung ist die Bindung des Tokens an den Inhaber (Sender-Constrained Tokens, etwa per DPoP nach RFC 9449). Damit kann ein gestohlenes Token nicht von einem anderen Akteur genutzt werden, weil der Nachweis des kryptografischen Schlüssels fehlt. Für Agenten, die über mehrere Hosts hinweg kommunizieren, ist das ein deutlicher Härtegewinn.

Wie sieht ein belastbarer Audit-Trail aus?

Ein Audit-Trail ist erst dann belastbar, wenn er die gesamte Delegationskette rekonstruierbar macht – nicht nur den letzten Aufruf. Bei einem Vorfall muss die Frage „Welcher Mensch hat über welchen Agenten welches Werkzeug mit welchem Recht aufgerufen?“ lückenlos beantwortbar sein. Genau diese Frage zerstört der Confused Deputy, wenn die Identitäten unterwegs verschmelzen.

Jeder Eintrag im Audit-Trail sollte mindestens diese Felder enthalten:

• Ursprüngliche Nutzeridentität (die delegierte Partei) und handelnde Agentenidentität (der act-Claim) – getrennt, nicht verschmolzen.
• Korrelations-ID, die über alle Hops hinweg gleich bleibt, sodass sich die Kette aus verteilten Protokollen wieder zusammensetzen lässt.
• Konkreter Werkzeugaufruf mit den tatsächlich genutzten Rechten (nicht den theoretisch verfügbaren).
• Auslösende Quelle, also ob die Aktion aus einer Nutzeranweisung oder aus eingelesenem, womöglich nicht vertrauenswürdigem Inhalt stammt – ein wichtiges Signal zur Erkennung von Prompt Injection.

Wichtig ist die Integrität des Protokolls selbst: Es sollte unveränderlich (append-only) und manipulationssicher sein, denn ein Audit-Trail, der nachträglich verändert werden kann, ist im Vorfall wertlos. Für regulierte Umgebungen im DACH-Raum kommt hinzu, dass die DSGVO eine Rechenschaftspflicht über die Verarbeitung personenbezogener Daten verlangt; ein sauberer Audit-Trail über die Delegationskette ist hier nicht nur Sicherheits-, sondern auch Compliance-Anforderung. Die kommende KI-Verordnung (EU AI Act) verstärkt diese Erwartung an Protokollierung und Nachvollziehbarkeit für KI-Systeme zusätzlich.

Welche Schritte machen eine Delegationskette konkret sicher?

Die folgenden sieben Schritte fassen das Vorgehen zusammen und lassen sich Glied für Glied auf eine bestehende Architektur anwenden:

1. Identitäten trennen. Modellieren Sie Nutzer und Agent als zwei eigenständige Identitäten – nie als eine. Der Agent erhält ein eigenes Konto mit eigener Lebenszyklusverwaltung.
2. Delegation statt Identitätsübernahme. Setzen Sie standardmäßig auf Delegation mit act-Claim. Reine Impersonation nur dort, wo es eine dokumentierte Begründung gibt.
3. Token-Austausch an jeder Grenze. Tauschen Sie an jedem Hop das Token gegen ein engeres ein (RFC 8693), mit zugeschnittenem Geltungsbereich und gesetztem audience.
4. Geringste Berechtigung erzwingen. Die effektiven Rechte eines Aufrufs sind die Schnittmenge aus Nutzerrechten und Agentenrechten – nie die Vereinigung.
5. Token binden. Nutzen Sie kurzlebige, an den Inhaber gebundene Token (DPoP, RFC 9449), damit abgefangene Token nutzlos sind.
6. Quelle der Anweisung markieren. Trennen Sie vertrauenswürdige Nutzeranweisungen von eingelesenem Inhalt und behandeln Sie Letzteren als potenziell feindlich, bevor er Werkzeugaufrufe auslöst.
7. Lückenlos protokollieren. Schreiben Sie an jedem Glied einen unveränderlichen Audit-Eintrag mit beiden Identitäten und einer durchgehenden Korrelations-ID.

Der rote Faden durch alle sieben Schritte ist derselbe: Die Berechtigung eines Aufrufs darf nie größer sein als das, was der ursprüngliche Nutzer und der handelnde Agent gemeinsam dürfen – und diese Kopplung muss über jedes Glied der Kette hinweg sichtbar bleiben. Damit verliert der Confused Deputy seine Grundlage, denn es gibt kein Ambient-Privileg mehr, das er versehentlich missbrauchen könnte.

Fazit: Delegation ist eine Identitätsfrage, kein Implementierungsdetail

Der Confused Deputy in Agenten-Identität ist kein exotischer Sonderfall, sondern die Standardfolge einer schlecht modellierten Delegationskette. Wer Agenten mit weiten Dienstkonten laufen lässt und die Nutzeridentität unterwegs verliert, baut die Schwachstelle aktiv ein. Die Gegenmittel sind etabliert und standardisiert: Delegation mit explizitem act-Claim statt unsichtbarer Identitätsübernahme, Token-Austausch mit Verengung an jeder Grenze und ein manipulationssicherer Audit-Trail, der die ganze Kette rekonstruierbar hält.

Diese Bausteine sind keine Kür, sondern die Grundlage dafür, dass autonome Agenten in regulierten Umgebungen überhaupt vertretbar sind. Behandeln Sie die Delegationskette als das, was sie ist – eine Identitätsarchitektur –, und der verwirrte Stellvertreter findet keinen Platz mehr darin.