Confused Deputy Agent
Das Confused-Deputy-Problem in Agentensystemen tritt auf, wenn ein Agent Aufträge ausführt, ohne die Berechtigungen des ursprünglichen Anfragenden zu prüfen, und dabei seine eigenen, meist umfassenderen Zugriffsrechte einsetzt. Die Zugriffskontrolle prüft dann den Agenten statt den Menschen dahinter.
Ein Confused Deputy Agent ist ein KI-Agent, der mit seinen eigenen weitreichenden Rechten eine Aktion ausführt, die ein weniger berechtigter Auftraggeber angestoßen hat – und so unbeabsichtigt eine Rechteausweitung ermöglicht.
Erklärung
Agenten werden aus Bequemlichkeit oft mit einem Service-Konto betrieben, das alle nötigen Systeme erreicht. Fragt eine Praktikantin den Agenten nach Umsatzzahlen, sieht die Datenbank nur den privilegierten Agenten – und liefert. Das Muster ist alt, kennt man aus Compilern und Proxy-Systemen, wird durch natürliche Sprache aber massiv verstärkt, weil Anfragen nicht mehr an feste Endpunkte gebunden sind. Lösungen sind Delegation statt Impersonation: Der Agent handelt mit einem Token, das die Rechte des anfragenden Nutzers trägt, ergänzt um eine serverseitige Autorisierungsprüfung pro Werkzeugaufruf und um Protokolle, die Nutzer und Agent getrennt ausweisen.
Relevanz für Marketing
In Marketing-Stacks mit CRM, Werbekonten und Kundendaten entscheidet dieses Muster darüber, ob ein hilfreicher Assistent versehentlich zur Datenabflussstelle wird. Es ist die häufigste Ursache unbeabsichtigter Datenfreigaben in Agentenprojekten.
Beispiel
Ein interner Wissens-Agent hat Lesezugriff auf alle Laufwerke, damit er gut antworten kann. Ein Werkstudent fragt nach Gehaltsbändern – der Agent findet die Datei, prüft aber nie, ob der Fragende sie sehen dürfte, und fasst sie zusammen.
Häufige Fallstricke
Der gravierendste Fehler ist ein einziges Service-Konto mit maximalen Rechten. Es macht jede spätere Zugriffskontrolle wirkungslos, weil das System die eigentliche Identität gar nicht mehr kennt.
Entstehung & Geschichte
Der Begriff des Confused Deputy stammt aus einem Aufsatz zur Rechnersicherheit von 1988. Mit dem Aufkommen autonomer Agenten und geteilter Service-Konten wurde er 2025 und 2026 neu diskutiert, weil klassische rollenbasierte Modelle die Zwischeninstanz Agent nicht abbilden.
Anwendungsfälle im Marketing
On-Behalf-Of-Tokens, mit denen der Agent im Rechtekontext des anfragenden Nutzers handelt.
Autorisierungsprüfung serverseitig bei jedem Tool-Aufruf statt nur im Prompt.
Audit-Log, das Nutzeridentität, Agentenidentität und Zielsystem getrennt festhält.
Least-Privilege-Design mit getrennten Agenten je Datenklasse statt eines Allzweck-Agenten.
Häufige Fragen
Reicht es, den Agenten per Prompt zu Zugriffsregeln zu verpflichten?
Nein. Prompt-Regeln sind Empfehlungen, keine Durchsetzung – eine geschickte Formulierung oder eine Injektion hebelt sie aus. Berechtigungen müssen dort geprüft werden, wo die Daten liegen, nicht im Modellkontext.
Was ist der Unterschied zu Impersonation?
Bei Impersonation gibt sich der Agent vollständig als Nutzer aus, was Nachvollziehbarkeit zerstört. Bei Delegation handelt er sichtbar als Agent, aber begrenzt auf die Rechte des Auftraggebers – nur letzteres ist auditierbar.
Wie testet man das Problem?
Indem man dieselbe Frage aus zwei Konten mit unterschiedlichen Rechten stellt. Liefert der Agent beide Male dieselbe Antwort, prüft er die Berechtigungen des Anfragenden nicht.
Verwandte Services
Tiefer einsteigen: Agentic AI Hub · Governance & Compliance