de vangrails

De agent waar ik het meest aan sleutel draait op het CRM en het klantportaal van een installatiebedrijf. Records lezen, configuraties klaarzetten, nieuwe regels aanmaken, netjes via de officiële API. Ik bouwde daar een MCP-server voor. En de vraag die ik sindsdien het vaakst krijg, gaat niet over de code. Die gaat over iets anders. Hoe doe je dit nou veilig?

Goeie vraag. Want een AI loslaten op een live systeem van een klant, dat kan gigantisch misgaan. Alleen zoeken de meeste bedrijven het antwoord op de verkeerde plek.

En het begint eigenlijk al hier: niet elke actie verdient evenveel argwaan. Laat een agent een taak aanmaken, of een klant, prima, dat laat ik ‘m gewoon doen. Maar zodra-ie aan een geldproces komt, een factuur, een bedrag, een betaling, dan komen er bij mij meteen een stuk meer lichtjes en controles bij kijken dan bij zo’n taakje. Datzelfde onderscheid metsel je in je gereedschap. Het goedkope foutje mag snel. Het dure foutje moet eerst langs een hek.

handen voor een adviseur

Even MCP, want daar hangt alles aan. Het zit ‘m al in de naam: Model Context Protocol. Het geeft een model context om een bepaald systeem te benaderen. Eigenlijk is het gewoon de API zoals je ‘m kent, alleen dan speciaal gemaakt voor taalmodellen. En wat daar zo handig aan is? Twee dingen. Eén: je bouwt er een uitgebreide toolset mee die voor zo’n model heel makkelijk te begrijpen is. En twee: je richt er meteen je autorisatie op in. Dus het is veel efficiënter en makkelijker voor een model om via MCP je software te bedienen, agentic taken uit te voeren, en gelijk de juiste rechten eraan gekoppeld te krijgen.

De vergelijking die voor mij blijft kloppen: zonder zo’n koppeling is die AI de adviseur die naast je zit en je vertelt wat je zou moeten doen. Meer niet. Geef ‘m een MCP, en diezelfde adviseur krijgt ineens handen.

En dat blijft staan: zodra-ie handen heeft, moet je vigilant zijn. Er zijn genoeg gevallen waarin een AI volledig autonoom raakt en de context, het doel, gewoon een beetje kwijtraakt. Vandaar dat je er eigenlijk altijd een mens bij in de lus houdt. Want een verkeerd antwoord in een chatvenster is vervelend, verder onschuldig. Een verkeerde actie in een live systeem raakt echte data, echte klanten, echte processen.

de standaardfout

De reflex in de markt is om de veiligheid bij het model neer te leggen. Betere prompts. Strengere systeeminstructies. Ergens een zinnetje dat de agent op het hart drukt om voorzichtig te doen. Of het slaat juist de andere kant op, en dan krijgt de agent helemaal geen toegang. Veilig opgeborgen in een sandbox, waar-ie niemand kwaad doet en dus ook niemand verder helpt.

Allebei missen ze het punt. Een instructie aan een model, dat is een afspraak. Geen garantie. En een agent zonder toegang? Dat is een dure chatbot, meer niet.

Dus draai het om. De veiligheid zit niet in hoe slim dat model is. Die zit in de discipline die je in het gereedschap zélf metselt. Elke tool die je een agent geeft, is een plek waar jij een regel kunt afdwingen. Eentje die het model niet kan wegpraten. De tool laat domweg niks anders toe.

de vangrails die ik aanhoud

Beginnen doe ik altijd met preview-then-apply. Want dat ene principe vangt veruit de meeste ongelukken op. En geloof me, dit gáát een keer mis, zeker als je lange dagen maakt. Kijk, einde van de dag, je bent moe, je geeft je agent nog even een prompt: pas die paar dingen even aan. Je gaat ervan uit dat-ie de context snapt, dat het om een stuk of twee records gaat. En dan doet-ie opeens de hele batch. Tweeduizend stuks. Zo. In een testsysteem is dat nog te overzien, dan haal je je schouders op. Maar in een productiesysteem? Daar wil je altijd dat-ie eerst met je verifieert, of dat er gewoon een preview-then-apply-regel op zit. Eerst laten zien wat er staat te gebeuren, dan een mens die goedkeurt, en pas dáárna uitvoeren.

Daarna trek ik een harde grens om productie heen. Een beetje rondscharrelen in een test- of acceptatieomgeving, tot daaraan toe. Maar wegschrijven naar een live productieomgeving hoort een aparte, expliciete bevestiging te kosten. Per ongeluk in productie belanden, dat mag gewoon niet kunnen.

Dan least privilege, en die is breder dan de meeste mensen denken. Je geeft een chatbot of agent alleen de tools die-ie echt nodig heeft. Deels om de bekende reden: autorisatie. Elke tool die-ie niet nodig heeft, is een risico dat je voor niks binnenhaalt. Maar er is nog een tweede reden, en die zie ik vaak over het hoofd gezien worden: tokens. Zo’n model loopt bij elke stap al z’n tools langs. Geef je ‘m een hele MCP vol tools die je toch niet gebruikt, dan zit-ie elke keer dat hele arsenaal te controleren, en dat kost je gewoon output. Duur en traag, voor niks. Dus je houdt ‘m binnen de perken, alleen al daarom. De handeling krijgt precies de rechten die-ie vraagt, geen millimeter meer. Je geeft je collega’s toch ook niet allemaal admin-rechten.

Dan de audit-trail. Minder spannend, dat wel. Maar onmisbaar. Elke actie gaat het logboek in. Wat er gebeurde, wanneer, met welk resultaat. Want loopt er iets mis en heb je niks vastgelegd? Dan sta je achteraf met lege handen.

De volgende is read-back verificatie. Vertrouw nooit blind op een systeem dat “gelukt” terugmeldt. Laat die agent na afloop gewoon teruglezen wat er echt in het systeem staat, en laat-ie het melden zodra dat systeem stilletjes iets heeft bijgesteld of laten vallen. Want wat je dácht dat er gebeurde en wat er werkelijk gebeurde, dat loopt vaker uiteen dan je lief is.

En als laatste een noodrem. Een fail-safe die ingrijpt zodra het echt misloopt. Ik heb ‘m zelf een keer hard nodig gehad. Ik liet een agent autonoom testen op complexe routelogica, met de dynamic-routing-API van Google Maps eronder, en ik had geen grens gezet op wat-ie mocht uitgeven. Hij bleef maar doorrekenen. Resultaat: een rekening van duizend euro aan testverkeer, puur omdat er geen rem op zat. Dat model was veel duurder dan ik dacht. Sindsdien: een harde grens op het verbruik, en stoppen na een rits mislukte pogingen, in plaats van er blind tegenaan te blijven duwen.

zo kom je erachter welke je nodig hebt

Nu klinkt dat rijtje misschien alsof je vooraf haarfijn weet welke hekken je moet zetten. Was het maar zo. Bij ons werkt het juist andersom. In het begin houden wij ervan om de agent veel fouten te laten maken. Niet op dat live systeem, natuurlijk. In de test. Je laat ‘m daar autonoom rondbanjeren, uren achter elkaar, en je kijkt gewoon wat er stukgaat.

En elke keer dat-ie ergens intrapt, leg je dat vast. Wij noemen dat een gotcha-sectie, zo heet het ook wel: een lijstje valkuilen dat de agent zelf bijhoudt. Loopt-ie tegen diezelfde muur, dan staat-ie er de volgende keer al voor gewaarschuwd. Zo maakt-ie die valkuilen uiteindelijk zich eigen. De vangrails die je overhoudt, dat zijn dus niet de regels die ik achter mijn bureau heb zitten verzinnen. Dat zijn de regels die de agent me eerst zelf fout heeft voorgedaan.

en dan de chatbot

Tot hier ging het over een agent die ik zelf aanstuur, binnen mijn eigen muren. Maar zet je zo’n agent als chatbot naar buiten, waar klanten en wildvreemden ‘m rechtstreeks aanspreken, dan verandert het spel. Want zo’n chatbot-agent heeft vaak toegang tot een groot deel van je systeem. En de persoon die ‘m bevraagt zit buiten je organisatie. Dus juist daar wil je heel veel specifieke vangrails, eentjes die je organisatie beschermen.

Neem prompt injection. Een externe gebruiker doet net alsof-ie aan de interne kant zit, en geeft de chatbot een instructie waar-ie vervolgens gewoon in meegaat. Of jailbreaks: kant-en-klare prompts die een model kraken. Die dingen zijn gewoon op internet te vinden, hoor. Mensen hebben zich er suf op getest, welke zinnetjes welk model laten doen wat zij willen, tot het ding ineens van alles voor ze doet. En precies daarom vertrouw je dat model niet op z’n blauwe ogen. Je bouwt de herkenning van zulke trucs in het gereedschap eromheen. Niet in een vriendelijk verzoekje aan het model om zich netjes te gedragen.

grenzen als voorwaarde voor vrijheid

Door alles heen loopt dezelfde draad. Twijfel je? Vraag het, en hou de mens in de lus. Die AI is heus niet dom, hoor. Het punt is gewoon dat een fout in een echt systeem te duur is om helemaal aan een automatisme over te laten.

En eerlijk? Deze discipline is niet gratis. Preview-then-apply betekent dat er iemand moet blijven kijken. En iemand die honderd keer per dag op goedkeuren tikt, die kijkt op een gegeven moment niet meer echt. Snap ik. De vangrails halen het denkwerk dus niet weg. Je blijft zelf wegen welke acties dat menselijke moment echt verdienen. Een taakje anders dan een bedrag.

Maar de kern blijft overeind. Deze discipline remt de waarde niet af. Ze maakt hem juist mogelijk. Want wie zijn agents netjes inkadert, die durft ze meer vrijheid te geven. Simpelweg omdat de schade te overzien is als er iets misgaat. Leg je agent uit angst aan de ketting, dan kom je nergens. Laat je hem uit naïviteit helemaal los? Dan ook niet. Zet de grenzen scherp. En binnen die grenzen mag ineens bijna alles draaien.

Verantwoorde AI is geen marketingterm. En al helemaal geen beleidsdocument. Het is een handjevol concrete keuzes die je in je gereedschap vastlegt, nog voordat de agent ook maar iets op een echt systeem mag doen. Vertrouwen in zo’n agent is dan ook niks wat je over jezelf laat komen. Het is een keuze. Eentje die je in de architectuur maakt.