Dies ist der vierte Blog-Beitrag einer siebenteiligen Reihe zum Thema Identity-Sicherheit zur Gewährleistung von KI-Sicherheit.
TL;DR: Delegationsketten entwickeln sich zu hochwirksamen Zielen in autonomen Systemen. Jede Übergabe von Agentenaufgaben multipliziert den Zugriff. Angesichts der Tatsache, dass fast alle (97 %) nicht-menschlichen Identities bereits über übermäßige Berechtigungen verfügen, erhöht sich das Risiko mit jeder Übergabe. Bei einer Schwachstelle, die als Agent Session Smuggling (November 2025) bekannt ist, bettet ein Unteragent in eine Standardantwort unauffällig einen stillen Delegationsschritt ein. Der übergeordnete Agent führt ihn dann ohne Benutzerbestätigung und ohne Sichtbarkeit aus. Bei einer anderen Schwachstelle, die als Cross-Agent Privilege Escalation (September 2025) bekannt ist, überschreibt ein Agent die Konfiguration eines anderen Agenten, während dieser eine Aufgabe ausführt, was eine sich selbst verstärkende Kontrollschleife auslösen kann. Delegierungen an sich sind nicht riskant, aber ohne definierten Berechtigungsbereich und kryptografische Herkunft können sie laterale Bewegungen ermöglichen.
Agent Session Smuggling: Wenn Delegation zu einem Exploit wird
Agent-zu-Agent-Delegation trägt dazu bei, ausdrücklich Skalierbarkeit zu ermöglichen: Primäre Agenten lagern komplexe Aufgaben zur gezielten Ausführung an spezialisierte Unteragenten aus.
In der Theorie verringert jeder Schritt die Berechtigungen und gewährleistet eine Abstimmung mit der ursprünglichen Absicht. In der Praxis passiert aber oft das Gegenteil.
Bei einem Proof of Concept (POC) im Rahmen des Agent Session Smuggling-Szenarios forderte ein Finanzassistent-Agent Markteinblicke von einem Forschungsagenten an. Der Unteragent lieferte eine saubere Zusammenfassung sowie einen stillen Delegationsschritt-Befehl. Es wurde keine Warnmeldung ausgelöst und die Delegation erfolgte unbemerkt.
Jede Schicht vertraute der nächsten und es fand keine verifizierte Abstimmung statt. Unit 42 skizzierte, wie der gesamte Exploit-Pfad funktionieren könnte:
- Der Finanzassistent-Agent delegiert die Analyse der Marktnachrichten an den Forschungsagenten.
- Der Forschungsagent ist schädlich und injiziert versteckte Anweisungen in seine Antwort.
- Der Finanzassistent-Agent kauft 10 Aktien, ohne dass dies vom Benutzer genehmigt wurde.
- Der Benutzer sieht nur die Nachrichtenzusammenfassung – der buy_stock-Aufruf wurde nicht angezeigt.
Unit 42 fasst dies wie folgt zusammen:
„Ein kompromittierter Agent ist ein durchaus fähiger Gegner. Unterstützt von KI-Modellen kann ein kompromittierter Agent autonom adaptive Strategien generieren, den Session-Status ausnutzen und seinen Einfluss auf alle verbundenen Client-Agenten ausweiten.“
Bei einem anschaulichen Beispiel für ein potenzielles Szenario mit Rechteausweitung könnte ein kompromittierter Agent die Laufzeitumgebung eines gleichgeordneten Agenten verändern. Dieser Agent, der nun falsch konfiguriert ist, übergibt Aufgaben so, dass die Reichweite des Angreifers vergrößert wird. Wenn die Kette nicht unterbrochen wird, kann sich der Eindringungsversuch durch eine Rückkopplungsschleife verstärken.
Je tiefer Agenten in Finanzwesen, Abläufe und die Infrastruktur integriert sind, desto gefährlicher wird eine ungeprüfte Delegation. Jede nicht verifizierte Aufgabenübergabe wird zu einem Sicherheitsverstoß.
Drei Systeme. Gleiches Fehlermuster.
ServiceNow Now Assist (Oktober 2025)
AppOmni gab bekannt, dass Agenten mit geringen Berechtigungen in ServiceNow Now Assist verwendet werden konnten, um mithilfe der Agentenerkennung andere Agenten mit umfangreicheren Berechtigungen einzubeziehen und Daten zu exfiltrieren.
Agentenübergreifende Rechteausweitung (September 2025)
Johann Rehberger identifizierte die Schwachstelle mit agentenübergreifender Rechteausweitung (Cross-Agent Privilege Escalation) und erklärte, wie ein kompromittierter Agent andere Agenten neu konfigurieren kann, indem er seine Konfiguration umschreibt. In Umgebungen, in denen sich mehrere Agenten (z. B. Copilot, Claude, Gemini) eine Codebasis teilen, kann ein Prompt-injizierter Copilot die .mcp.json von Claude ändern.
Bei der nächsten Verwendung würde Claude beliebigen Code ausführen und dann Copilot neu konfigurieren können. Rehberger dazu:
„Was als eine einzelne indirekte Prompt Injection beginnt, kann schnell zu einer Kompromittierung mehrerer Agenten eskalieren.“
EchoLeak in Microsoft 365 Copilot (Juni 2025)
Aim Security hat „EchoLeak“ aufgedeckt (CVE-2025-32711, CVSS 9.3). Bei diesem Exploit, das keinen Klick erfordert, lösen in E-Mails verborgene Prompts eine stille Exfiltration von SharePoint-, Teams- und OneDrive-Daten aus.
Dasselbe Verwundbarkeitsmuster tritt bei LLM-Orchestrierungs-Frameworks auf, bei denen Ketten von Modellen und Tools Berechtigungsbereiche typischerweise nicht automatisch durchsetzen, so dass Entwickler die Einschränkung manuell verwalten müssen.
Rekursive Delegation: Das Problem der russischen Matroschka-Puppe
Multi-Agenten-Systeme sind für die Aufgabenzerlegung konzipiert, d. h. ein primärer Agent zerlegt komplexe Anfragen in Teilaufgaben und delegiert sie an Spezialisten. Diese Unteragenten können diese Teilaufgaben weiterdelegieren. Mit jeder Delegation wird eine Vertrauensgrenze überschritten, und die Agenten erben die ursprüngliche Autorität.
Die Leitlinie der OpenID Foundation zu agentenbasierter KI bezeichnet dies als wichtigsten Vorteil und größtes Risiko von Agenten-Ökosystemen: „Die wahre Stärke eines Agenten-Ökosystems ergibt sich aus der rekursiven Delegation: der Fähigkeit eines Agenten, eine komplexe Aufgabe zu zerlegen, indem er Teilaufgaben an andere, spezialisiertere Agenten delegiert.“
Aber diese Stärke geht mit einer Warnung einher: „Die Herausforderungen vervielfachen sich exponentiell angesichts rekursiver Delegation, der Einschränkung des Berechtigungsbereichs über Delegationsketten hinweg, Abläufen im Namen des Benutzers, die die Verantwortlichkeit gewährleisten, sowie der Komplexitäten bei der Interoperabilität verschiedener Systeme zur Verwaltung von Agenten-Identities, die miteinander kommunizieren wollen.“
Mit anderen Worten: Was agentenbasierte KI leistungsstark macht, macht sie auch anfällig – es sei denn, die Architektur erzwingt bei jeder Übergabe eine Kontrolle.
Berechtigungsbereich, Herkunft und Kontext = Drei strukturelle Lücken, die Risiken erzeugen
1. Keine Einschränkung des Berechtigungsbereichs an Delegationspunkten. Jeder Agent in einer Delegationskette sollte enger definierte Berechtigungen haben als der vorherige. In der Praxis scheitert dieses Least-Privilege-Prinzip jedoch häufig. Beim Agent Session Smuggling-Szenario erhielt ein Forschungsagent Zugriff auf das buy_stock-Tool eines Finanzassistent-Agenten und führte einen versteckten Aktienkauf aus, der in einer Nachrichtenzusammenfassung eingebettet war. Traditionelle OAuth-Token können nach der Ausstellung nicht ohne erneute Kontaktaufnahme mit dem Authentifizierungsserver eingeschränkt werden, was bei dezentralen Systemen nicht funktioniert. Sichere Delegation benötigt Token-Formate, die die Einschränkung von Berechtigungsbereichen ohne Serverkommunikation (d. h. offline) unterstützen, sodass Agenten den Zugriff unabhängig einschränken können.
2. Kein kryptografischer Nachweis der Delegationsherkunft. OAuth-Token validieren Struktur und Status, können jedoch nicht die Herkunft nachverfolgen. Beim dritten Delegationsschritt gibt es keine kryptografische Verbindung zu dem Agenten oder Benutzer mehr, der die Aktion ausgelöst hat. Aembit erklärt: „Ohne kryptografischen Nachweis können schädliche Agenten Delegations-Claims fälschen und auf Ressourcen zugreifen, auf die sie keinen Zugriff haben sollten.“
3. Keine Session-übergreifende Kontextverankerung. Interaktionen mit mehreren Agenten erfordern eine ständige Abstimmung mit der ursprünglichen Aufgabe. Andernfalls driften Agenten ab und erweitern ihr Verhalten schrittweise über den ursprünglichen Aufgabenbereich hinaus. Unit 42 empfiehlt „Kontextverankerung“, d. h. die Erstellung eines „Ankers“ zur eigentlichen Aufgabe zu Beginn der Session und die kontinuierliche Überprüfung der semantischen Abstimmung.
Einschränkung des Berechtigungsbereichs: Berechtigungen müssen enger werden und dürfen sich nicht erweitern
Neue Token-Formate wie Macaroons, Biscuits und Wafers spiegeln die Architektur wider, die Delegationsketten benötigen, um sicher zu sein. Jedes Token wird mit den wichtigsten Attributen „gebacken“: Identität, Ablaufdatum und kryptographischer Vertrauensanker. Inhaber können Ebenen hinzufügen, die die Berechtigungen nur reduzieren können. Token bleiben offline verifizierbar, wodurch die Integrität erhalten bleibt und eine Eskalation von Berechtigungen verhindert wird.
Obwohl die Syntax je nach Format variiert, ist das eigentliche Muster konsistent: Token können lokal eingeschränkt, aber niemals erweitert werden:
Jeder Unteragent fügt einen signierten Caveat hinzu, der nur angehängt werden kann und den Umfang des Tokens einschränkt. Dadurch wird eine überprüfbare Kette bildet, über die der Aussteller den vollständigen Delegationspfad nachverfolgen kann. Wenn ein Forschungsagent versucht, buy_stock auszuführen, schlägt die Anfrage fehl. Dabei kann anhand von Nachweisen nachvollzogen werden, wer was und wo eingeschränkt hat.
Obwohl Macaroons und Biscuits derzeit von keinem großen Identity-Anbieter nativ unterstützt werden, können ihre Grundprinzipien (Offline-Einschränkung des Berechtigungsbereichs, kryptografische Delegation und nur anhängbare Einschränkungen) mithilfe der vorhandenen OAuth-Infrastruktur bereits angewendet werden.
Abwehr von Angriffen mit rekursiver Delegation
Diese Schwachstellen im Zusammenhang mit der KI-Agenten-Delegation legen vier wichtige Schutzmaßnahmen nahe:
1. Out-of-Band-Bestätigung: Sensible Aktionen erfordern die Zustimmung des Benutzers über Kanäle, auf die Agenten nicht zugreifen können, z. B. Push-Benachrichtigungen oder eine separate Benutzeroberfläche. Ein Chat ist nicht geeignet.
2. Kontextverankerung: Sessions müssen mit der der ursprünglichen Aufgabe verankert werden und vor der Ausführung muss auf semantische Abweichungen hingewiesen werden.
3. Verifizierte Identität und Fähigkeiten: Agenten müssen signierte Anmeldedaten übermitteln (z. B. kryptografische AgentCards).
4. Sichtbarkeit für Benutzer: Eingeschleuste Anweisungen sind erfolgreich, wenn sie verborgen bleiben, daher müssen Tool-Aufrufe sichtbar gemacht und protokolliert werden.
Wie Okta und Auth0 rekursive Delegation handhaben
Die unabhängige Implementierung dieser Kontrollen kann zu blinden Flecken führen. Okta und Auth0 begegnen der rekursiven Delegation mit einer einheitlichen Identitätsschicht:
Cross-App Access (XAA). XAA ist bei Okta und Auth0 verfügbar und verlagert die Zustimmung zum Identity-Anbieter, jetzt Teil von MCP (ab November 2025) unter „Enterprise-Managed Authorization“. XAA basiert auf ID-JAG und kann die Delegationsherkunft verfolgen und widerrufen, sodass Agentenaktionen protokolliert und widerrufen werden können.
Token Vault. Auth0 Token Vault löst das Confused-Deputy-Problem bei Zugriffen mit Agent-Zugangsdaten. Naive APIs ermöglichen Entwicklern die Übergabe von userId-Parametern, wodurch Systeme Programmfehlern oder Prompt Injections ausgesetzt werden, die die Anmeldedaten eines anderen Benutzers abrufen könnten. Token Vault verhindert dies, da ein kryptografischer Nachweis der aktuellen Benutzer-Session (niemals eine einfache Kennung) abgefragt wird. Agenten verwenden OAuth 2.0 Token Exchange (RFC 8693), um Sitzungs-Token in kurzlebige Anmeldedaten mit festgelegtem Berechtigungsbereich umzuwandeln und so auch mit Standardprotokollen eine präzise Einschränkung des Berechtigungsbereichs zu erreichen.
Asynchrone Autorisierung. Auth0 Async Auth ermöglicht eine Out-of-Band-Genehmigung per Push-Benachrichtigung oder E-Mail und behebt die Agent Session Smuggling-Schwachstelle direkt, da eine menschliche Bestätigung über Kanäle abgefragt wird, die das LLM nicht manipulieren kann.
Feingranulare Autorisierung. Auth0 FGA basiert auf dem Zanzibar-Modell von Google und erzwingt bei jedem Aufruf einen beziehungsbasierten Zugriff. Agenten validieren und aktualisieren den Delegationsstatus bei jeder Übergabe und schränken die Berechtigungen progressiv ein. Dieser statusbasierte Kontext wird in FGA (nicht im Token) erfasst, was eine Einschränkung der Berechtigungen ermöglicht, ohne dass neue Token-Formate erforderlich sind.
Identity Governance. Okta Identity Governance erweitert die Lebenszyklusverwaltung auf Agenten und trägt dazu bei, dass delegierte Berechtigungen überprüft und widerrufen werden, wenn sich Rollen, Projekte oder Sicherheitskontexte ändern. Was bei der Bereitstellung angemessen war, kann schnell zu umfassend werden. Governance ermöglicht die kontinuierliche Anpassung der Agentenautorität.
Der Weg in die Zukunft: Delegierungen, die sich selbst beweisen
Multi-Agenten-Systeme bieten Fähigkeiten, die über die Möglichkeiten eines einzelnen Agenten hinausgehen, führen jedoch auch zu Lücken, die klassische IAM-Lösungen nicht schließen können. Jede hier beschriebene Schwachstelle hat das gleiche Muster: Agenten erlangen mehr Befugnisse als beabsichtigt, agieren ohne Wissen des Benutzers und hinterlassen keinen Audit-Trail.
Die Gewährleistung der Sicherheit von Delegierungen erfordert vier Grundlagen: Einschränkung des Berechtigungsbereichs bei jeder Übergabe, Überprüfung der Token-Herkunft, konsistente Abstimmung des Kontexts und Out-of-Band-Genehmigung durch einen Menschen bei sensiblen Aktionen.
Dies ist nicht mehr optional. Das EU-Gesetz zur künstlichen Intelligenz (EU AI Act) schreibt Rückverfolgbarkeit und Aufsicht bei risikoreichen Systemen als gesetzliche Verpflichtung vor. Artikel 14 schreibt vor, dass Menschen die Aktivitäten von KI vollständig verstehen und überwachen.
Ohne überprüfbare Delegationsketten ist diese Aufsicht nicht möglich. Wenn Ihre Infrastruktur keine überprüfbare Kontrolle ermöglicht, hält sie die Compliance-Vorgaben nicht ein.
Im fünften Teil unserer Blog-Reihe erfahren Sie, was passiert, wenn KI-Agenten physische Systeme steuern, bei denen ein einziger Fehler realen Schaden verursachen kann und eine sichere Identity zur letzten Verteidigungslinie wird.
