De trust-root-vraag: wie mag het onderdeel zijn dat je niet ter discussie kunt stellen?

Veldnotities agentplatform, een van acht. Elke notitie is een beslissing die een CTO of Head of AI moet nemen, met het bewijs dat ik gebruikte, waar ik uitkwam en wat ik nog niet kan bewijzen.

De vraag

Wanneer een AI-agent iets doet binnen je organisatie, welk onderdeel mag dan met gezag zeggen dat dat was toegestaan? Dat onderdeel is je trust root. Al het andere op het platform kan daaraan getoetst worden. De trust root zelf kan nergens aan getoetst worden.

De meeste teams kiezen er nooit een. Ze erven er een. Het orkestratieframework wordt het, omdat de policy hook daar zit. Of de modelprovider wordt het, omdat de function-calling API bepaalt wat als tool call telt. Of de cloud wordt het, omdat identiteit en logs in zijn IAM en zijn auditdienst leven. De beslissing wordt genomen door de leverancier die toevallig als eerste werd geïnstalleerd.

Mijn korte antwoord, na een jaar ontwerpen en bouwen aan een governed agentplatform voor de Nederlandse lokale overheid: geen enkele runtime, modelprovider, cloud of hardwareleverancier mag de trust root zijn. De trust root moet een onderdeel zijn dat je zelf bezit, dat klein genoeg is om te begrijpen, en waarmee elk ander onderdeel gedwongen wordt te praten via een gepubliceerd contract.

Juvenalis vroeg wie de bewakers bewaakt. Tweeduizend jaar later is het antwoord in de meeste AI-platforms: de leverancier die toevallig als eerste was geïnstalleerd.

Waarom ik daar uitkwam

Drie bevindingen duwden me die kant op.

De policy hook is niet het beleid. Elk groot agentframework dat ik beoordeelde, inmiddels meer dan honderd, biedt een plek om guardrails aan te haken: een callback vóór een tool call, een middleware op het modelverzoek, een graph node waar je doorheen kunt routeren. Nuttig. Maar een hook binnen de runtime wordt afgedwongen door de runtime. Heeft de runtime een bug, een omweg of gewoon een nieuwere versie met andere semantiek, dan gaat het beleid mee. Een regel die leeft binnen het ding dat hij bestuurt, is een afspraak, geen control. Dat heb ik vastgelegd als architectuurbeslissing: regels worden afgedwongen buiten de prompt en buiten de runtime, door een onderdeel dat geen agentcode uitvoert.

Modeloutput is een voorstel, geen instructie. Wanneer een model een function call teruggeeft, voert het framework die doorgaans uit. Daarmee wordt het model de autoriteit over wat er daarna gebeurt. Ik heb dat omgedraaid: een door het model geproduceerde tool call is een voorstel, en een deterministisch lokaal onderdeel beslist of het effect wordt geautoriseerd en uitgevoerd. Het model kan zich niet langs een beleid praten dat het nooit te beoordelen krijgt. Het klinkt als een kleine verandering. Het verandert alles aan waar de audittrail begint.

Providerlogs zijn niet jouw bewijs. Als je registratie van wat een agent deed in het dashboard van je modelprovider leeft, dan heb je geen registratie. Je hebt een kijkje in het systeem van iemand anders, onder diens bewaartermijn, in diens regio, onderhevig aan diens contractwijzigingen. Voor een gemeente die een besluit misschien moet verdedigen tegenover een inwoner of een rechter is dat niet acceptabel. Het gezaghebbende bewijs van een run moet geschreven worden door het onderdeel dat je zelf bezit, op het moment dat de beslissing werd genomen, en het moet tamper-evident zijn.

Leg die drie naast elkaar en de vorm van de trust root is duidelijk. Hij bezit identiteit: mens, workload, tenant, agent, tool, model en runtime. Hij bezit delegatie en beleid. Hij bezit de beslissing om een run toe te laten, een actie goed te keuren, data naar buiten te laten gaan. Hij bezit het bewijsrecord. Hij draait geen agents, host geen modellen en heeft geen specifieke cloud nodig.

De beslissing, concreet

Ik heb het platform gesplitst in een eigen governance-ruggengraat en al het andere.

De ruggengraat bestaat uit vier verantwoordelijkheidsvlakken: governed execution en beleid; identiteit, delegatie en registry; verificatie, evaluatie en bewijs; en soevereiniteit, deployment en compliance. Dat is de trust root. Hij is bewust klein.

Al het andere, de agentruntimes, de modellen, de workflow-engines, de protocolimplementaties, de vector stores, zit buiten de ruggengraat en wordt bestuurd via geversioneerde contracten en adapters. Die worden ingekocht, niet bezeten, op één voorwaarde: hun gedrag moet beperkt, geobserveerd, getest en vervangen kunnen worden.

De test die ik toepas op elk onderdeel dat bij de ruggengraat wil horen, is de exit-test. Als ik het verwijder, verlies ik dan agentdefinities, beleid, bewijs, audithistorie of runrecords? Zo ja, dan zat het al die tijd in de ruggengraat en moet het aan de ruggengraatregels voldoen. Zo nee, dan is het een ingekocht onderdeel en mag het worden verwisseld.

Het zwaarste gevolg was voor onze eigen referentieruntime. Het is verleidelijk om je eigen runtime een privépad te geven: een signing key, een verborgen bewijskanaal, een beleidssluiproute, omdat je hem vertrouwt. Dat heb ik niet gedaan. De referentieruntime gebruikt exact dezelfde gepubliceerde interfaces als een runtime van een derde partij zou doen. Geen privé-bypass-API, geen bevoorrechte signing-autoriteit, geen permanente credential. Als ik mijn eigen runtime niet kan vervangen zonder governance te verliezen, heb ik geen governor gebouwd; dan heb ik nog een framework gebouwd.

Twee assuranceklassen, eerlijk gehouden

De trust-root-beslissing heeft een neef die nog vaker wordt genegeerd: waar draait de inferentie, en verandert het antwoord je claims?

Ik heb modelassurance gescheiden van deployment-topologie en er twee expliciete klassen van gemaakt. In de eerste blijven inferentie, data, sleutels, bewijs, telemetrie, identiteit en beheer allemaal binnen de controle van de gemeente; er is geen remote modelprovider nodig. In de tweede blijft de governor lokaal, maar gaat door het beleid goedgekeurde, geminimaliseerde data naar één expliciet gekwalificeerde remote modelroute, met provider, juridische entiteit, regio, bewaartermijn, subverwerkers en vervaldatum allemaal vastgepind.

De regel die ertoe doet: de tweede klasse erft of impliceert nooit de eerste. Een frontier-connected route wordt nooit gepresenteerd, afgeleid of vermarkt als soeverein. Automatische failover van een soevereine route naar een remote route is verboden. Als de soevereine route niet beschikbaar is, degradeert de run veilig, wacht op een mens, onthoudt zich of wordt geweigerd. Hij belt niet stilletjes naar buiten.

Die regel kost beschikbaarheid. Dat is de juiste prijs. Het alternatief is een soevereiniteitsclaim die waar is tot de eerste storing.

Wat ik nog niet kan bewijzen

Ik beoordeel mijn eigen werk zoals ik elke claim op deze site beoordeel: dit is een prototype, geen uitgerold systeem. Er is geen gemeente die het draait, geen gemeten override-percentage, geen incident dat de bewijsketen onder druk heeft getest. De architectuur telt meer dan veertig vastgelegde beslissingen en een dreigingsmodel dat de eigen agents van het platform als tegenstanders behandelt, en ik heb het gebouwd met een pipeline van AI-codeeragents die zelf onder dezelfde ruggengraat vallen. Maar vooral de exit-test is beoefend in ontwerp en in demo’s, niet in een migratie onder druk.

De eerlijke beperking van een trust root die je zelf bezit, is ook duidelijk: je bezit hem nu. Zijn beveiliging, zijn beschikbaarheid en zijn correctheid zijn van jou. Een kleine ruggengraat is makkelijker goed te krijgen dan een grote, en daarom heb ik hem klein gehouden, maar klein is niet hetzelfde als af.

Wat je hiermee doet

Als je een agentplatform draait of op het punt staat er een te kopen, stel dan in de volgende architectuurreview één vraag: welk onderdeel is onze trust root, en hebben wij dat gekozen?

Pas daarna de exit-test toe op elk onderdeel in het diagram. Alles waarvan het verwijderen beleid, identiteit of bewijs kost, zit in je ruggengraat. Tel hoeveel daarvan je zelf bezit. Als het antwoord nul is, heb je geen AI-governanceprobleem. Dan heb je een leverancier die dat heeft, namens jou, zonder jouw handtekening.

De volgende veldnotitie gaat in detail over de twee assuranceklassen: wat er nodig is om een frontier-modelroute te kwalificeren zodat “connected” een eerlijk woord blijft.

Have you tried turning it off and on again? Met een trust root die je hebt geërfd in plaats van gekozen, is de lastigere vraag waar de schakelaar zit.

Verwijzingen

De knipogen en citaten in dit stuk, met hun herkomst:

• Juvenal, Satires VI (c. 100 AD): “quis custodiet ipsos custodes”, who guards the guards.
• The IT Crowd (Channel 4, 2006-2013): “Have you tried turning it off and on again?”, Roy’s standard first response.