Wie kan de actie werkelijk laten gebeuren? Authority decomposition voor AI-agenten

Wie mag een AI-agent een betaling laten uitvoeren, een besluit laten verzenden of een productiemodel laten vervangen? De gebruikelijke antwoorden zijn rollen, mandaten en goedkeuringsstappen. Die antwoorden zijn nodig, maar ze beschrijven vooral de normatieve werkelijkheid: wie de actie hoort te mogen initiëren. Ze bewijzen niet welke combinatie van systemen, beheerders en sleutels de onderliggende toestand feitelijk kan veranderen.

Dat is de belangrijkste les die ik haal uit het nog niet peer-reviewed paper Authority Decomposition for Software Systems, waarvan ook de volledige PDF beschikbaar is. Het paper verschuift de analyse van identiteit en toestemming naar causaliteit. Niet de vraag “wie is geautoriseerd?”, maar: welke minimale coalitie van trust domains kan deze specifieke overgang werkelijk veroorzaken?

Die verschuiving is relevant voor agentic systems. Een agent handelt niet in een vacuüm. Een concrete actie loopt door een modelruntime, orkestrator, policy engine, credential store, API, SaaS-platform en vaak een menselijk goedkeuringskanaal. Elk onderdeel kan een gewone route ondersteunen, maar update-, herstel- en vervangingspaden kunnen de feitelijke machtsverdeling ingrijpend veranderen. Daardoor kan een architectuur op papier functiescheiding tonen terwijl enkele technisch samenhangende domeinen de beschermde actie toch kunnen afdwingen.

Mijn conclusie is begrensd. De centrale these is dat authority decomposition een ontbrekende causale laag toevoegt aan IAM, logging en menselijke besluitvorming. De methode is pas waardevol als zij wordt getoetst tegen zowel een RBAC- en lifecycle-baseline als een goede attack-path workshop, en als de gevonden routes in een geïsoleerde omgeving reproduceerbaar zijn.

Toestemming is geen causale macht

RBAC, privileged access management en approval-workflows modelleren voornamelijk wie een verzoek mag doen en onder welke voorwaarden een systeem het verzoek behoort te accepteren. Dat blijft essentieel. NIST SP 800-207 benadrukt bijvoorbeeld dat authenticatie en autorisatie van subject én device afzonderlijke functies zijn voordat toegang tot een resource ontstaat. Zero trust voorkomt daarmee impliciet vertrouwen op basis van netwerkpositie of eigendom.

Maar zelfs een correcte autorisatiebeslissing beantwoordt meerdere andere vragen niet:

1. Welke componenten moeten gezamenlijk functioneren om de gewenste toestandsovergang te produceren?
2. Welke beheer-, update- of recoveryroute kan dezelfde overgang buiten de gewone workflow realiseren?
3. Welke partij kan achteraf een verslag van de uitvoering maken, wijzigen of selectief weglaten?
4. Welke ogenschijnlijk gescheiden domeinen vallen onder dezelfde technische of organisatorische control?

Neem een agent die een subsidiebesluit opstelt en na menselijke goedkeuring naar een zaaksysteem stuurt. De formele beslisser kan correct zijn vastgelegd. Toch kan een beheerder van de agentruntime de uitvoeringscode wijzigen, kan een SaaS-beheerder een signing-policy vervangen en kan een recoveryproces credentials herstellen of rouleren. Als deze routes niet in hetzelfde model staan, wordt de approval-chain ten onrechte gelezen als een volledige beschrijving van de uitvoeringsmacht.

Het onderscheid is dus niet semantisch. Geautoriseerd, goedgekeurd en technisch in staat zijn verschillende predicaten. Ze kunnen samenvallen, maar dat moet blijken uit de architectuur en de test, niet uit de naam van een rol.

Modelleer eerst de beschermde overgang

Authority decomposition begint niet bij een actor, maar bij een actie. Definieer een beschermde overgang tau_a: s- -> s+: een waarneembare verandering van een begintoestand naar een eindtoestand. Voorbeelden zijn het publiceren van een besluit, het vervangen van een model, het ontsleutelen van een dossier of het starten van een betaling.

Daarna worden witnesses gezocht: concrete uitvoeringsroutes die aantonen dat de overgang kan plaatsvinden. Een ordinary witness volgt de bedoelde productieroute. Exceptional witnesses gebruiken bijvoorbeeld update, recovery, override, disablement of alternate invocation. Per witness wordt vastgelegd welke trust domains noodzakelijke controle uitoefenen. Deze werkwijze volgt het formele model uit het primaire paper.

De analyse zoekt vervolgens inclusion-minimal sufficient coalitions. Een coalitie is voldoende als zij de overgang kan veroorzaken. Zij is inclusion-minimaal als het weglaten van ieder domein de aangetoonde route breekt. “Minimaal” betekent hier dus niet kleinste in aantal en evenmin exclusief. Meerdere verschillende minimale coalities kunnen naast elkaar bestaan.

Dat action-relative karakter volgt direct uit de definitie. Een platformteam kan veel macht hebben over deployment, maar geen directe macht over een hardwarekey. Een securityteam kan een sleutel intrekken, maar geen inhoudelijk besluit produceren. Authority bestaat daarom niet als één algemene eigenschap van een rol of organisatieonderdeel. Zij moet per beschermde overgang worden afgeleid.

Wat de Havenlon-casus wel en niet bewijst

Het paper past het model toe op Havenlon, een begrensde softwarearchitectuur. De casus maakt minstens 2 routetypen zichtbaar: ordinary execution en certificate replacement. De gewone route omvat volgens de bronafleiding 5 domeinen: D_L als Linux protocol peer, D_U als controller van de handtekening van de execution user, D_S als controller van de SaaS-handtekening, D_A als Arbiter en D_X als Security of secure-element domein.

Binnen dit model is de verzameling {D_L, D_U, D_S, D_A, D_X} een bekende minimale voldoende coalitie voor de gewone route. De 2 afzonderlijke één-domeinsets D_L en D_X zijn onvoldoende. Wanneer certificate replacement als alternatieve route wordt meegenomen, verschijnt een bekende 3-domeinwitness: {D_L, D_A, D_X}. Ook daar blijft D_L op zichzelf onvoldoende. De precieze afleiding staat in het primaire paper.

Dit resultaat ondersteunt de hypothese dat lifecycle- en vervangingspaden de materiële machtsverdeling kunnen veranderen. Een RBAC-matrix die alleen de gewone gebruikersroute beschrijft, laat die verandering niet vanzelf zien. De casus toont echter niet dat drie domeinen universeel voldoende zijn voor agentic systems, noch dat alle uitzonderlijke routes zijn gevonden. De uitkomst geldt voor de beschreven actie, trust-domainindeling en witness-verzameling.

Dat verschil tussen een begrensde bevinding en een universele claim is belangrijk. Het paper levert een analysetaal en een uitgewerkte casus. Het levert nog geen empirisch bewijs dat de methode in iedere enterprise-architectuur systematisch meer kritieke routes vindt dan een volwassen threat model. Dat moet een implementatie zelf aantonen.

Causale authority en bewijs-authority zijn verschillende lagen

Een tweede nuttige scheiding is die tussen causal execution authority en evidentiary authority. De eerste gaat over het veroorzaken van de overgang. De tweede gaat over het produceren en beheersen van het bewijs waarmee anderen die uitvoering reconstrueren.

Een logregel kan overtuigend tonen dat een component een request heeft ontvangen. Zij bewijst niet automatisch dat dit de enige route was, dat de gelogde actor de toestand werkelijk veranderde of dat het logproducerende domein onafhankelijk is van de uitvoerende coalitie. Andersom kan een domein causale invloed hebben zonder zelfstandig alle auditsporen te controleren.

De EU AI Act, artikel 12 vereist voor high-risk AI-systemen technisch ondersteunde automatische eventlogging gedurende de levensduur van het systeem. Die logs moeten passende traceerbaarheid ondersteunen, onder meer voor risico-identificatie en post-market monitoring. Dat is een sterke eis aan observeerbaarheid. De tekst zegt echter niet dat een aanwezige log op zichzelf de causale volledigheid van alle uitvoeringsroutes bewijst.

Logging blijft noodzakelijk en heeft onafhankelijke bewijsarchitectuur nodig. NIST SP 800-53 Rev. 5 behandelt access control en audit/accountability als afzonderlijke control families. Die scheiding sluit aan bij het causale probleem: toegangsbeslissingen, uitvoering en bewijs moeten gekoppeld worden, terwijl hun trust assumptions expliciet blijven.

Voor een AI-agent betekent dit minimaal dat het besluitobject, de policybeslissing, gebruikte credentials, toolcall, uitvoeringsrespons en geobserveerde state transition correleerbaar zijn. Waar mogelijk worden deze sporen door verschillende domeinen bevestigd. Een cryptografisch gebonden eventketen kan mutatie zichtbaarder maken, maar lost een onvolledige witness-inventaris niet op. Onweerlegbare registratie van één bekende route is nog geen bewijs dat er geen tweede route bestaat.

Vier concurrerende verklaringen

Een publication-ready architectuurclaim moet kunnen verliezen. Daarom zijn voor toepassing binnen DjimIT 4 verklaringen relevant.

H1: causale meerwaarde. Authority decomposition vindt minimale coalities, bypasses of common-control collapses die een RBAC- en lifecycle-review én een goede attack-path workshop missen. Authority decomposition toont op nieuwe systemen minstens één reproduceerbaar onderscheid met zowel de RBAC-baseline als de attack-path workshop.

H2: inventarisatie-effect. De winst ontstaat doordat het team eindelijk update-, recovery- en overridepaden volledig inventariseert, ongeacht de coalitie-analyse. Een goede attack-path workshop zonder formele decompositie zou dan dezelfde bevindingen opleveren.

H3: conditionele schijnzekerheid. Het model is correct voor de bekende witnesses, maar onvolledige discovery maakt de uitkomst misleidend. De methode lijkt preciezer dan het onderliggende dreigingsmodel rechtvaardigt. Deze verklaring wordt sterker wanneer nieuwe red-teamroutes de berekende coalities regelmatig doorbreken.

H0: geen operationele meerwaarde. Een bestaande combinatie van IAM-review, threat modeling en deploymentanalyse vindt dezelfde routes tegen lagere kosten. In dat geval moet de extra analysetaal niet als nieuw product worden opgetuigd.

H1 is inhoudelijk aantrekkelijk, maar nog niet bewezen voor Nederlandse overheidsarchitecturen. H2 en H0 zijn serieuze alternatieven. De juiste reactie is geen marketingclaim, maar een paired comparison op een holdout-set.

Een falsifieerbare enterprise-toets

De minimale proef vergelijkt 3 teams of 3 onafhankelijk uitgevoerde analyses op dezelfde nieuwe systemen. Analyse A gebruikt RBAC, PAM, deployment- en lifecycle-documentatie. Analyse B voert met dezelfde bronnen een gestructureerde attack-path workshop uit en inventariseert gewone en uitzonderlijke routes, maar berekent geen minimale coalities. Analyse C gebruikt dezelfde informatie plus action-relative witnesses en coalition-minimalisatie. Alle analyses leveren vooraf voorspelde uitvoeringsroutes op. Een geïsoleerde testomgeving bepaalt vervolgens welke routes de beschermde overgang werkelijk kunnen veroorzaken.

De kern kan eenvoudig blijven:

for action in protected_transitions:
    baseline = review_rbac_and_lifecycle(action)
    workshop = map_attack_paths_without_coalition_minimization(action)
    witnesses = enumerate_ordinary_and_exceptional_paths(action)
    coalitions = inclusion_minimal_domains(witnesses)
    novel = coalitions - baseline.predictions - workshop.predictions
    reproduce(novel, isolated_environment=True)
    record(action, baseline, workshop, coalitions, reproduced_routes)

H1 wordt verzwakt wanneer de attack-path workshop op een vooraf gekozen holdout-set dezelfde coalities, bypasses en common-control collapses vindt. H1 faalt eveneens wanneer de door decomposition voorspelde en door beide baselines gemiste routes in een sandbox de overgang niet kunnen realiseren. H3 wint juist aan gewicht als herhaalde red-teamtests nieuwe, niet-gemodelleerde witnesses vinden.

Als authority decomposition een reproduceerbare coalitie toont die zowel de RBAC-baseline als de attack-path workshop missen, ondersteunt dat H1 boven H2. Vindt de workshop dezelfde route zonder coalitie-minimalisatie, dan past de uitkomst beter bij H2.

De hypothese wordt verworpen wanneer authority decomposition op de holdout-set geen reproduceerbaar onderscheid met de attack-path workshop toont.

Meet daarom meer dan het aantal findings. Leg vooraf vast welk aandeel unieke routes reproduceerbaar is, hoeveel tijd en expertise elke analyse vergt en hoeveel false positives of gemiste paden ontstaan. Meet ook hoe stabiel de uitkomst blijft na model-, sleutel- of leveranciersupdates en in hoeverre één common-control domein meerdere ogenschijnlijk gescheiden rollen beheerst.

Zonder deze vergelijking blijft authority decomposition een plausibel raamwerk. Met een vooraf geregistreerde baseline en holdout kan het een bewezen aanvullende control worden, of eerlijk worden verworpen.

De counterfactual maakt de oorzaak zichtbaar

Een nuttige stresstest verwijdert conceptueel alle update-, recovery-, override- en alternate-invocation-paden. Als die paden aantoonbaar niet bestaan of voor de gemodelleerde domeinen onbereikbaar zijn, wordt de coalition-analyse beperkt tot de ordinary witnesses. Dat zou de analyse eenvoudiger maken en de hypothese ondersteunen dat lifecycle-routes de extra causale complexiteit veroorzaken.

De scheiding tussen causaliteit en bewijs verdwijnt daarmee niet. Ook in een architectuur met één gewone route kan het uitvoerende domein invloed hebben op zijn eigen verslag, of kan een observatiedomein slechts een deel van de overgang zien. De oorspronkelijke tekst trok hier een te sterke conclusie: eenvoudiger causale analyse maakt onafhankelijke bewijsvoering niet overbodig.

Deze counterfactual levert een praktische ontwerpregel op. Iedere extra beheer- of herstelroute moet niet alleen functioneel worden getest, maar ook worden toegevoegd aan het authority-model van de acties die zij kan beïnvloeden. De security review van een nieuwe deploymentfunctie is dus onvolledig wanneer alleen de eigen permissies van die functie worden beoordeeld.

Consequenties voor secure-by-design agentarchitectuur

Voor enterprise-agenten zie ik vijf concrete gevolgen.

Ten eerste moet de architectuur beginnen met een klein register van beschermde transitions, niet met een generieke lijst “AI-risico’s”. Een toolcall naar een zoeksysteem vraagt een ander authority-model dan het verzenden van een beschikking of het wijzigen van een beleidsregel.

Ten tweede moeten trust domains organisatorische én technische common control weerspiegelen. Twee services met aparte accounts zijn niet onafhankelijk wanneer hetzelfde deploymentteam, dezelfde cloud control plane of dezelfde root key beide kan wijzigen. Het National Institute of Standards and Technology beschrijft in het Secure Software Development Framework de bescherming van software en ontwikkelomgevingen; authority decomposition maakt zichtbaar voor welke productietransitions die ontwikkelmacht causaal relevant wordt.

Ten derde verdient recovery dezelfde aandacht als de gewone workflow. Break-glass, certificate replacement, rollback, secret rotation en model-hot-swap zijn noodzakelijke bedrijfsfuncties. Juist omdat ze uitzonderlijk zijn, vallen ze gemakkelijk buiten een reguliere autorisatiereview. De Cybersecurity and Infrastructure Security Agency plaatst met Secure by Design de verantwoordelijkheid voor veilige ontwerpkeuzes bij producenten; voor agentplatforms hoort daar een expliciet model van beheerpaden bij.

Ten vierde moeten logs worden ontworpen als toetsbare evidence, niet als decoratie. Leg per beschermde transition vast welke onafhankelijke observatie de feitelijke eindtoestand bevestigt. Een succesvolle API-response is niet altijd gelijk aan een uitgevoerde actie. Bij asynchrone workflows, retries en compensating transactions is een toestandsspecifieke bevestiging nodig.

Ten vijfde hoort het authority-model mee te veranderen met de software bill of materials, credentials en deploymenttopologie. Een modelupgrade die geen businesslogica verandert, kan toch een nieuwe coalitie introduceren als de nieuwe runtime andere beheerpaden of toolrechten krijgt. De causale analyse is daarom een versioned architecture artifact, geen eenmalige compliancebijlage.

Dit bouwt voort op het eerdere DjimIT-onderzoek naar de authority gap bij langlopende software-agents. Daar ligt de nadruk op de scheiding tussen producent en acceptor van werk. Authority decomposition voegt de vraag toe welke domeinen de uiteindelijke state transition kunnen veroorzaken, inclusief routes buiten het bedoelde protocol.

Voor Nederlandse overheidsorganisaties kan dit dienen als verdiepende architectuurtoets naast toegangsbeveiliging en logging onder de Baseline Informatiebeveiliging Overheid. Het paper bewijst geen BIO2-compliance en vervangt geen formele controlbeoordeling. Het maakt een aanvullende vraag toetsbaar: dekken die controls ook de feitelijke coalities achter een beschermde agentactie?

Grenzen en onzekerheden

De voornaamste onzekerheid is witness-compleetheid. Geen workshop kan garanderen dat zero-days, verborgen leveranciersfuncties of ongedocumenteerde recoveryroutes volledig zijn gevonden. Lees de uitkomst daarom als minimaal voldoende binnen dit bron- en dreigingsmodel, niet als universele afwezigheid van andere coalities.

Een tweede onzekerheid is generaliseerbaarheid. Havenlon is één casus met een specifieke trust-domainindeling. Publieke organisaties hebben andere leveranciersketens, shared-serviceconstructies en mandaatmodellen. De vijf- en driedomeinsets uit het paper mogen niet als referentiearchitectuur worden gekopieerd.

Ten derde is de methode gevoelig voor modelleringskeuzes. Te grove domeinen verbergen functiescheiding; te fijne domeinen suggereren onafhankelijkheid die organisatorisch niet bestaat. Een bruikbaar model vereist daarom expliciete criteria voor gemeenschappelijk beheer, sleuteleigendom, updatebevoegdheid en incidentherstel.

Ten slotte is de bron een arXiv-preprint. Het formele raamwerk en de casus zijn primaire onderzoekssignalen, geen gevestigde industriestandaard. Het National Institute of Standards and Technology vraagt met het Artificial Intelligence Risk Management Framework om doorlopende, contextgebonden risicobeheersing. Dat ondersteunt de manier van toetsen, maar valideert niet automatisch de specifieke decompositiemethode.

De onzekerheidsklassen zijn daarom expliciet. De beschreven Havenlon-coalities zijn ESTABLISHED binnen het bronmodel, niet daarbuiten. Generaliseerbaarheid naar Nederlandse overheidsarchitecturen is PLAUSIBLE maar nog niet getoetst. Operationele meerwaarde boven een volwassen RBAC- en lifecycle-baseline blijft SPECULATIVE totdat een paired comparison op een vooraf gekozen holdout-set het verschil reproduceert.

Veelgestelde vragen

Vervangt authority decomposition bestaande IAM- en PAM-controles?

Nee. IAM en PAM blijven nodig om bedoelde toegang en bevoegdheden af te dwingen. Authority decomposition onderzoekt aanvullend welke technische coalities een specifieke toestandsovergang causaal kunnen realiseren, ook via update-, herstel- en overridepaden.

Bewijst een complete auditlog wie de actie heeft veroorzaakt?

Niet zonder aanvullende aannames. Een log bewijst wat het observerende domein heeft geregistreerd. De analyse moet ook aantonen dat het bewijs onafhankelijk genoeg is, de eindtoestand bevestigt en relevante alternatieve uitvoeringsroutes omvat. Artikel 12 van de EU AI Act vereist logging voor high-risk AI-systemen, maar maakt één logbron niet automatisch causaal volledig.

Wanneer levert de methode aantoonbare meerwaarde?

Wanneer zij op een vooraf gekozen holdout-set reproduceerbare coalities of bypassroutes vindt die zowel een RBAC- en lifecycle-baseline als een goede attack-path workshop missen. Vindt de workshop dezelfde routes tegen lagere kosten, dan moet DjimIT de extra methode niet als zelfstandige control positioneren.

Conclusie: van rolmatrix naar toetsbare uitvoeringsmacht

Authority decomposition toont in de Havenlon-casus dat de formele approval-chain niet vanzelf de volledige causale keten beschrijft. Het paper toont niet aan dat iedere enterprise-architectuur dezelfde coalities heeft of dat alle uitzonderlijke routes vindbaar zijn. Het sterkere model combineert daarom action-relative coalities met onafhankelijke bewijsvoering en twee baselines. Organisaties moeten die combinatie per beschermde transition toetsen. De observatie die dit oordeel zou wijzigen is een holdout waarop een attack-path workshop dezelfde reproduceerbare routes tegen lagere kosten vindt.

Voor een eerste toepassing is geen nieuw platform nodig. Kies één hoog-impact agentactie. Definieer de toestandsovergang, inventariseer ordinary en exceptional witnesses, groepeer werkelijk onafhankelijke trust domains en bereken de inclusion-minimale coalities. Vergelijk die uitkomst blind met de bestaande RBAC- en lifecycle-review. Test alleen de afwijkende routes in een geïsoleerde omgeving. Publiceer ook een nulresultaat wanneer de methode niets toevoegt.

Secure-by-design betekent op dit niveau dat organisaties de relatie tussen toestemming, uitvoering en bewijs aantoonbaar maken. Wie het protocol wil opnemen in de eigen architectuur- en controlcyclus kan via DjimIT AI-governance één beschermde agentactie afgebakend laten beoordelen.