29.03.2026
Aktualisiert 27.07.2026
Threat
Identity and Privilege Abuse
KI-Agenten können mit zu breiten oder falsch gebundenen Rechten handeln. Gefährlich wird das, wenn legitime Identitäten unautorisierte Zugriffe verschleiern.
Was Identity and Privilege Abuse ist
Bei Identity and Privilege Abuse handelt ein KI-Agent mit mehr, anderen oder falsch gebundenen Berechtigungen, als die aktuelle Aufgabe erlaubt. Ursache sind häufig geteilte Servicekonten, überbreite OAuth-Scopes, weitergereichte Nutzerrechte oder wiederverwendete Tokens.
Der Zugriff wirkt technisch legitim, obwohl Zweck, Ressource, Sitzung oder ursprüngliche Nutzerabsicht nicht mehr zur ausgeführten Aktion passen.
Wie der Angriff funktioniert
Meist verbindet der Angriff einen legitimen Auftrag mit einem zu mächtigen Autorisierungskontext. Ein fremder Inhalt, ein kompromittierter Peer oder ein Workflow-Fehler bestimmt dann, wofür dieser Kontext eingesetzt wird.
Auftrag
Ein Agent erhält eine legitime Aufgabe
Zu breite Rechte
Token oder Rolle erlauben mehr als nötig
Falscher Kontext
Eingabe oder Delegation verschiebt den Zweck
Privilegierte Aktion
Der Agent handelt mit gültigen Credentials
Mögliche Folgen
Sensible Daten werden gelesen
Systeme werden verändert
Rechte werden weitergereicht
Entscheidend ist die erneute Autorisierung unmittelbar vor der Aktion. Ein Rollencheck nur zu Beginn des Workflows schützt nicht vor Scope-Drift, Delegationsfehlern oder später wiederverwendeten Credentials.
Rechte vorhanden oder Rechte falsch gebunden?
Tool Misuse
Erlaubtes Tool, falscher Zweck
Der Agent besitzt die vorgesehenen Rechte, verwendet sie aber für eine nicht freigegebene Handlung.
Die bestehende Berechtigung wird missbraucht
Kontrolle setzt an Parametern und Aktionen an
Identity Abuse
Falscher Autorisierungskontext
Identität, Token, Scope oder Delegation passen nicht zur aktuellen Aufgabe und ihrem Auftraggeber.
Rechte sind zu breit, geerbt oder wiederverwendet
Kontrolle setzt an Identität und Delegation an
Prompt Injection kann die Fehlsteuerung auslösen. Tool Misuse beschreibt die Ausführung; Identity and Privilege Abuse erklärt, warum dabei unzulässige Reichweite entsteht.
Drei typische Angriffsszenarien
Finance-Worker erbt Supervisor-Rechte
DelegationEin Query-Worker erhält statt eines task-spezifischen Lesetokens den vollständigen API-Kontext des Finance-Agenten und kann Stammdaten ändern oder Zahlungsprozesse anstoßen.
Admin-Zugangsdaten bleiben im nächsten Lauf
SessionEin späterer Standardauftrag läuft im selben Cache- oder Sitzungskontext. Der Agent nutzt Rechte weiter, die nur für ein abgeschlossenes Wartungsfenster gedacht waren.
Schwacher Agent lenkt starken Agenten
Confused DeputyEin niedrig privilegierter Agent formuliert eine interne Delegation, die ein stärkerer Peer ungeprüft als autorisiert übernimmt und mit seinen eigenen Rechten ausführt.
Was wirklich schützt
Wirksamer Schutz hält Identität und Autorisierung über den gesamten Ausführungspfad zusammen. Jede Delegation muss Rechte verkleinern oder erhalten, darf sie aber nie still erweitern.
Eigene Agentenidentitäten sowie kurzlebige Tokens mit enger Audience, Ressource, Aufgabe und Laufzeit statt geteilter Servicekonten verwenden.
Identität, Nutzerabsicht, Zweck, Ressource und Parameter unmittelbar vor Schreibzugriffen, Exporten oder Rechteänderungen serverseitig prüfen.
Credentials nicht in Memory übernehmen, privilegierte Sessions kurz halten und folgenreiche Aktionen durch unabhängige Freigaben schützen.
Ein manipulierter Agent darf nur innerhalb eines eng gebundenen, nachvollziehbaren und jederzeit widerrufbaren Autorisierungskontexts handeln.
Delegationspfade, verwendete Token-Typen und Policy-Entscheidungen sollten gemeinsam protokolliert und korreliert werden. In Multi-Agent-Systemen gehört dazu auch die Absicherung der Inter-Agent-Kommunikation.
Wie Teams Angriffe erkennen und testen
- Auftrag und Scope vergleichen: Angeforderte Rechte müssen zu Nutzerabsicht, Ressource und erwarteter Aktion passen.
- Delegationen nachverfolgen: Agent-ID, Nutzer-ID, Audience, Task-ID und Token-Weitergabe über jeden Hop protokollieren.
- Scope-Drift alarmieren: Neue Admin-Rechte, Impersonation, wiederverwendete Tokens oder unerwartete Write-Zugriffe hervorheben.
- Negativpfade testen: Abgelaufene Sessions, fremde Mandanten, Replay, Peer-Anfragen und versteckte Scope-Erweiterungen gezielt ablehnen lassen.
Ein legitimer Tool-Aufruf ist kein ausreichender Nachweis. Die Telemetrie muss zeigen, wer in wessen Auftrag, mit welchem Scope und für welchen Zweck gehandelt hat. Mehr dazu unter Agent Observability.