Authorization propagation uitgelegd: Waarom toegangsbeheer op verzoekniveau niet volstaat

De beveiligingsdiscussie rond AI-agents wordt al zo lang gedomineerd door één aanval — prompt injection — dat een stiller, structureel probleem onbenoemd bleef. Het heeft nu een naam: authorization propagation, voorgesteld in een arXiv-preprint van één auteur van Kamiwaza uit mei 2026 (met voorlopige implementatiebewijzen), "Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure" (Tallam, arXiv:2605.05440), waarvan we de stelling in zijn eigen geciteerde woorden kunnen samenvatten — "We call this problem authorization propagation" — en in één zin kunnen parafraseren: wanneer niet-menselijke principals gegevens ophalen, taken delegeren en resultaten synthetiseren over veranderende grenzen heen, is het harde probleem het behouden van autorisatie-invarianten gedurende de hele keten, en dit is noch te herleiden tot prompt injection, noch volledig op te lossen met de klassieke toegangsbeheermodellen — RBAC, ABAC, ReBAC — die bedrijven al draaien. De paper verdeelt het probleem in drie benoemde subproblemen die elke multi-agent operator onmiddellijk zal herkennen zodra ze worden genoemd. Transitieve delegatie: agent A, geautoriseerd voor een taak, delegeert een subtaak aan agent B — wat mag B doen, op wiens gezag, en wat voorkomt dat de keten bij elke stap breder wordt? Aggregatie-inferentie: elke afzonderlijke ophaalactie in een workflow is toegestaan, maar de synthese voegt iets samen dat geen enkele afzonderlijke principal mocht zien. Temporele validiteit: de autorisatie was geldig toen de workflow begon — is deze nog steeds geldig bij stap veertig, een uur later, nadat de toekenning is ingetrokken? Dit zijn eigenschappen op workflow-niveau, niet op verzoekniveau, en dat is precies waarom de mechanismen op verzoekniveau van de afgelopen twee decennia ze niet afdekken. Deze gids is de enterprise-referentie voor de term: wat authorization propagation is, waar het vandaan komt, hoe het verschilt van de problemen waar het vaak onder wordt geschaard — en de infrastructuur die geselecteerde invarianten voor deelnemende operaties kan ondersteunen — terwijl aggregatie-inferentie, volgens de paper zelf, een open probleem blijft dat geen enkele huidige architectuur volledig oplost — conform de ondertitel van de paper: identity governance als infrastructuur. Zoals met al onze referenties voor nieuwe termen, zullen we deze pagina bijwerken naarmate het onderzoek en het vakjargon zich verder ontwikkelen.

Wat is Authorization Propagation? Een definitie

Authorization propagation is het probleem van het behouden van autorisatie-invarianten — de waarborgen over wie waar toegang toe heeft, vastgesteld bij de start van een workflow — terwijl het werk van die workflow wordt uitgevoerd door meerdere niet-menselijke principals die gegevens ophalen, taken aan elkaar delegeren en resultaten synthetiseren over systeemgrenzen heen. De definitieve stap die de term nuttig maakt, is de verschuiving in analyse-eenheid: klassiek toegangsbeheer beoordeelt een verzoek (deze principal, deze bron, dit moment) en is op dat niveau grotendeels opgelost; authorization propagation beoordeelt een workflow — de keten van verzoeken, delegaties en combinaties — en vraagt of de autoriteit die bij de start aanwezig was, getrouw behouden blijft bij elke stap en in het uiteindelijke resultaat. De drie subproblemen benoemen de manieren waarop het misgaat. Transitieve delegatie: wanneer agent A delegeert aan B en B aan C, is elke stap een kans voor autoriteit om uit te breiden — B draait met de credentials van A plus die van zichzelf, C verzamelt ze beide — totdat een actie diep in de keten wordt uitgevoerd met een effectieve permissieset die geen enkele mens ooit heeft verleend; de klassieke "confused deputy" is de voorouder van één stap van dit probleem, die zich nu opstapelt naarmate de keten langer wordt. Aggregatie-inferentie: de vijf ophaalacties van een onderzoeksagent zijn elk afzonderlijk geautoriseerd, maar de synthese — salarisschalen gekoppeld aan organisatiegrafieken gekoppeld aan prestatie-opmerkingen — vormt een onthulling op een gevoeligheidsniveau dat geen van de individuele toekenningen impliceerde; controles op verzoekniveau slagen vijf keer terwijl de invariant op workflow-niveau één keer, onzichtbaar, faalt. Temporele validiteit: agent-workflows lopen lang — uren, dagen, continu — terwijl toekenningen worden ingetrokken, rollen veranderen en tokens verlopen; een autorisatie die alleen bij stap één wordt gecontroleerd, is een momentopname die wordt gepresenteerd als een garantie. Een verduidelijking voor gerelateerde zoekopdrachten: dit is geen authenticatie (bewijzen wie een principal is — de voorwaarde, behandeld in de MCP-auth-literatuur), geen prompt injection (een manipulatie-aanval; voor dit probleem is geen aanvaller nodig), en geen autorisatie in het algemeen — het is specifiek de propagatie van autorisatie door werk dat uit meerdere stappen, meerdere principals en meerdere grenzen bestaat.

Een korte geschiedenis: Van Confused Deputies naar niet-menselijke principals

De oorsprong van het probleem is decennia ouder dan de term zelf, wat deels verklaart waarom de naamgeving van belang is. De confused deputy — een bevoorrecht programma dat wordt misleid om zijn autoriteit te misbruiken namens een aanroeper — werd beschreven in 1988 en vormde een generatie lang het denken over capability-gebaseerde beveiliging; de delegatieflows van OAuth, SAML-beweringen en de discussies over impersonatie versus delegatie in het SOA-tijdperk waren allemaal gedeeltelijke antwoorden voor een wereld waarin de principals applicaties waren en de ketens kort. De jaren 2010 brachten schaal, maar veranderden de vorm niet: microservices maakten service-to-service identiteit tot een vakdiscipline (mTLS, SPIFFE, workload identity), en de IAM-sector begon te spreken over niet-menselijke identiteiten die de menselijke in aantal overtroffen. Wat veranderde in 2024–2026 is dat de niet-menselijke principals autonoom en compositioneel werden: agents die tijdens runtime beslissen welke tools ze aanroepen, sub-agents aanmaken met subverzamelingen (of per ongeluk superverzamelingen) van hun autoriteit, en alles wat ze hebben aangeraakt synthetiseren — ketens die lang, dynamisch en ongepland zijn, precies op de manieren die de klassieke mechanismen negeerden. De discussie volgde de ontwikkeling stapsgewijs — MCP-authenticatie- en autorisatiegidsen, zero-trust-frameworks voor agents, de identity-first beveiligingsgolf, onze eigen agent identity census — tot mei 2026, toen de paper van Kamiwaza het geheel afkaderde: het probleem benoemde, het scheidde van injection, de drie subproblemen formaliseerde en zeven structurele vereisten afleidde voor architecturen die de invarianten behouden. Onze vaste benadering blijft van toepassing: de naamgeving loopt achter op de praktijk — elk bedrijf dat multi-agent workflows draait heeft vandaag de dag te maken met deze drie problemen, benoemd of niet — en de naamgeving is het moment waarop de inkoopvragen gesteld gaan worden in de juiste analyse-eenheid, namelijk de workflow, niet het verzoek.

Authorization propagation vs Prompt injection, RBAC en Authenticatie

Drie contrasten verduidelijken de term, en elk daarvan corrigeert een veelvoorkomende verkeerde categorisering. Versus prompt injection: injection is een aanval — een kwaadwillende die een agent manipuleert om autoriteit te misbruiken die hij rechtmatig bezit; propagatiefouten hebben geen kwaadwillende nodig — gewone delegatie, nuttige synthese en langlopende workflows veroorzaken ze standaard, wat betekent dat een omgeving beveiligd kan zijn tegen injection en toch data kan lekken via de eigen permissiestructuur. Ze overlappen elkaar (een geïnjecteerde agent met een uitgebreide effectieve permissieset is een ernstiger incident), maar het oplossen van de een raakt niet aan de ander, en de centrale klacht van de paper is dat de focus op injection in de beveiligingsdiscussie het structurele probleem onbenoemd liet. Versus RBAC/ABAC/ReBAC: de klassieke modellen zijn beleidstalen op verzoektijd — krachtige, noodzakelijke invoer die op zichzelf geen invarianten op workflow-niveau bewijst, omdat een rolcontrole niet kan zien dat autoriteit zich over meerdere stappen heeft opgebouwd, een regel per bron niet kan zien wat de synthese heeft samengesteld, en een beleid dat op verzoektijd wordt geëvalueerd niet kan zien dat de workflow waartoe het behoort is gestart onder toekenningen die inmiddels zijn ingetrokken. De modellen zijn invoer voor een oplossing, niet de oplossing zelf: de invarianten bevinden zich op een laag die die modellen niet evalueren. Versus authenticatie: weten wie elke principal is — de OAuth-flows, de token-uitwisseling, de workload identity — is de voorwaarde waarop dit probleem voortbouwt; propagatie is wat moet standhouden nadat iedereen correct is geïdentificeerd, wat verklaart waarom "we hebben SSO voor onze agents" een andere vraag beantwoordt dan de vraag die deze term stelt. De samenvatting van alle drie de contrasten in één regel: de sector heeft twee jaar besteed aan het beveilligen van het verzoek en de prompt; authorization propagation betreft de beveiliging van de keten.

Authorization Propagation in de Enterprise: Identity Governance als infrastructuur

Hier komt TrueFoundry in beeld, en de ondertitel van de paper geeft de vorm van het argument al aan: de invarianten kunnen niet worden behouden door elk agent-team te vragen ze te implementeren — ze moeten eigenschappen zijn van de laag die elke agent-aanroep toch al passeert. Bekijk de drie subproblemen in het licht van gedocumenteerde mechanismen. Transitieve delegatie wordt beheerd waar de delegatie plaatsvindt: het bereik van agent-tools verloopt via de MCP Gateway, waar delegatie per gebruiker betekent dat een downstream-aanroep de autoriteit van de oorspronkelijke principal meeneemt naar elk systeem — de CRM ziet de permissies van de gebruiker, niet de algemene van de agent — en scoping op basis van taken betekent dat wat een aangemaakte agent ontvangt een ingeperkt recht is dat is afgeleid van de ouder, nooit een opgebouwde superverzameling; de invariant "autoriteit mag versmallen, nooit verbreden" wordt een structurele eigenschap van hoe credentials worden uitgegeven, in plaats van een gewoonte die teams moeten onthouden, de discipline die onze TBAC-analyse en het werk aan OAuth op de MCP-laag diepgaand uitwerken. Temporele validiteit wordt een eigenschap van het token in plaats van een belofte van de workflow: kortstondige, automatisch vernieuwde, centraal intrekbare credentials betekenen dat een toekenning die bij stap twaalf wordt ingetrokken, de tool-aanroep bij stap dertien laat mislukken — de controle wordt bij elke stap opnieuw uitgevoerd omdat elke stap de laag passeert, wat de enige plek is waar "nog steeds geldig nu" continu kan worden beantwoord voor een workflow die langer duurt dan zijn beginomstandigheden. Aggregatie-inferentie is het eerlijke, moeilijke geval — geen enkele gateway berekent de gevoeligheid van een synthese in het algemeen — en de bijdrage van de infrastructuur is om het beheersbaar te maken: request traces op ketenniveau leggen gemedieerde ophaalacties en aanroepen vast met hun opgeloste identiteiten — bewijs voor audit-beoordeling van deelnemende operaties, niet een automatisch autorisatie-oordeel over wat de workflow heeft samengesteld; guardrails op tool-outputs en model-responsen dwingen de uitdrukbare grenzen af (PII-klassen, beperkte bronnen die oversteken naar onbeperkte outputs); en de coördinatielaag voor multi-agents die ons werk rond A2A governance behandelt, houdt de stappen tussen agents op dezelfde gecontroleerde laag als de tool-stappen, zodat de keten geen onzichtbare segmenten heeft. De paper vraagt om architecturen met structurele vereisten; deze laag is waar die vereisten niet langer maatwerk per team zijn, maar configuratie worden.

Enterprise Authorization-Propagation Checklist

Zes vragen voor elke multi-agent omgeving: Passeert elke agent-naar-tool- en agent-naar-agent-stap een beheerde laag, of zijn er directe integraties waar de keten onzichtbaar wordt? Is delegatie geïmplementeerd als credential-afleiding — onderliggende bereiken vallen strikt binnen de bovenliggende bereiken — in plaats van het delen van credentials? Zien downstream-systemen de autoriteit van de oorspronkelijke principal (delegatie per gebruiker) in plaats van de algemene autoriteit van een serviceaccount? Zijn credentials kortstondig en centraal intrekbaar, zodat temporele validiteit bij elke stap opnieuw wordt vastgesteld in plaats van aangenomen vanaf stap één? Kan een auditor de volledige ophaal- en synthesevoetafdruk van een workflow reconstrueren op basis van sporen? En is er iemand verantwoordelijk voor het aggregatievraagstuk — het beoordelen van wat workflows met hoge privileges samenstellen, en niet alleen waar ze toegang toe hebben? Zes keer 'ja' betekent identity governance als infrastructuur; de 'nee's zijn de plekken waar de compliance van de keten berust op toeval.

De toekomst van Authorization Propagation: Waar we op gaan letten

Voorzichtige voorspellingen. Verwacht dat de term snel de weg van onderzoek naar praktijk zal afleggen, omdat hij — net als governance decay, de andere term van dit seizoen — fouten benoemt waar operators nu al mee te maken hebben: de sub-agent met te veel permissies die bij een audit wordt aangetroffen, de synthese waar de juridische afdeling van schrok, de workflow die bleef draaien op een ingetrokken toekenning; jargon dat bestaande incidenten verklaart, wordt overgenomen in evaluaties na incidenten. Verwacht dat standaardisatieinstanties het zullen verwerken: de MCP- en A2A-ecosystemen komen al samen rond delegatiesemantiek, en "hoe behoudt uw protocol autorisatie-invarianten over meerdere stappen" is precies de vraag die de paper beoordelaars helpt te stellen — we durven te wedden dat propagatietaal binnen een jaar verschijnt in beveiligingsbeoordelingen van agent-protocollen. Verwacht dat aggregatie-inferentie de hardnekkige grens blijft: delegatie en temporele validiteit hebben duidelijke structurele antwoorden; wat-onthulde-de-synthese is een semantisch probleem dat leveranciers van dataclassificatie, DLP en output-guardrails in de agent-discussie zal trekken, met sporen op ketenniveau als de onderlaag die ze allemaal nodig zullen hebben. Verwacht dat de golf van niet-menselijke identiteiten in de IAM-sector productief zal botsen met deze benadering — NHI-governance geeft de principals namen; propagatie is wat de benoemde principals moeten behouden — en verwacht dat inkoop dit alles zal samenvatten in één vraag waar deze pagina een antwoord op biedt: niet "hebben uw agents identiteiten", maar "behouden uw ketens hun invarianten". We zullen deze gids bijwerken naarmate het onderzoek en het vakjargon zich verder ontwikkelen; de duurzame claim is de herkadering die de paper heeft opgeleverd: de afgelopen twee jaar gingen over het beveiligden van het verzoek en de prompt — de komende twee gaan over het beveiligden van de keten.

Veelgestelde vragen over Authorization Propagation

Wat is authorization propagation in AI-systemen?

Authorization propagation is het probleem van het behouden van autorisatie-invarianten wanneer meerdere AI-agents gegevens ophalen, taken delegeren en resultaten synthetiseren over systeemgrenzen heen — om ervoor te zorgen dat de autoriteit waarmee een workflow is gestart, bij elke stap getrouw behouden blijft. De term werd voorgesteld in een preprint van één auteur uit mei 2026 (arXiv:2605.05440), die het onderverdeelt in transitieve delegatie, aggregatie-inferentie en temporele validiteit.

Hoe verschilt authorization propagation van prompt injection?

Prompt injection is een aanval waarbij een kwaadwillende een agent manipuleert om autoriteit te misbruiken die hij rechtmatig bezit. Fouten in authorization propagation hebben geen aanvaller nodig: gewone delegatieketens breiden autoriteit uit, afzonderlijk toegestane ophaalacties worden gesynthetiseerd tot niet-toegestane onthullingen, en lange workflows duren langer dan hun toekenningen. Een tegen injection beveiligde omgeving kan nog steeds data lekken via de eigen permissiestructuur.

Waarom lossen RBAC of ABAC authorization propagation niet op?

Omdat het modellen op verzoektijd zijn: een rol- of attribuutcontrole evalueert één principal, één bron, één moment. De propagatiefouten bevinden zich op workflow-niveau — autoriteit die zich opbouwt over meerdere stappen, syntheses die een individuele toekenning overschrijden, validiteit die halverwege de keten verloopt — wat controles op verzoekniveau structureel niet kunnen zien. De klassieke modellen blijven noodzakelijke invoer; de invarianten moeten worden afgedwongen op de laag die de hele keten passeert.

Hoe behouden bedrijven autorisatie-invarianten in delegatieketens van agents?

Door de invarianten tot eigenschappen van de infrastructuur te maken: routeer elke agent-naar-tool- en agent-naar-agent-stap via een beheerde gateway; implementeer delegatie als afgebakende credential-afleiding (voor geregistreerde agent-naar-agent-aanroepen die via de Agent Gateway worden gerouteerd, kan afgebakende token-uitwisseling helpen om subject, actor, audience en geautoriseerd bereik te behouden — terwijl Harness-subagents momenteel de tools en sandbox van de hoofd-run delen in plaats van onafhankelijk ingeperkte permissies te ontvangen); gebruik geconfigureerde delegatie per gebruiker waar ondersteund, zodat downstream-systemen de autoriteit van de oorspronkelijke principal kunnen zien; zorg dat credentials kortstondig en centraal intrekbaar zijn, zodat temporele validiteit bij gemedieerde stappen opnieuw kan worden vastgesteld, afhankelijk van de levensduur van het token en downstream-validatiesemantiek; en leg sporen van gemedieerde operaties vast zodat de ophaal- en synthesevoetafdruk van een workflow beoordeeld kan worden voor het deelnemende vlak.

Referenties

• Anker — Tallam, "Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure" (Kamiwaza AI, arXiv:2605.05440, mei 2026: de term; de argumenten over niet-herleidbaar-tot-injection en verder-dan-RBAC/ABAC/ReBAC; de drie subproblemen; de zeven structurele vereisten).
• TrueFoundry documentatie — MCP Gateway (delegatie per gebruiker; officieel architectuurdiagram); MCP-authenticatie & beveiliging; request traces en analytics (officiële afbeelding); guardrails.
• Dit blog — TBAC: task-based access control; OAuth en tokenbeheer op de MCP-laag; multi-agent A2A governance; de agent identity census; MCP gateway vs proxy vs router.

Er is één direct citaat van minder dan vijftien woorden gebruikt uit de geciteerde paper, in de tekst toegeschreven; de argumenten, subproblemen en vereisten uit de paper zijn anderszins geparafraseerd, en lezers dienen het origineel te raadplegen voor de formele behandeling. De koppeling van de vereisten uit de paper aan TrueFoundry-mechanismen is onze redactionele invulling; de auteur van de paper en Kamiwaza AI noemen noch ondersteunen TrueFoundry. Productmogelijkheden zijn geparafraseerd uit openbare documentatie die beschikbaar was op het moment van schrijven; de productafbeeldingen zijn eigen documentatiemiddelen van TrueFoundry, overgenomen met bronvermelding. Dit is een dynamische referentie en zal worden herzien naarmate het onderzoek en het vakjargon zich verder ontwikkelen.

‍