Whitepaper: Authority Decomposition voor AI-agenten
Van bevoegdheidsketen naar attested execution: hoe u aantoonbaar maakt welke trust-domain coalitie een AI-agent een beschermde actie werkelijk kan laten uitvoeren.
Whitepaper: 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 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.
Dit whitepaper vertaalt het raamwerk uit het preprint Authority Decomposition for Software Systems (Wu, Wang en Zhang, Chengdu Havenlon Security Technology) naar een toetsbare methode voor Nederlandse publieke organisaties. Het antwoordt op de vraag die een rolmatrix niet beantwoordt: welke minimale coalitie van trust domains kan een specifieke beschermde overgang werkelijk veroorzaken?
1. Toestemming is geen causale macht
RBAC, privileged access management en approval-workflows modelleren wie een verzoek mag doen en onder welke voorwaarden een systeem het behoort te accepteren. Dat blijft essentieel. NIST SP 800-207 benadrukt dat authenticatie en autorisatie van subject én device afzonderlijke functies zijn vóór toegang tot een resource ontstaat.
Maar zelfs een correcte autorisatiebeslissing beantwoordt vier vragen niet:
- Welke componenten moeten gezamenlijk functioneren om de gewenste toestandsovergang te produceren?
- Welke beheer-, update- of recoveryroute kan dezelfde overgang buiten de gewone workflow realiseren?
- Welke partij kan achteraf een verslag van de uitvoering maken, wijzigen of selectief weglaten?
- Welke ogenschijnlijk gescheiden domeinen vallen onder dezelfde technische of organisatorische control?
Het paper onderscheidt vijf analytische stadia die in systeembeschrijvingen vaak worden samengeperst:
- Een verzoek wordt voorgesteld.
- Het verzoek wordt geautoriseerd of goedgekeurd.
- Een uitvoerbaar commando wordt richting een uitvoeringsgrens gestuurd.
- Het commando produceert een uitvoeringspoging aan die grens.
- De aangewezen beschermde toestandsovergang treedt op, of niet.
Deze stadia kunnen verschillende actoren betreffen of in één proces samenvallen. Elke allocatie is relevant omdat zij het effect van een compromittering verandert. Een goedgekeurde operatie kan zonder tegenspraak worden geweigerd: weigering voorkomt de overgang via het bemiddelde pad, maar bewijst geen niet-optreden elders in de run.
2. De authority-taxonomie: negen machten
Het paper onderscheidt negen authority-types. Een type classificeert een macht, niet een actor, rol of component. Dezelfde macht kan over domeinen verdeeld zijn; één domein kan meerdere machten houden.
| Authority-type | Object van controle | Analytische betekenis |
|---|---|---|
| Proposal | Creatie of indiening van een verzoek | Introduceert een operatie ter overweging |
| Authorization | Normatieve toestemming onder een regel | Bepaalt permit/deny/conditional-status |
| Approval | Bevestiging van een concreet verzoek | Levert instemming of bevestiging |
| Command | Productie van een uitvoerbare instructie | Stuurt een operatie richting een uitvoeringsgrens |
| Policy decision | Toepasselijke regels en contextuele input | Produceert een beslissing die autorisatie kan instantiëren |
| Policy update | Wijziging van regels | Verandert welke latere beslissingen bereikbaar zijn |
| Veto | Weigering van een poging of blokkering van een pad | Voorkomt de overgang via dat bemiddelde pad |
| Execution | Uitkomst-relative causale toereikendheid | Bepaalt of een domein/coalitie de overgang kan veroorzaken |
| Evidence | Productie, attestatie, bewaring, onderdrukking of officiële aanwijzing van bewijs | Bepaalt welke operation accounts worden gecreëerd of als autoritatief behandeld |
De classificatie is functioneel, niet chronologisch. Een bypass kan de nominale proposal-, authorization- of approval-sequentie overslaan. Analyse dekt daarom elk toegelaten control-pad, niet alleen de verwachte trace.
Kerninzicht: authorized, approved 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.
3. Het formele model: beschermde overgangen en witnesses
Authority decomposition begint niet bij een actor, maar bij een actie. Definieer een beschermde overgang τ_a: s⁻ → s⁺: een waarneembare verandering van een begintoestand naar een eindtoestand. Voorbeelden: 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 update, recovery, override, disablement of alternate invocation. Per witness wordt vastgelegd welke trust domains noodzakelijke controle uitoefenen.
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 niet kleinste in aantal en evenmin exclusief, meerdere verschillende minimale coalities kunnen naast elkaar bestaan.
Trust domains: de eenheid van analyse
Een trust domain is een dreigingsmodel-relative grens waarbinnen compromittering, beheer, update-autoriteit, sleuteleigendom of organisatorische controle als gedeeld wordt behandeld. Het hoeft niet samen te vallen met een machine, proces, bedrijf of locatie.
- Afzonderlijke componenten vallen onder één domein bij gemeenschappelijke controle.
- Componenten in één apparaat blijven afzonderlijk alleen wanneer hun code, sleutels, lifecycle-roots en invocation-paden onafhankelijk worden beheerd.
- Een tweede component creëert geen causale scheiding als een domein zijn regel kan wijzigen, alle geaccepteerde inputs kan produceren, het kan uitschakelen of eromheen kan routeren.
Componentcount is irrelevant wanneer één domein de ogenschijnlijk gescheiden approvals, credentials, policies of executors controleert.
4. Gevaarlijke authority-patronen
Het model onthult configuraties die workflow-diagrammen verbergen. Het paper groepeert ze in vijf categorieën:
4.1 Causale concentratie
- Self-authorizing executor: de exacte set domeinen die een relevante autorisatie-macht uitoefent, is zelf voldoende voor uitvoering. De autorisatie-controller kan de overgang veroorzaken zonder een beslissing van buiten het domein.
- Approval-execution compression: het geselecteerde approval-certificaat bevat de witness-vereisten en er blijft geen externe finale restrictie over.
4.2 Boundary capture
- Upstream-satisfied boundary: een upstream-coalitie kan compleet ondersteunend bewijs leveren voor acceptatie of non-refusal van een nominale grens. De grens levert geen onafhankelijk gecontroleerde gunstige conditie.
- Mutable veto: een domein kan de grens of het veto herconfigureren in een richting die de realisatie vereenvoudigt of uitbreidt.
- Veto disablement: een domein kan de restrictie neutraliseren terwijl een haalbare realisatie blijft bestaan.
4.3 Alternatieve realisatie
- Bypassable final boundary: een haalbare realisatie vermijdt een grens die als finaal wordt voorgesteld.
- Reconfiguration-execution coupling: een geselecteerde reconfiguratie-macht verschijnt in een minimale voldoende uitvoeringscoalitie.
4.4 Administratieve collapse
- Owner/administrative override collapse: een toegelaten reconfiguratie-witness levert unilaterale uitvoeringsautoriteit. Recovery, override, key-, firmware- of alternate-invocation-controle maakt de beheerder alleen voldoende.
4.5 Epistemische concentratie
- Self-attesting executor: een uitvoeringscoalitie produceert of attesteert zijn eigen gemodelleerde operation account.
- Evidence-control collapse: de coalitie kan alle gemodelleerde tegenstrijdige accounts onderdrukken én exclusief zijn voorkeursaccount als officieel aanwijzen.
Belangrijk: deze patronen zijn afgeleide diagnostieken, geen primitieve authority-types, automatische kwetsbaarheidsbevindingen of beveiligingsmechanismen. Aanwezigheid stelt een capability vast, geen exploitatie. Concentratie kan ook een proportionele beschikbaarheidskeuze zijn, het raamwerk maakt haar zichtbaar in plaats van elke geconcentreerde architectuur defect te verklaren.
5. Onafhankelijkheidscondities I1-I4 en E1
Fysieke scheiding bewijst geen authority-onafhankelijkheid wanneer een upstream-domein policy, updates, recovery, credentials of geaccepteerde inputs controleert. Het paper test daarom of een aangewezen upstream-coalitie een geclaimde-finale restrictie kan wijzigen, bevredigen, uitschakelen of vermijden.
| Conditie | Vereist resultaat | Vraag |
|---|---|---|
| I1, Geen unilaterale wijziging | ¬ CanAlter | Kan U beveiligingsrelevante beslissingssemantiek wijzigen? |
| I2, Geen unilaterale bevrediging | ¬ CanSatisfy | Kan U alleen compleet ondersteunend bewijs leveren voor acceptatie? |
| I3, Geen unilaterale uitschakeling | ¬ CanDisable | Kan U de restrictie neutraliseren terwijl τ_a realiseerbaar blijft? |
| I4, Globale no-bypass | GlobalNoBypass | Traverseert elk lid van een niet-lege haalbare witness-set de grens? |
| E1, Geen unilaterale evidence-redefinitie | ¬ CanRedefineEvidence | Kan een toelaatbare uitvoeringscoalitie tegenstrijdige accounts onderdrukken en exclusief zijn voorkeursaccount aanwijzen? |
Kerninzicht: structurele traversal (I4) bewijst geen weerstand tegen upstream-wijziging (I1), bevrediging (I2) of uitschakeling (I3). Een grens kan door elke witness worden getraverseerd terwijl een domein de regel kan wijzigen, compleet ondersteunend bewijs voor acceptatie kan produceren of het veto kan neutraliseren zonder de grens te vermijden.
6. De Havenlon-casus: wat wel en niet bewezen is
Het paper past het model toe op Havenlon, een begrensde softwarearchitectuur. In het split-control, release-intended, open-state protocolmodel:
- De gewone route vereist vijf domeinen:
{D_L, D_U, D_S, D_A, D_X}, Linux protocol peer, execution-user handtekening, SaaS-handtekening, Arbiter en Security/secure-element. - Certificate replacement levert de unieke inclusion-minimale bekende vereistenset
{D_L, D_A, D_X}onder de source-enumerated protocol witnesses. - De Linux-domein blijft onvoldoende voor de complete overgang, geen enkele source-enumerated witness heeft
Req(w) ⊆ {D_L}.
Certificate replacement stelt I1- en I2-falen vast ten opzichte van D_L in dat begrensde model. De Arbiter's geclaimde-finale status is een gedocumenteerde ontwerpclaim; gedeployde globale non-bypassability en boundary-bound veto coverage blijven UNRESOLVED.
De les voor Nederlandse organisaties: de vijf- en driedomeinsets uit het paper mogen niet als referentiearchitectuur worden gekopieerd. Publieke organisaties hebben andere leveranciersketens, shared-serviceconstructies en mandaatmodellen. De methode is waardevol, de specifieke uitkomsten niet.
7. Vijf cross-domain casestudies
Het paper demonstreert de methode op vijf archetypen. Elke casus houdt zichtbare kenmerken constant en verandert één authority-relevante variabele:
| Casus | Beschermde actie | Gecontroleerde variabele | Discriminatief resultaat |
|---|---|---|---|
| AI-agent finance | Post een overdracht naar de ledger | Gedeelde vs. onafhankelijke boundary-administratie | Req verandert van één naar twee domeinen; self-authorization verdwijnt |
| Enterprise payment | Commit een betalingsrelease | Gedeelde vs. onafhankelijke credential recovery | Eén-domein support wordt pair-specific multi-domein coalitie |
| IoT control | Commit een device-commando | Update uitgesloten vs. toegelaten | Boundary coverage, bypass en disablement scheiden in verschillende resultaten |
| HSM signing | Produceer een handtekening | Client-geleverde vs. lokale acceptatie-input | I2 verandert terwijl de minimale coalitie vast blijft |
| CI/CD deployment | Commit een productie-deployment | Gescheiden vs. gecollapste evidence-controle | E1 verandert terwijl causale uitvoeringsautoriteit gelijk blijft |
Vijf terugkerende bevindingen:
- Component- en principal-count zijn onbetrouwbare proxies voor trust-domain-decompositie.
- Een low-level executor kan uitvoeringsautoriteit missen omdat hij niet de complete geselecteerde support controleert.
- Structurele traversal bewijst geen weerstand tegen upstream-wijziging, bevrediging of uitschakeling.
- Reconfiguratie kan een coalitie toevoegen, een alternatieve witness toevoegen of een restrictie neutraliseren zonder een vermijdende route toe te voegen.
- Self-attestation en evidence-control collapse blijven onderscheiden: het heralloceren van epistemische machten kan E1 veranderen terwijl elke causale witness gelijk blijft.
8. Toepassing in de Nederlandse publieke sector
8.1 Waar dit raakt
- EU AI Act, artikel 12 vereist voor high-risk AI-systemen technisch ondersteunde automatische eventlogging gedurende de levensduur. Die logs moeten passende traceerbaarheid ondersteunen. De tekst zegt echter niet dat een aanwezige log op zichzelf de causale volledigheid van alle uitvoeringsroutes bewijst.
- BIO2 vereist aantoonbare beheersing van externe koppelingen en functiescheiding. Authority decomposition maakt een aanvullende vraag toetsbaar: dekken die controls ook de feitelijke coalities achter een beschermde agentactie?
- NIS2/Cyberbeveiligingswet vereist supply chain security. Een agentruntime, SaaS-platform of credential store met gedeelde lifecycle-roots is een supply chain risico dat een rolmatrix niet zichtbaar maakt.
8.2 Vijf concrete gevolgen voor enterprise-agenten
- Begin 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.
- Trust domains moeten 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.
- Recovery verdient 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.
- Logs moeten 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.
- Het authority-model moet meeveranderen 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.
9. Een falsifieerbare enterprise-toets
De minimale proef vergelijkt drie teams of drie 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.
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 (causale meerwaarde) wordt verzwakt wanneer de attack-path workshop op een vooraf gekozen holdout-set dezelfde coalities, bypasses en common-control collapses vindt. H1 faalt wanneer de door decomposition voorspelde en door beide baselines gemiste routes in een sandbox de overgang niet kunnen realiseren. H3 (conditionele schijnzekerheid) wint gewicht als herhaalde red-teamtests nieuwe, niet-gemodelleerde witnesses vinden.
Meet 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.
10. 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 als minimaal voldoende binnen dit bron- en dreigingsmodel, niet als universele afwezigheid van andere coalities.
De methode is gevoelig voor modelleringskeuzes. Te grove domeinen verbergen functiescheiding; te fijne domeinen suggereren onafhankelijkheid die organisatorisch niet bestaat. Een bruikbaar model vereist expliciete criteria voor gemeenschappelijk beheer, sleuteleigendom, updatebevoegdheid en incidentherstel.
De bron is een arXiv-preprint. Het formele raamwerk en de casus zijn primaire onderzoekssignalen, geen gevestigde industriestandaard. De onzekerheidsklassen zijn 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.
11. 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 action-relative coalities met onafhankelijke bewijsvoering en twee baselines.
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.
Gerelateerde bronnen
- Wie kan de actie werkelijk laten plaatsvinden? Authority decomposition voor AI-agenten, de blogpost-versie van dit raamwerk
- De authority gap bij langlopende software-agents, scheiding tussen producent en acceptor van werk
- Primaire bron: Authority Decomposition for Software Systems, arXiv preprint
- Volledige PDF
Uw AI-agent-architectuur aantoonbaar beheersen? Plan een vrijblijvende kennismaking. Plan een kennismaking →