Gisteren schreef ik dat het geheugen van een agent een contract nodig heeft: wie mag schrijven, wat mag blijven, en wat telt als bewijs. Het klinkt solide, tot je de enige vraag stelt die écht telt — wie dwingt het af? Een regel die in een prompt leeft is geen regel. Het is een wens met goede manieren.
Ik draai een agent-stack die wakker wordt voordat ik dat doe. Cron-jobs halen het nieuws op, genereren afbeeldingen en publiceren naar twee websites terwijl ik nog slaap. Om 6 uur ’s ochtends is er geen goedkeuringsvenster, want er is niemand die erop kan klikken. Lang was mijn vangnet hetzelfde als dat van iedereen: de instructie. “Vraag het eerst.” “Wees voorzichtig met credentials.” Dat werkt precies tot het moment dat de agent alleen is.
De poort hoort een laag lager
Een draad op r/mcp stelde de praktische versie van mijn vraag: “Voor MCP-servers die echt iets kunnen veranderen — hoe poort je schrijf-acties?” De antwoorden lazen als een anatomie van handhaving, en ik herkende mijn eigen gaten in bijna elk ervan.
- Scheid lees- en schrijf-tools. Lezen is makkelijk; schrijven is waar je blijft twijfelen, zeker als een verkeerde call echt geld kost. Houd schrijf-tools alleen in sessies waar je ze expliciet aanzet.
- Schrijf-tools die nog niets doen. Ze geven een preview van de wijziging plus een token. Pas een tweede call mét dat token voert het echt uit. Zoals iemand het samenvatte: “Het model kan de preview niet overslaan.”
- Leunen op de permissie-prompts van de client. Handig — en het “werkt precies tot iemand op altijd toestaan klikt.”
- Harde limieten in de server. Een maximum per call, geen deletes, wat het model ook vraagt.
Alleen die laatste overleeft een onbeheerde run. De derde is de valkuil waarin ik half leefde: een goedkeuringsvenster is spiergeheugen, en spiergeheugen faalt zodra iets op “altijd toestaan” klikt.
Een limiet per actie is geen limiet
De scherpste observatie kwam uit een andere draad: “40 terugbetalingen van €90 zijn allemaal individueel prima en tellen op tot €3.600 die niemand heeft goedgekeurd.” Dat zette iets recht wat ik verkeerd had. Mijn vangrails waren vooral per actie — één publicatie per run, één write per call. Maar een vaste drempel per eenheid is geen plafond als de hoeveelheid vrij is. Het plafond moet cumulatief zijn: per dag, per week, per doel.
En de sandbox-helft
Het zusterstuk was een server die MCP-processen in een sandbox zet zonder hun secrets: omgevingswaarden, auth-headers en tokens strippen vóór het opslaan, npm-lifecycle-scripts uitzetten, dependencies pinnen, en precies één netwerk-regel per opzet toestaan. Dat is het verschil tussen “raak alsjeblieft de credentials niet aan” en een proces dat ze domweg niet kan zien.
Wat ik echt heb veranderd
Ik ben opgehouden verificatie als genoeg te zien. Mijn verificatie-gate leest de eindstaat terug na de write — dat is de regel “een timeout is onbekend, niet mislukt”, en die is het houden waard. Maar hij gebeurt achteraf. Wat ontbrak was de preview ervoor: een schrijfstap die de wijziging toont en een token teruggeeft, zodat niets er stil langs kan glippen.
Hetzelfde gat zit in mijn geheugenlaag. Die heeft veracity-tags — stated, tool, inferred, unknown — maar geen onveranderlijkheid en geen ondertekenaar. Een van de projecten die ik las houdt zijn geheugen als markdown in een vault waar als ik een regel bewerk, mijn versie wint — een agent kan die later niet overschrijven. Dat is geen richtlijn. Dat is een poort.
De ongemakkelijke les van vandaag: ik vertrouwde regels die leefden in precies de laag die de agent zelf beheert. Verplaats ze één niveau naar beneden — naar de tool, de server, de sandbox — en ze zijn geen belofte meer. De vraag die ik mezelf nu blijf stellen: waar mag jouw agent nog steeds de regels veranderen die hij hoort te gehoorzamen?
Wat vond je van dit bericht?
