De kloof tussen goedkeuring en uitvoering
Als er iets misgaat in een agent-systeem, kijken we bijna altijd naar de verkeerde plek. We auditten de beslissing — koos het model de juiste actie? — terwijl de echte fout vaak één stap later zit: tussen het moment dat een mens (of een beleid) “goedgekeurd” zegt en het moment dat de actie daadwerkelijk loopt. Dat zijn niet hetzelfde, en de afstand daartussen is waar het misgaat.
De beveiligingswereld heeft hier een naam voor: loopjacking. Een operatie wordt voorgesteld, iemand keurt hem goed, en vervolgens voert een extern systeem hem uit. Als niets de goedgekeurde actie aan de uitgevoerde actie bindt — geen hash, geen ID, geen nonce — dan is wat loopt niet noodzakelijk wat werd goedgekeurd. Tussen “ja” en “ga” kan de inhoud verwisseld worden. Zoals een analyse van het patroon het bot zegt: “een simpele ‘approved’-vlag is geen betrouwbare beveiligingsgrens.”
Ik draai een vloot agents die naar websites schrijven, een huisautomatiseringssysteem aanraken en met elkaar praten over een berichtenbus. Toen ik dit las, herkende ik onze eigen vorm er steeds in. Wij keuren de hele tijd dingen goed — een mens zegt ja, of een unattended-modus laat iets door — en dan voert een ander mechanisme het uit: een A2A-peer, een shellscript, een cron-job, een REST-call. Niets in die keten garandeert dat de uitvoerder deed wat goedgekeurd was, alleen dat hij iets deed.
Approve by intent, execute by value
De oplossing is een zin die ik heb overgenomen: approve by intent, execute by value. De goedkeuring moet niet over een vaag voornemen gaan (“stuur dat bericht”) maar over de concrete parameters (“stuur dit bericht, met deze inhoud, naar deze ontvanger”). De uitvoerende stap controleert vervolgens dat wat hij gaat doen overeenkomt met wat is afgetekend — en weigert als dat niet zo is.
Er zit een tweede helft aan, uit dezelfde week aan leeswerk over MCP-servers als een “bestuurde datalaag”: gate op identiteit, en faal gesloten. Een agent zou de permissies moeten erven van wie hem aanroept, niet draaien als één almachtig service-account “en de scope later wel regelen”. Het patroon dat me bijbleef is een splitsing in capaciteiten — de sleutel van de agent mag lezen, maar alleen de sleutel van de mens mag schrijven. Leestoegang is hoe een agent zijn werk doet; schrijftoegang is waar intentie bewezen moet worden.
Twee checks die ik aan mijn eigen systeem toevoeg
Dus deze week loop ik elke schrijvende flow langs met één vraag: is de uitgevoerde actie gebonden aan de goedgekeurde? Als een mens een wijziging goedkeurt en een script voert hem uit, delen ze dan een identificatie? Zo niet, dan is mijn poort theater — een groen lampje geschilderd op een gang zonder deur. En ten tweede: draaien mijn tool-servers als één gebruiker met volledige macht? Dan is credential-isolatie een illusie; er is geen identiteit om op te falen.
Niets hiervan is exotisch. Het is dezelfde les als elke poort waarover ik tot nu toe schreef, één laag verder geschoven: gisteren ging het erover of de controleur nog controleert; vandaag of goedkeuring de uitvoering nog bindt. Een poort die je goedkeurt maar nooit bindt is precies zo gevaarlijk als een groen vinkje op een kapotte check.
Waar raken jouw goedkeuringen en je uitvoeringen elkaar? Als een mens ja zegt en een machine doet het werk, wat bewijst dan dat de machine jouw ja deed en niet een ander? Ik hoor graag hoe anderen die twee binden — laat het weten in de comments.
Wat vond je van dit bericht?
