Vertrouw AI-agenten niet

Als je met AI-agenten bouwt, moeten ze behandeld worden als onbetrouwbaar en potentieel kwaadwillend. Of je je nu zorgen maakt over prompt injection, een model dat uit zijn sandbox probeert te ontsnappen, of iets waar nog niemand aan heeft gedacht, ongeacht je dreigingsmodel: je zou de agent niet moeten vertrouwen. De juiste aanpak is niet betere machtigingscontroles of slimmere allowlists. Het is architectuur die ervan uitgaat dat agenten zich zullen misdragen en de schade beperkt wanneer ze dat doen.

Dat is het principe waarop ik NanoClaw heb gebouwd.

Vertrouw het proces niet

OpenClaw draait standaard rechtstreeks op de hostmachine. Er is een optionele Docker-sandboxmodus, maar die staat standaard uit en de meeste gebruikers zetten hem nooit aan. Zonder sandbox is de beveiliging volledig afhankelijk van controles op applicatieniveau: allowlists, bevestigingsprompts, een reeks “veilige” commando’s. Deze controles gaan uit van een impliciet vertrouwen dat de agent niet zal proberen iets fout te doen. Zodra je de mentaliteit aanneemt dat een agent potentieel kwaadwillend is, is het duidelijk dat blokkeringen op applicatieniveau niet genoeg zijn. Ze bieden geen hermetische beveiliging. Een vastbesloten of gecompromitteerde agent kan er manieren omheen vinden.

In NanoClaw is containerisolatie een kernonderdeel van de architectuur. Elke agent draait in zijn eigen container, op Docker of een Apple Container op macOS. Containers zijn efemeer: ze worden per aanroep nieuw aangemaakt en daarna vernietigd. De agent draait als onbevoegde gebruiker en kan alleen directories zien die expliciet zijn gemount. De containergrens wordt afgedwongen door het besturingssysteem.

Vertrouw andere agenten niet

Zelfs wanneer de sandbox van OpenClaw is ingeschakeld, delen alle agenten dezelfde container. Je hebt misschien een agent als persoonlijke assistent en een andere voor werk, in verschillende WhatsApp-groepen of Telegram-kanalen. Ze zitten allemaal in dezelfde omgeving, wat betekent dat informatie kan lekken tussen agenten die eigenlijk toegang zouden moeten hebben tot verschillende data.

Agenten zouden elkaar niet meer moeten vertrouwen dan jij hen vertrouwt. In NanoClaw krijgt elke agent zijn eigen container, filesystem en Claude-sessiegeschiedenis. Je persoonlijke assistent kan de data van je werkagent niet zien omdat ze in volledig gescheiden sandboxen draaien.

De containergrens is de harde beveiligingslaag — de agent kan er niet uit ontsnappen, ongeacht de configuratie. Daarbovenop fungeert een mount-allowlist in ~/.config/nanoclaw/mount-allowlist.json als extra laag van defense-in-depth: deze bestaat om te voorkomen dat de gebruiker per ongeluk iets mount dat niet blootgesteld zou moeten worden, niet om te voorkomen dat de agent uitbreekt. Gevoelige paden (.ssh, .gnupg, .aws, .env, private_key, credentials) zijn standaard geblokkeerd. De allowlist bevindt zich buiten de projectdirectory, zodat een gecompromitteerde agent zijn eigen machtigingen niet kan aanpassen. De hostapplicatiecode is alleen-lezen gemount, zodat niets wat een agent doet kan blijven bestaan nadat de container is vernietigd.

Mensen in je groepen moeten ook niet vertrouwd worden. Niet-hoofdgroepen zijn standaard onbetrouwbaar. Andere groepen, en de mensen daarin, kunnen geen berichten sturen naar andere chats, taken inplannen voor andere groepen, of data van andere groepen bekijken. Iedereen in een groep zou een prompt injection kunnen sturen, en het beveiligingsmodel houdt daar rekening mee.

Vertrouw niet wat je niet kunt lezen

OpenClaw heeft bijna een half miljoen regels code, 53 configuratiebestanden en meer dan 70 afhankelijkheden. Dit ondermijnt de basispremisse van open source-beveiliging. Chromium heeft meer dan 35 miljoen regels, maar je vertrouwt op de reviewprocessen van Google. De meeste open source-projecten werken andersom: ze blijven klein genoeg zodat veel ogen ze daadwerkelijk kunnen reviewen. Niemand heeft de 400.000 regels van OpenClaw gereviewed. Het is in weken geschreven zonder behoorlijk reviewproces. Complexiteit is waar kwetsbaarheden zich verbergen, en de analyse van Microsoft bevestigde dit: de risico’s van OpenClaw kunnen opduiken via normale API-aanroepen, omdat geen enkel persoon het volledige plaatje kan overzien.

NanoClaw is een enkel proces en een handvol bestanden. We leunen zwaar op Anthropic’s Claude Agent SDK, de wrapper rond Claude Code, voor sessiebeheer, geheugencompactie en nog veel meer, in plaats van het wiel opnieuw uit te vinden. Een competente ontwikkelaar kan de hele codebase in een middag reviewen. Dit is een bewuste beperking, geen tekortkoming. Onze contributierichtlijnen accepteren uitsluitend bugfixes, beveiligingsfixes en vereenvoudigingen.

Nieuwe functionaliteit komt via skills: instructies met een volledige werkende referentie-implementatie die een coding-agent in je codebase integreert. Je reviewt precies welke code wordt toegevoegd voordat deze landt. En je voegt alleen de integraties toe die je daadwerkelijk nodig hebt. Elke installatie resulteert in enkele duizenden regels code op maat van de exacte behoeften van de eigenaar.

Dit is het echte verschil. Met een monolithische codebase van 400.000 regels, zelfs als je maar twee integraties inschakelt, is de rest van de code er nog steeds. Het is nog steeds geladen, nog steeds onderdeel van je aanvalsoppervlak, nog steeds bereikbaar door prompt injections en onbetrouwbare agenten. Je kunt niet ontwarren wat actief is en wat sluimerend. Je kunt het niet auditen omdat je niet eens de grens kunt definieren van wat “jouw code” is. Met skills is de grens duidelijk: het zijn enkele duizenden regels, het is allemaal code die je zelf hebt gekozen om toe te voegen, en je kunt elke regel lezen. De kern wordt in de loop der tijd zelfs kleiner: WhatsApp-ondersteuning wordt bijvoorbeeld uitgehaald en als skill verpakt.

Ontwerp voor wantrouwen

Als een hallucinatie of een zich misdragende agent een beveiligingsprobleem kan veroorzaken, dan is het beveiligingsmodel kapot. Beveiliging moet buiten het agentische oppervlak worden afgedwongen, niet afhankelijk zijn van correct gedrag van de agent. Containers, mountrestricties en filesystemisolatie bestaan zodat zelfs wanneer een agent iets onverwachts doet, de schaderadius beperkt blijft.

Niets hiervan elimineert risico. Een AI-agent met toegang tot je data is inherent een risicovolle opzet. Maar het juiste antwoord is om dat vertrouwen zo smal en zo verifieerbaar mogelijk te maken. Vertrouw de agent niet. Bouw muren eromheen.

Je kunt de broncode en het volledige beveiligingsmodel van NanoClaw lezen; ze zijn kort genoeg om in een middag door te nemen.