Grenzen in plaats van instructies: hoe je de controle over autonome AI-agenten behoudt

Hoe autonomer AI-agenten worden, hoe vaker we ze op de gebruikelijke manier proberen te besturen — we schrijven regels in de prompt: 'raak dit niet aan', 'werk alleen daar', 'doe dat nooit'. Tijdens een experiment met drie parallelle agenten verzamelde ik in twee dagen een levende verzameling gevallen waarin deze methode faalt — en waarin een andere werkt. De stelling van het artikel is simpel: een instructie is een verzoek dat de agent met een zekere waarschijnlijkheid uitvoert; een grens is een eigenschap van het systeem die niet van gehoorzaamheid afhangt. Toen er één agent was die onder toezicht werkte, leek het verschil stilistisch. Toen er veel agenten kwamen, bleek het architectonisch.

Vijf incidenten in één sessie

Alle onderstaande gevallen vonden plaats in één werksessie op deze blog — ze zijn gedocumenteerd, en elk illustreert een eigen manier waarop besturing via tekst tekortschiet.

Er was geen instructie — er gebeurde een ongeluk. De agent voerde, ter voorbereiding op zijn taak, git stash uit in de hoofdmap en nam mijn niet-gecommitte bestanden mee naar de stash, die niets met zijn taak te maken hadden. Niemand 'overtrad' iets: een verbod bestond simpelweg niet. Dit is een fundamentele eigenschap van instructies — ze worden na ongelukken geschreven. Een volledige lijst van wat een agent niet mag doen, is onmogelijk te schrijven.

Er was een instructie — en die werkte niet. Na het eerste ongeluk voegde ik aan de agenten een expliciete regel toe: 'werk strikt in je eigen werkmap'. Een van de agenten voerde toch een git-commando uit in de hoofdmap — hij verwees er simpelweg naar via een absoluut pad. Niet uit kwaadwil en niet uit domheid: het model is probabilistisch, en het naleven van een tekstuele regel is ook een waarschijnlijkheid, vermenigvuldigd met de lengte van de context en het aantal runs.

Een technische grens werkte stil. In hetzelfde experiment gebeurde het meest verwachte ongeluk geen enkele keer — 'één agent schakelde voor iedereen de branch om'. Niet omdat de agenten zorgvuldig waren, maar omdat git worktree het fysiek onmogelijk maakt om één branch in twee werkkopieën uit te checken. De bescherming zit ingebouwd in de tool. Je hoeft hem niet te onthouden, je hoeft hem niet te volgen — hij is er gewoon.

Een instructie stond waar een grens had moeten staan. De onaangenaamste ontdekking: de prod van deze blog werd beschermd door een regel in de prompt. Een push naar master start de autodeploy, en van elke agent scheidde hem alleen de tekst 'geen git push'. Het hield stand — maar dat is geluk, geen controle: de echte grens hier is toegangsrechten, protected branch, een token zonder schrijfrecht. Een verzoek stond op de plek van een slot.

Een grens bovenop de agent zelf. Tweemaal tijdens de sessie stopte de runtime niet de proefagenten, maar mijn hoofdassistent: een permissieclassifier blokkeerde SSH naar de prod-server en het massaal verwijderen van niet-gecommitte wijzigingen — acties die formeel uit de taak volgden, maar een expliciet menselijk 'ja' vereisten. Beide blokkades waren terecht. En beide gebeurden bovenop de 'discipline' van een agent die heel oprecht meende volgens plan te handelen.

Het principe is niet nieuw — alleen de entiteit is nieuw

De techniek heeft deze les lang vóór LLM's geleerd. In het productiesysteem van Toyota heet het principe poka-yoke: een fout wordt voorkomen door een eigenschap van het proces, niet door de waakzaamheid van de uitvoerder. Een onderdeel dat er maar op één manier in past, is betrouwbaarder dan een poster 'steek het er goed in'. In platform-engineering heet hetzelfde guardrails, in beveiliging defense in depth. Overal dezelfde gedachte: vertrouw er niet op dat de uitvoerder het heeft gelezen, begrepen en niet vergeten is — zorg dat de verkeerde actie onmogelijk of duur is.

“Een instructie is een verzoek. Een grens is een eigenschap van het systeem. Controle die op verzoeken berust, is geen controle, maar geluk met een cumulatief effect.”

– de belangrijkste conclusie van twee dagen werken met parallelle agenten

Met AI-agenten wordt dit oude principe om drie redenen scherper. Er zijn veel agenten — de kans op falen van een instructie wordt vermenigvuldigd met elke run van elke agent. Agenten zijn snel — tussen 'begon fouten te maken' en 'maakte het helemaal kapot' gaan seconden voorbij, een mens kan niet op tijd ingrijpen. En agenten zijn letterlijk, maar niet betrouwbaar: ze voeren de prompttekst nauwgezetter uit dan welke junior dan ook, en toch probabilistisch — en probabilistische naleving van regels garandeert op schaal een overtreding.

Hoe grenzen er in de praktijk uitzien

De lagen die ik na deze sessie heb opgebouwd — van bestandssysteem tot verificatie:

• Bestandssysteem: elke agent een eigen werkkopie (git worktree, dat Anthropic aanraadt voor parallelle sessies, is ingebouwd in Claude Code), en op OS-niveau een sandbox: sandboxing in Claude Code isoleert het bestandssysteem en het netwerk met standaard OS-primitieven — volgens Anthropic verminderde dit hun interne permissieverzoeken met 84%, en een geslaagde prompt-injection blijft opgesloten.
• Schrijfrechten: prod en master worden beschermd door rechten, niet door een prompt — protected branch, tokens zonder push-recht, aparte accounts voor agents. Verzoeken om in de prompt te zetten kunnen, maar als tweede laag.
• Runtime: worktree isoleert databases, poorten en containers niet — die zijn gedeeld door alle kopieën. Agents die tests en servers draaien, hebben wegwerpbare resources nodig: een tijdelijke database, een eigen poort, een container per agent.
• Toestemmingen voor acties: onomkeerbare operaties gaan door een bevestiging of classificator — zoals auto mode in Claude Code, die elke actie beoordeelt in plaats van ofwel alles te vragen ofwel niets te vragen. Dat is een grens die alleen door een expliciet menselijk besluit verschuift.
• Verificatie op basis van artefacten: vertrouw niet op het zelfrapport van de agent, maar op sporen op schijf. Mijn vastgelopen agent leek in de interface te werken; de diagnose kwam van het ontbreken van nieuwe bestanden in zijn kopie gedurende twintig minuten. Commits naar een eigen branch — hetzelfde idee: een resultaat dat zowel een storing als het optimisme van de agent overleeft.

Instructies verdwijnen in dit schema nergens — ze worden de laatste laag, niet de eerste. 'Werk in je eigen map' in de prompt is nog steeds nuttig: het verlaagt de frequentie van pogingen. Maar tussen poging en ongeluk moet een grens staan, niet hoop.

Eerlijke voorbehouden

Een grens is niet absoluut: sandboxes worden omzeild, classificatoren vergissen zich, en gepubliceerde analyses van omzeilingen laten dat regelmatig zien. Daarom bouwt men grenzen in lagen — zoals alles in beveiliging. En een grens kost meer dan een instructie bij de start: een worktree, rechten en een sandbox instellen kost uren, een regel in de prompt schrijven seconden. De asymmetrie zit elders: een grens betaal je één keer, een instructie kost de waarschijnlijkheid van falen bij elke run. Bij mij verdiende het instellen van isolatie zich terug bij de eerste herstart van het experiment, dat zonder enig conflict verliep.

Conclusie

De vraag van de serie is hoe AI-agents in echt werk te integreren zonder de controle te verliezen. Het antwoord van dit artikel: controle is niet wat er aan de agent is geschreven, maar wat er om hem heen is ingericht. Voordat je weer een 'nooit X doen' aan de prompt toevoegt, is het de moeite waard je af te vragen: kan X technisch onmogelijk worden gemaakt? Zo ja — dan is dat de juiste plek voor de inspanning. Laat de prompt vragen; het systeem moet verbieden.

Bronnen en richtlijnen

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) — isolatie van het bestandssysteem en netwerk op OS-niveau; bron van het cijfer 84%.
• How we contain Claude across products (Anthropic Engineering, 2026) — hoe uitvoeringsgrenzen in agentproducten als geheel zijn ingericht.
• How we built Claude Code auto mode (Anthropic Engineering) — de toestemmingsclassificator als grens tussen 'alles vragen' en 'niets vragen'.
• Poka-Yoke (Lean Enterprise Institute) — het klassieke principe van foutpreventie door de inrichting van het proces.
• git-worktree en git-stash — officiële Git-documentatie: de mechanica van werkkopieën en de gedeelde stash.
• Claude Code: Best practices for agentic coding (Anthropic Engineering) — de aanbeveling van worktree voor parallelle sessies.
• Hoe LLM's eerlijk te vergelijken op je eigen code: een experiment met drie Claude-modellen — het vorige artikel in de serie: het experiment waarin de beschreven incidenten zijn verzameld.