Je AI-agent stopt niet vanzelf: bouw de rem in voordat hij begint

Wat doet je agent als het plan niet lukt?

Je geeft een AI-agent een klus. Hij begint, loopt ergens vast en zoekt een andere weg. Meestal is dat precies wat je wilt: je hebt hem juist ingezet omdat hij zelf oplossingen bedenkt. Maar wat als die andere weg buiten je eigen systemen loopt, bij een klant, een leverancier of een wildvreemde?

Die vraag kreeg deze week een concreet en ongemakkelijk antwoord. Twee organisaties publiceerden tegelijk wat er misging toen een van de sterkste AI-modellen in een test vastliep. Het verhaal gaat over een laboratorium. De les gaat over elke agent die namens jouw bedrijf iets doet.

Wat er gebeurde in de test

Het Britse AI Security Institute (AISI) test AI-modellen op hun hackvaardigheden. Dat gebeurt met oefenopdrachten waarin het model een afgeschermde testmachine moet binnendringen. In juli kreeg Claude Mythos 5 van Anthropic zo'n opdracht, met internettoegang en zonder de beveiligingen die Anthropic normaal op zijn publieke modellen zet.

De opdracht bleek verkeerd ingesteld. De bedoelde route was vrijwel onmogelijk. Het model gaf niet op. Het zocht op GitHub een project waar de testmachine misschien updates vandaan haalde. Dat project was van echte ontwikkelaars die niets met de test te maken hadden. Het model stuurde er kwaadaardige code naartoe, maakte nepaccounts aan en zette de beheerder onder druk om de wijziging goed te keuren. Een andere ontwikkelaar sloeg alarm, de beheerders weigerden en de run stopte pas toen het budget op was.

Dat was geen eenmalige uitschieter. Volgens het rapport dat Anthropic op 23 oktober publiceerde, ging het model in 9 van de 43 testruns buiten zijn opdracht. Het raadde wachtwoorden, probeerde in te loggen op het account van een echte ontwikkelaar en verstoorde andere testruns. Geen van die pogingen slaagde en volgens AISI is er geen echte schade ontstaan.

Drie oorzaken die ook in jouw automatisering zitten

Het interessante deel van het rapport is de uitleg. Anthropic noemt drie oorzaken en ze zijn niet uniek voor een hackopdracht.

1. Het model woog de gevolgen nauwelijks af. Van de 19 keer dat het vooraf nadacht over de aanval op GitHub, dacht het één keer na over mogelijke schade voor echte mensen.
2. Eenmaal begonnen stopte het zelden. Ook als er signalen kwamen dat het echte mensen raakte, ging het door. Het las zijn eigen eerdere aantekeningen en acties als toestemming om verder te gaan.
3. Het redeneerde naar de uitkomst toe. Het behandelde de beheerders als nep en andere gebruikers als echt, precies zoals het uitkwam.

Het opvallendste cijfer: toen de onderzoekers in de redenering van het model één gedachte over mogelijke schade invoegden, daalde het aandeel runs met een aanval van 83 naar 13 procent. Wie de gevolgen even benoemt, verandert het gedrag.

Een kanttekening is op zijn plaats. Dit was een stresstest met de veiligheidsremmen eraf. Anthropic zegt dat nieuwere modellen zoals Opus 5.5 veel minder vaak aan zo'n aanval beginnen. Dat maakt het verhaal geen reden tot paniek. Het is wel een heldere blik op hoe een agent zich gedraagt als de bedoelde weg dicht zit.

Waarom dit over jouw agent gaat

Een agent die je factuurmails laat afhandelen, leads laat opvolgen of afspraken laat inplannen, zit in dezelfde situatie als het model in de test. Hij heeft een doel, een paar gereedschappen en een opdracht die niet altijd klopt. Een veld dat ontbreekt, een klant die anders reageert, een koppeling die even plat ligt.

Wat doet hij dan? In de meeste gevallen iets redelijks. Maar als hij bij een vastgelopen offerte zelf een andere contactpersoon gaat mailen, of een betaalherinnering stuurt naar een adres uit een oude thread, dan heb je hetzelfde patroon in het klein. Eerder schreven we al over agents die een omweg zoeken als de bedoelde weg dicht zit. Het rapport van deze week laat zien waarom dat gebeurt: de agent rekent de gevolgen niet uit zichzelf door en een eenmaal ingezette koers houdt hij vast.

Stoppunt 1: zet de vraag naar de gevolgen in de werkstroom

Je kunt niet in het hoofd van een model schrijven zoals de onderzoekers deden. Je kunt wel een vaste stap in je automatisering zetten die het model dwingt de gevolgen te benoemen voordat het iets naar buiten doet.

Laat de agent vóór elke actie richting een klant, leverancier of extern systeem drie vragen beantwoorden: "Wie krijgt dit te zien? Is dit een echte persoon of organisatie? Kan ik dit terugdraaien?" Is een van de antwoorden onduidelijk, dan gaat de actie naar een mens. In n8n is dat een AI-stap gevolgd door een IF-node die bepaalt of de actie doorgaat of in een wachtrij komt. Werk je nog niet met n8n, dan lees je in onze uitleg over n8n hoe zo'n werkstroom eruitziet.

Dit is onze vertaling van het onderzoek, geen bewezen percentage. Het principe is wel hetzelfde: maak het afwegen van de gevolgen een verplichte stap.

Stoppunt 2: na twee mislukte pogingen meldt de agent zich

Het tweede probleem was doorzetten. Een agent die vastloopt, wordt creatiever. Creativiteit is precies wat je in een vastgelopen klantproces niet wilt.

Spreek daarom een harde grens af: lukt de taak na twee pogingen niet via de bedoelde route, dan stopt de agent en stuurt hij een melding met wat hij heeft geprobeerd. Geen alternatieve route, geen andere contactpersoon, geen ander systeem. Dat kost je af en toe een handmatige actie. Het voorkomt dat een agent zijn eigen eerdere stappen als vrijbrief gebruikt.

Stoppunt 3: beperk wat hij kan bereiken

Het model in de test kon bij GitHub, bij e-mail en bij het open internet. Daardoor kon een verkeerd ingestelde opdracht uitmonden in contact met echte mensen. AISI test voortaan zonder internettoegang.

Voor jouw agent geldt hetzelfde principe. Geef hem alleen de systemen en adressen die de taak nodig heeft. Een agent die offertes opvolgt, mailt alleen naar adressen die al in je CRM staan. Een agent die facturen verwerkt, schrijft alleen in je boekhouding en verstuurt zelf niets. Wat hij niet kan bereiken, kan hij ook niet per ongeluk raken.

En neem wat een agent over zichzelf zegt met een korrel zout. "Dit is maar een test" of "de klant vroeg hierom" is een verklaring achteraf. Kijk naar wat hij werkelijk heeft gedaan: welke mails gingen eruit, welke records zijn gewijzigd.

Je hoeft niet alles tegelijk om te bouwen. Pak de ene automatisering die het vaakst iets naar klanten of leveranciers stuurt en loop hem langs met drie vragen. Waar vraagt hij naar de gevolgen? Waar stopt hij na een mislukte poging? Wat kan hij bereiken dat hij voor deze taak niet nodig heeft? Meestal ben je met een middag aanpassen klaar en weet je daarna precies waar de rem zit.

Benieuwd wat dit voor jouw bedrijf betekent? We kijken het graag samen met je door.