Autorisierungspropagierung erklärt: Warum Zugriffskontrolle auf Anfrageebene nicht ausreicht

Die Sicherheitsdiskussion rund um KI-Agenten wurde so lange von einem einzigen Angriffstyp dominiert – Prompt Injection –, dass ein stilleres, strukturelles Problem lange unbenannt blieb. Jetzt hat es einen Namen: Autorisierungspropagierung, vorgeschlagen in einem arXiv-Preprint vom Mai 2026 von Kamiwaza (mit vorläufigen Implementierungsnachweisen), „Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure“ (Tallam, arXiv:2605.05440), dessen These wir in sechs eigenen zitierten Wörtern zusammenfassen können – „We call this problem authorization propagation“ – und in einem Satz umschreiben: Während nicht-menschliche Akteure Daten abrufen, Aufgaben delegieren und Ergebnisse über sich ändernde Grenzen hinweg synthetisieren, besteht das eigentliche Problem darin, Autorisierungsinvarianten über die gesamte Kette hinweg aufrechtzuerhalten, und es ist weder auf Prompt Injection reduzierbar noch durch die klassischen Zugriffskontrollmodelle – RBAC, ABAC, ReBAC –, die Unternehmen bereits einsetzen, vollständig lösbar. Das Papier zerlegt das Problem in drei Teilbereiche, die jeder Multi-Agenten-Betreiber sofort wiedererkennen wird. Transitive Delegation: Agent A, der für eine Aufgabe autorisiert ist, delegiert eine Teilaufgabe an Agent B – was darf B tun, in wessen Namen, und was verhindert, dass sich die Kette bei jedem Schritt ausweitet? Aggregationsinferenz: Jeder Abruf innerhalb eines Workflows ist einzeln zulässig, aber die Synthese führt zu einem Ergebnis, für das kein einzelner Akteur eine Freigabe hatte. Zeitliche Gültigkeit: Die Autorisierung war zu Beginn des Workflows gültig – ist sie das auch noch bei Schritt vierzig, eine Stunde später, nachdem die Berechtigung widerrufen wurde? Dies sind Eigenschaften auf Workflow-Ebene, nicht auf Anfrageebene. Genau deshalb können die Mechanismen der letzten zwei Jahrzehnte, die auf Anfragen basieren, diese Lücken nicht schließen. Dieser Leitfaden dient als Referenz für Unternehmen: Was Autorisierungspropagierung ist, woher sie kommt, wie sie sich von anderen Problemen unterscheidet, unter denen sie oft eingeordnet wird – und welche Infrastruktur ausgewählte Invarianten für beteiligte Abläufe unterstützen kann. Während die Aggregationsinferenz laut dem Papier selbst ein offenes Problem bleibt, für das es derzeit keine vollständige Architektur gibt – gemäß dem Untertitel des Papiers: Identitäts-Governance als Infrastruktur. Wie bei allen unseren Referenzen zu neuen Begriffen werden wir diese Seite aktualisieren, sobald sich die Forschung und das Vokabular weiterentwickeln.

Was ist Autorisierungspropagierung? Eine Definition

Autorisierungspropagierung ist das Problem der Wahrung von Autorisierungsinvarianten – die Zusicherungen darüber, wer auf was zugreifen darf, die zu Beginn eines Workflows festgelegt werden –, während die Arbeit dieses Workflows von mehreren nicht-menschlichen Akteuren ausgeführt wird, die Daten abrufen, Aufgaben untereinander delegieren und Ergebnisse über Systemgrenzen hinweg zusammenführen. Der definitorische Schritt, der den Begriff nützlich macht, ist die Verschiebung der Analyseeinheit: Klassische Zugriffskontrolle bewertet eine Anfrage (dieser Akteur, diese Ressource, dieser Zeitpunkt) und ist in dieser Granularität weitgehend gelöst; die Autorisierungspropagierung bewertet einen Workflow – die Kette von Anfragen, Delegierungen und Kombinationen – und fragt, ob die zu Beginn vorhandene Berechtigung bei jedem Schritt und bis zum Endergebnis zuverlässig gewahrt bleibt. Die drei Teilprobleme benennen die Arten, wie dies scheitern kann. Transitive Delegierung: wenn Agent A an B delegiert und B an C, ist jeder Schritt eine Gelegenheit für eine Ausweitung der Berechtigungen – B agiert mit den Anmeldedaten von A plus den eigenen, C sammelt beide –, bis eine Aktion tief in der Kette mit einem effektiven Berechtigungssatz ausgeführt wird, den nie ein Mensch erteilt hat; der klassische „Confused Deputy“ ist der einstufige Vorläufer dieses Problems, der sich nun mit der Kettenlänge potenziert. Aggregationsinferenz: die fünf Abrufe eines Forschungsagenten sind jeweils einzeln autorisiert, aber die Synthese – Gehaltsbänder verknüpft mit Organigrammen und Leistungsnotizen – stellt eine Offenlegung auf einem Sensitivitätsniveau dar, das durch keine der einzelnen Freigaben impliziert war; Anfragen auf Einzel-Ebene werden fünfmal erfolgreich geprüft, während die Invariante auf Workflow-Ebene einmal unsichtbar verletzt wird. Zeitliche Gültigkeit: Agenten-Workflows laufen lange – Stunden, Tage, dauerhaft –, während Berechtigungen widerrufen werden, Rollen sich ändern und Token ablaufen; eine Autorisierung, die nur beim ersten Schritt geprüft wird, ist eine Momentaufnahme, die als Garantie präsentiert wird. Zur Abgrenzung gegenüber ähnlichen Begriffen: Dies ist keine Authentifizierung (der Nachweis, wer ein Akteur ist – die Voraussetzung, die in der MCP-Auth-Literatur behandelt wird), keine Prompt-Injection (ein Manipulationsangriff; dieses Problem benötigt keinen Angreifer) und keine Autorisierung im Allgemeinen – es geht spezifisch um die Propagierung von Autorisierung durch Arbeit, die mehrere Akteure und Schritte umfasst und Systemgrenzen überschreitet.

Eine kurze Geschichte: Von Confused Deputies zu nicht-menschlichen Akteuren

Die Herkunft des Problems ist Jahrzehnte älter als der Begriff selbst, was ein Grund dafür ist, warum die Benennung wichtig ist. Der Confused Deputy – ein privilegiertes Programm, das dazu verleitet wird, seine Autorität im Namen eines Aufrufers zu missbrauchen – wurde 1988 beschrieben und prägte das auf Fähigkeiten basierende Sicherheitsdenken für eine Generation; die Delegierungsabläufe von OAuth, SAML-Assertionen und die Debatten über Identitätswechsel versus Delegierung in der SOA-Ära waren allesamt Teilantworten für eine Welt, in der die Akteure Anwendungen waren und die Ketten kurz. Die 2010er Jahre brachten Skalierung, aber keine strukturelle Änderung: Microservices machten die Identität zwischen Diensten zu einer Disziplin (mTLS, SPIFFE, Workload-Identität), und die IAM-Branche begann davon zu sprechen, dass nicht-menschliche Identitäten die menschlichen an Zahl übertreffen. Was sich 2024–2026 änderte, ist, dass die nicht-menschlichen Akteure autonom und kompositionell wurden: Agenten, die zur Laufzeit entscheiden, welche Tools sie aufrufen, Sub-Agenten mit Teilmengen (oder versehentlichen Obermengen) ihrer Befugnisse erstellen und Ergebnisse aus allem synthetisieren, womit sie in Berührung kamen – Ketten, die lang, dynamisch und ungeplant sind, genau so, wie es die klassischen Mechanismen ausgeschlossen haben. Die Diskussion verfolgte diese Entwicklung schrittweise – MCP-Authentifizierungs- und Autorisierungsleitfäden, Zero-Trust-Frameworks für Agenten, die Welle der identitätsbasierten Sicherheit, unsere eigene Bestandsaufnahme der Agentenidentitäten – bis Mai 2026, als das Kamiwaza-Papier den Rahmen für das gesamte Thema absteckte: Es benannte das Problem, grenzte es von Injection ab, formalisierte die drei Teilprobleme und leitete sieben strukturelle Anforderungen für Architekturen ab, die die Invarianten wahren. Unsere grundlegende Auffassung bleibt bestehen: Die Benennung folgt der Praxis – jedes Unternehmen, das Multi-Agenten-Workflows betreibt, hat diese drei Probleme heute, ob benannt oder nicht – und mit der Benennung beginnen die Beschaffungsfragen in der richtigen Analyseeinheit gestellt zu werden: dem Workflow, nicht der Anfrage.

Autorisierungspropagierung vs. Prompt Injection, RBAC und Authentifizierung

Drei Kontraste definieren den Begriff, und jeder korrigiert einen häufigen Einordnungsfehler. Im Vergleich zu Prompt Injection: Injection ist ein Angriff – ein Angreifer manipuliert einen Agenten, damit dieser seine rechtmäßig innehabenden Befugnisse missbraucht; Propagierungsfehler benötigen keinen Angreifer – gewöhnliche Delegation, hilfreiche Synthese und lang laufende Workflows erzeugen sie standardmäßig. Das bedeutet, dass eine Umgebung gegen Injection gehärtet sein kann und dennoch durch ihre eigene Berechtigungsstruktur Daten preisgibt. Sie überschneiden sich (ein injizierter Agent mit erweiterten effektiven Berechtigungen ist ein schwerwiegenderer Vorfall), aber die Lösung des einen Problems berührt das andere nicht. Die zentrale Kritik des Papiers ist, dass der Fokus der Sicherheitsdiskussion auf Injection das strukturelle Problem unbenannt ließ. Im Vergleich zu RBAC/ABAC/ReBAC: Die klassischen Modelle sind Richtliniensprachen für den Zeitpunkt der Anfrage – mächtige, notwendige Eingaben, die jedoch für sich genommen keine Invarianten auf Workflow-Ebene beweisen können. Denn eine Rollenprüfung kann nicht erkennen, dass sich Befugnisse über mehrere Stationen hinweg angesammelt haben, eine ressourcenbezogene Regel kann nicht sehen, was die Synthese zusammengefügt hat, und eine zum Zeitpunkt der Anfrage evaluierte Richtlinie kann nicht erkennen, dass der zugehörige Workflow unter Berechtigungen gestartet wurde, die inzwischen widerrufen wurden. Die Modelle sind Eingaben für eine Lösung, nicht die Lösung selbst: Die Invarianten existieren auf einer Ebene, die diese Modelle nicht bewerten. Im Vergleich zur Authentifizierung: zu wissen, wer jeder Akteur ist – die OAuth-Flows, der Token-Austausch, die Workload-Identität – ist die Voraussetzung, auf der dieses Problem aufbaut; Propagierung ist das, was Bestand haben muss, nachdem jeder korrekt identifiziert wurde. Deshalb beantwortet „Wir haben SSO für unsere Agenten“ eine andere Frage als die, die dieser Begriff stellt. Die Zusammenfassung aller drei Kontraste in einem Satz: Die Branche hat zwei Jahre damit verbracht, die Anfrage und den Promptzu sichern; Autorisierungspropagierung ist die Sicherheit der Kette.

Autorisierungspropagierung im Unternehmen: Identity Governance als Infrastruktur

Hier setzt TrueFoundry an, und der Untertitel des Papiers hat die Argumentationsstruktur bereits vorgegeben: Die Invarianten können nicht dadurch gewahrt werden, dass jedes Agententeam zu deren Implementierung aufgefordert wird – sie müssen Eigenschaften der Schicht sein, die jeder Agentenaufruf ohnehin durchläuft. Betrachten wir die drei Teilprobleme im Kontext der dokumentierten Mechanismen. Transitive Delegation wird dort gesteuert, wo die Delegation stattfindet: Die Reichweite der Agenten-Tools fließt durch das MCP Gateway, wobei die nutzerspezifische Delegation bedeutet, dass ein nachgelagerter Aufruf die Autorität des ursprünglichen Prinzipals in jedes System überträgt – das CRM sieht die Berechtigungen des Nutzers, nicht die des Agenten – und aufgabenbasierte Bereichsbegrenzung bedeutet, dass ein gestarteter Agent eine eingeschränkte Berechtigung erhält, die von der seines übergeordneten Elements abgeleitet ist, niemals eine akkumulierte Gesamtmenge; die Invariante „Befugnisse können sich verengen, aber niemals erweitern“ wird zu einer strukturellen Eigenschaft der Berechtigungsausstellung, anstatt eine Konvention zu sein, an die sich Teams erinnern müssen – die Disziplin, die unsere TBAC-Analyse und OAuth-auf-MCP-Ebene im Detail ausarbeiten. Zeitliche Gültigkeit wird zur Eigenschaft des Tokens statt zum Versprechen des Workflows: Kurzlebige, automatisch aktualisierte und zentral widerrufbare Anmeldedaten bedeuten, dass eine Berechtigung, die in Schritt zwölf entzogen wurde, den Tool-Aufruf in Schritt dreizehn fehlschlagen lässt – die Prüfung wird bei jedem Sprung erneut durchgeführt, da jeder Sprung die Ebene durchquert, die der einzige Ort ist, an dem „noch gültig jetztkann kontinuierlich für einen Workflow beantwortet werden, der über seine ursprünglichen Startbedingungen hinaus Bestand hat. Aggregationsinferenz ist der offene Härtefall – kein Gateway berechnet im Allgemeinen die Sensitivität einer Synthese – und der Beitrag der Infrastruktur besteht darin, sie steuerbarzu machen: Anfrage-Traces auf Chain-Ebene erfassen vermittelte Abrufe und Aufrufe mit ihren aufgelösten Identitäten – ein Nachweis für die Audit-Prüfung beteiligter Operationen, kein automatisches Autorisierungsurteil darüber, was der Workflow zusammengestellt hat; Leitplanken für Tool-Outputs und Modellantworten erzwingen die definierbaren Grenzen (PII-Klassen, eingeschränkte Quellen, die in nicht eingeschränkte Outputs gelangen); und die Multi-Agenten-Koordinationsschicht, die unsere A2A-Governance -Arbeit abdeckt, hält die Inter-Agenten-Sprünge auf derselben auditierten Ebene wie die Tool-Sprünge, sodass die Kette keine dunklen Segmente aufweist. Das Dokument fordert Architekturen mit strukturellen Anforderungen; die Ebene ist der Punkt, an dem diese Anforderungen aufhören, technisches Engineering pro Team zu sein, und zu einer Konfigurationsfrage werden.

Checkliste zur Autorisierungspropagierung im Unternehmen

Sechs Fragen für jede Multi-Agenten-Umgebung: Durchläuft jeder Agent-zu-Tool- und Agent-zu-Agent-Sprung eine gesteuerte Schicht, oder gibt es direkte Integrationen, bei denen die Kette im Dunkeln bleibt? Wird die Delegation als Anmeldeinformations- ableitung implementiert? – Kind-Scopes strikt innerhalb von Eltern-Scopes – statt der gemeinsamen Nutzung von Anmeldedaten? Sehen nachgelagerte Systeme die Berechtigung des ursprünglichen Prinzipals (benutzerbezogene Delegation) anstelle der allgemeinen Berechtigung eines Dienstkontos? Sind Anmeldedaten kurzlebig und zentral widerrufbar, sodass die zeitliche Gültigkeit bei jedem Sprung neu hergestellt wird, anstatt sie vom ersten Schritt an vorauszusetzen? Kann ein Prüfer den vollständigen Abruf- und Synthese-Fußabdruck eines Workflows anhand von Traces rekonstruieren? Und ist jemand für die Aggregationsfrage verantwortlich – also für die Überprüfung dessen, was Workflows mit hohen Privilegien zusammenstellen, nicht nur, worauf sie zugreifen? Sechs Ja-Antworten bedeuten Identitäts-Governance als Infrastruktur; die Nein-Antworten sind die Stellen, an denen die Compliance der Kette nur ein Zufall ist.

Die Zukunft der Autorisierungspropagierung: Was wir beobachten werden

Vorhersagen mit Vorsicht. Erwarten Sie, dass sich der Begriff schnell von der Forschung in die Praxis verbreitet, denn – ähnlich wie bei der Governance-Erosion, dem Geschwisterbegriff der Saison – benennt er Fehler, die Betreiber bereits haben: den überberechtigten Sub-Agenten, der bei einem Audit gefunden wurde, die Synthese, bei der die Rechtsabteilung zusammenzuckte, den Workflow, der trotz widerrufener Berechtigung weiterlief; Vokabular, das bestehende Vorfälle erklärt, wird in den Post-Mortems übernommen. Erwarten Sie, dass die Standardisierungsgremien ihn verarbeiten: Die MCP- und A2A-Ökosysteme konvergieren bereits bei Delegationssemantiken, und „wie hält Ihr Protokoll Autorisierungsinvarianten über Sprünge hinweg aufrecht“ ist die präzise Frage, die das Papier den Prüfern an die Hand gibt – wir würden darauf wetten, dass die Sprache der Propagierung innerhalb eines Jahres in Sicherheitsüberprüfungen von Agentenprotokollen auftaucht. Erwarten Sie, dass die Aggregationsinferenz die hartnäckige Grenze bleibt: Delegation und zeitliche Gültigkeit haben klare strukturelle Antworten; was die Synthese enthüllt hat, ist ein Semantikproblem, das Anbieter von Datenklassifizierung, DLP und Output-Guardrails in die Agenten-Diskussion ziehen wird, wobei kettenweite Traces das Substrat sind, das sie alle benötigen werden. Erwarten Sie, dass die Welle der nicht-menschlichen Identitäten in der IAM-Branche produktiv mit diesem Rahmen kollidiert – NHI-Governance gibt den Prinzipals Namen; Propagierung ist das, was die benannten Prinzipals bewahren müssen – und erwarten Sie, dass die Beschaffung all dies in eine Frage komprimiert, die diese Seite beantworten soll: nicht „haben Ihre Agenten Identitäten“, sondern „halten Ihre Ketten ihre Invarianten ein“. Wir werden diesen Leitfaden aktualisieren, während sich Forschung und Vokabular weiterentwickeln; der dauerhafte Anspruch ist die Neuausrichtung, die sich das Papier verdient hat: Die letzten zwei Jahre sicherten die Anfrage und den Prompt – die nächsten zwei Jahre drehen sich um die Sicherung der Kette.

FAQ zur Autorisierungspropagierung

Was ist Autorisierungspropagierung in KI-Systemen?

Autorisierungspropagierung ist das Problem der Aufrechterhaltung von Autorisierungsinvarianten, während mehrere KI-Agenten Daten abrufen, Aufgaben delegieren und Ergebnisse über Systemgrenzen hinweg synthetisieren – und sicherstellen, dass die Berechtigung, mit der ein Workflow begann, bei jedem Sprung getreu bewahrt bleibt. Der Begriff wurde in einem Preprint eines einzelnen Autors vom Mai 2026 (arXiv:2605.05440) vorgeschlagen, das ihn in transitive Delegation, Aggregationsinferenz und zeitliche Gültigkeit zerlegt.

Wie unterscheidet sich Autorisierungspropagierung von Prompt Injection?

Prompt Injection ist ein Angriff, bei dem ein Angreifer einen Agenten dazu manipuliert, eine Berechtigung, die er rechtmäßig besitzt, missbräuchlich zu verwenden. Fehler bei der Autorisierungspropagierung benötigen keinen Angreifer: Gewöhnliche Delegationsketten erweitern Berechtigungen, individuell erlaubte Abrufe synthetisieren sich zu unerlaubten Offenlegungen, und lange Workflows überdauern ihre Berechtigungen. Ein gegen Injection gehärtetes System kann dennoch durch seine eigene Berechtigungsstruktur lecken.

Warum lösen RBAC oder ABAC die Autorisierungspropagierung nicht?

Weil es sich um Modelle zum Zeitpunkt der Anfrage handelt: Eine Rollen- oder Attributprüfung bewertet einen Prinzipal, eine Ressource, einen Moment. Die Propagierungsfehler liegen auf Workflow-Ebene – Berechtigungen akkumulieren sich über Sprünge hinweg, Synthesen überschreiten jede einzelne Berechtigung, die Gültigkeit läuft mitten in der Kette ab – was Prüfungen auf Anfrageebene strukturell nicht sehen können. Die klassischen Modelle bleiben notwendige Eingaben; die Invarianten müssen auf der Ebene durchgesetzt werden, die die gesamte Kette durchläuft.

Wie halten Unternehmen Autorisierungsinvarianten über Agenten-Delegationsketten hinweg aufrecht?

Indem Invarianten zu Eigenschaften der Infrastruktur gemacht werden: Leiten Sie jeden Agent-zu-Tool- und Agent-zu-Agent-Sprung durch ein gesteuertes Gateway; implementieren Sie Delegation als bereichsbezogene Ableitung von Anmeldedaten (für registrierte Agent-zu-Agent-Aufrufe, die über das Agent Gateway geleitet werden, kann ein bereichsbezogener Token-Austausch helfen, Subjekt, Akteur, Zielgruppe und autorisierten Bereich zu bewahren – während Harness-Subagenten derzeit die Tools und die Sandbox des Root-Runs teilen, anstatt unabhängig eingeschränkte Berechtigungsumschläge zu erhalten); verwenden Sie konfigurierte benutzerbezogene Delegation, wo unterstützt, damit nachgelagerte Systeme die Berechtigung des ursprünglichen Prinzipals sehen können; halten Sie Anmeldedaten kurzlebig und zentral widerrufbar, damit die zeitliche Gültigkeit bei vermittelten Sprüngen wiederhergestellt werden kann, vorbehaltlich der Token-Lebensdauer und der nachgelagerten Validierungssemantik; und zeichnen Sie Traces vermittelter Operationen auf, damit der Abruf- und Synthese-Fußabdruck eines Workflows für die beteiligte Ebene überprüfbar ist.

Referenzen

• Anchor – Tallam, "Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure" (Kamiwaza AI, arXiv:2605.05440, Mai 2026: die Begriffsbildung; die Argumente, dass es nicht auf Injection reduzierbar ist und über RBAC/ABAC/ReBAC hinausgeht; die drei Teilprobleme; die sieben strukturellen Anforderungen).
• TrueFoundry-Dokumentation – MCP Gateway (benutzerbezogene Delegation; offizielles Architekturdiagramm); MCP-Authentifizierung & Sicherheit; Anfrage-Traces und Analysen (offizielles Bild); Leitplanken.
• Dieser Blog – TBAC: aufgabenbasierte Zugriffskontrolle; OAuth und Token-Management auf der MCP-Ebene; Multi-Agenten-A2A-Governance; die Agenten-Identitätszählung; MCP-Gateway vs. Proxy vs. Router.

Es wird ein direktes Zitat aus dem zitierten Dokument verwendet, das weniger als fünfzehn Wörter umfasst und im Text zugeordnet ist; die Argumente, Teilprobleme und Anforderungen des Dokuments werden ansonsten paraphrasiert. Leser sollten für die formale Behandlung das Original konsultieren. Die Zuordnung der Anforderungen aus dem Dokument zu den Mechanismen von TrueFoundry stellt unsere redaktionelle Einordnung dar; der Autor des Dokuments und Kamiwaza AI erwähnen oder unterstützen TrueFoundry nicht. Die Produktfunktionen wurden aus der zum Zeitpunkt der Erstellung aktuellen öffentlichen Dokumentation paraphrasiert; die Produktbilder sind Dokumentationsmaterial von TrueFoundry und werden mit Quellenangabe wiedergegeben. Dies ist ein lebendiges Referenzdokument, das bei Weiterentwicklung der Forschung und Terminologie überarbeitet wird.

‍