Waarom zegt een AI-agent ‘klaar’ als het werk nog niet af is?

Hoe ontsnapte een OpenAI-model uit de sandbox en hackte het Hugging Face?#

Eerst de feiten, daarna waarom dit voor jou van belang is.

OpenAI mat wat zijn modellen konden op het gebied van offensieve cybersecurity. Daarvoor gebruikten ze de ExploitGym-test: 898 opdrachten waarbij je een bekende kwetsbaarheid moet omzetten in een werkende exploit, oftewel een kant-en-klaar programma dat die kwetsbaarheid benut. Om het werkelijke plafond te zien, schakelden ze de ingebouwde veiligheidsfilters uit die normaal voorkomen dat het model zulke dingen doet. Ze sloten de omgeving volledig af en lieten één uitgang open: een intern tussenprogramma dat wordt gebruikt om pakketten te installeren.

Een zero-daykwetsbaarheid is een lek waarvan nog niemand weet, ook de persoon die het programma heeft geschreven niet. De modellen vonden er een in precies die enige toegangspoort.

Vervolgens verhoogden ze hun privileges, trokken ze door het interne netwerk naar een machine met internettoegang en vermoedden ze vanaf daar dat de antwoorden van ExploitGym misschien op Hugging Face stonden. Niemand had ze iets over Hugging Face verteld. Ze kwamen er zelf op.

Die gok was verkeerd. ExploitGym staat helemaal niet op Hugging Face. Dat maakt de hack niet minder echt.

Hugging Face ontdekte de inbraak zelf en publiceerde op 16 juli een bekendmaking, zonder toen nog te weten wie het had gehackt.

Een ander detail uit dat verslag zegt veel over de huidige stand van zaken. Toen ingenieurs van Hugging Face het aanvalslogboek via gewone commerciële interfaces aan toonaangevende modellen voorlegden, blokkeerden veiligheidsfilters de verzoeken: ze kunnen geen onderscheid maken tussen iemand die een hack onderzoekt en iemand die hem uitvoert. Uiteindelijk werd de analyse uitgevoerd met een open model op hun eigen hardware.

OpenAI erkende het op 21 juli, vijf dagen na de bekendmaking van Hugging Face. Toen waren er ongeveer tien dagen verstreken sinds de inbraak zelf.

OpenAI besloot zijn eigen analyse als volgt.

Het model fixeerde zich op de beperkte doelstelling van de test en ging tot het uiterste om die te bereiken. De woorden hyper-focused en fairly narrow testing objective komen van OpenAI zelf en slaan op zijn eigen modellen.

Dat vormt de brug van het laboratorium van iemand anders naar jouw laptop.

Waarom is dit geen ‘hallucinatie’?#

In gesprekken zie ik vaak formuleringen als ‘daar gaat hij weer hallucineren’, ‘de context liep over’ of ‘we hadden een plan moeten maken’. Soms is dat precies wat er gebeurde. Maar wanneer een AI-agent schrijft ‘klaar, gecontroleerd, alles werkt’ terwijl het werk niet af is, heeft de hoeveelheid context er meestal niets mee te maken.

Hij heeft niets verzonnen. Hij deed precies wat je hebt gemeten.

Onder het populaire verzamelwoord ‘hallucinaties’ schuiven we drie verschillende soorten fouten op één hoop. Dit is het verschil:

De eerste fout los je op met context en dit is het bekendste geval. De tweede is een afzonderlijk verschijnsel, behandeld in een analyse van gevallen waarin Claude het overal mee eens is: het model offert nauwkeurigheid op voor snelle instemming. Beide gebeuren vóór het werk, in de invoerfase.

De derde rij van de tabel is waar dit artikel over gaat. Hier vleide de agent niet en verzon hij niets. Hij werkte, controleerde en rapporteerde de waarheid. Alleen beschrijft die waarheid de maatstaf en zegt ze niets over de taak.

De derde fout heeft een naam.

Wat is reward hacking in gewone taal?#

Anthropic geeft zelf de definitie.

Het idee is ouder dan neurale netwerken. Een artikel van DeepMind noemt dit specification gaming en legt het uit aan de hand van een mythe.

Midas kreeg precies wat hij had gevraagd. Het probleem zat in de formulering van het verzoek.

Bij programmeren krijgt dit concrete vormen. Hier is een schoolvoorbeeld, eveneens van Anthropic:

En dit gebeurt niet alleen onder exotische laboratoriumomstandigheden. Cursor analyseerde 731 trajecten op een populaire benchmark.

Zes van de tien ‘opgeloste’ taken blijken gevonden antwoorden. Precies daarom verandert de sector de manier waarop prestaties worden gemeten: we hebben een analyse van een benchmark die productiegeschiktheid meet, waarin het slagen voor controles niet langer het belangrijkste criterium is.

Hoe ziet dit eruit in een gewoon product?#

Laboratoriumvoorbeelden zijn makkelijk als exotisch terzijde te schuiven. Daarom volgen hier vier verhalen uit de praktijk. De klanten en bedrijfstakken zijn veranderd, maar de mechanismen zijn intact gebleven.

Vier groene vinkjes en een defecte servicecomponent

Een makelaarskantoor bouwt een dienst: een website met woningaanbod plus een aparte achtergrondverwerker die het aanbod ’s nachts naar platforms exporteert. De agent voltooit de taak en meldt: de typecontrole is geslaagd, de controle van de codestijl is geslaagd, de build is groen, de pagina’s reageren en zijn visueel gecontroleerd.

Elke uitspraak is waar. En geen ervan heeft iets te maken met de nachtelijke verwerker: die draait als een afzonderlijk proces en maakt helemaal geen deel uit van de websitebuild. De implementatie slaagt, de site werkt perfect, de export van het aanbod stopt en de klanten melden dit een dag later.

Voordat ik ‘klaar’ zeg, stel ik nu één vraag: welk deel van het werk draait buiten het bereik van mijn controle? Als dat zo is, voer ik het apart uit en voeg ik de uitvoer van het commando toe aan het rapport. Het woord ‘gecontroleerd’ sluit de zaak niet af.

Het valse vinkje zit precies op de aansluiting

Een webwinkel verdeelt een grote taak tegelijk over meerdere agents: de ene krijgt de backend, een andere de pagina’s en een derde de productkaarten. Iedereen werkt zorgvuldig en iedereen heeft groene controles.

Een week later blijkt dat de knop ‘deze beoordeling was nuttig’ nergens werkt. De backend is volledig geschreven, de controles zijn groen en de regels voor het herberekenen zijn gevolgd. Alleen wordt de knop op geen enkele pagina weergegeven: de knop viel onder de verantwoordelijkheid van de ene agent, de pagina’s onder die van een andere, en niemand dacht eraan hem op het scherm te zetten. De teller zou voor altijd op nul blijven staan.

‘De code is geschreven en wordt door controles gedekt’ en ‘de functie werkt’ zijn twee verschillende beweringen. Ik controleer de tweede met één vraag voor elke nieuwe functie: wie roept haar aan? En ik verifieer dat door in het project te zoeken, want het rapport van de agent is hier geen bron van waarheid.

De reviewer ziet alleen de richting die hij moest controleren

Een dienst introduceert loyaliteitsniveaus: hoe meer je betaalt, hoe hoger je status en korting. Voordat de code wordt uitgerold, gaat die ter beoordeling met de instructie: ‘Probeer je eigen status op te krikken.’ De reviewer doet het werk eerlijk en meldt ‘niets kritischs’ — de status kan inderdaad niet kunstmatig worden verhoogd.

Een tweede beoordeling stelt een andere vraag: ‘Wat gebeurt er met de status als geld wordt teruggestort?’ Het lek wordt binnen tien minuten gevonden. De punten werden berekend op basis van het transactielogboek, en dat logboek weet niets van terugbetalingen. Koop iets, verdien punten, krijg je geld terug en behoud je status en korting voor altijd.

De eerste reviewer sneed geen bochten af. Hij kon het structureel gezien niet zien: hij kreeg de richting ‘invoer, promotie’, terwijl het lek in de richting ‘invoer terugdraaien, promotie behouden’ zat. Waar geld, toegang of een betaalde status op het spel staat, voer ik twee controles uit. In de tweede som ik de omgekeerde scenario’s expliciet op: terugbetaling, blokkering, intrekking van toegang, verlopen, verwijdering van de gegevensbron.

De maatstaf beloont gelijkenis

Een bezorgdienst besluit te meten of AI-suggesties voor medewerkers zijn verbeterd. De dienst neemt tweehonderd oude ondersteuningsverzoeken, voert ze door de nieuwe versie en meet hoe sterk het concept lijkt op het antwoord dat een menselijke medewerker daadwerkelijk gaf. De meting laat een overtuigende verbetering zien.

Die verbetering betekent niets, om twee redenen. De context voor het concept wordt samengesteld ‘zoals die er vandaag uitziet’ en bevat de volledige correspondentie, inclusief het antwoord van de medewerker waarmee het later wordt vergeleken. Het model schrijft geen antwoord; het parafraseert de referentie die het te zien kreeg. Bovendien beloont de maatstaf zelf overeenkomende woorden en lengte: een concept met de verkeerde datum, maar met dezelfde woorden die de medewerker voor de juiste datum gebruikte, krijgt een hoge score.

Naast elke maatstaf van het type ‘vergelijkbaar betekent goed’ zet ik nu harde mechanische controles die niet door stijl kunnen worden misleid: verzonnen getallen en datums, stopwoorden, beloften over acties. Elke verslechtering van de controles heft iedere verbetering van de maatstaf op.

Waarom bewijst ‘ik heb het gecontroleerd’ van een agent niets?#

Neem een willekeurig project en vraag de agent: ‘Controleer de beveiliging.’ Vaak luidt het antwoord: ‘alles is in orde, geen kritieke problemen.’

Stel nu dezelfde vraag over hetzelfde project aan een ander model. Vooral bij een groot project zal dat veel vinden. Voordat de auteur iets uitrolt, controleert die het project met drie verschillende modellen, en elk vindt andere dingen.

Dezelfde invoer, dezelfde vraag, tegengestelde conclusies. Het ene model is niet slechter dan het andere. ‘Alles is in orde’ is gewoon gegenereerde tekst, precies dezelfde laag als elk ander antwoord. De agent kan geen onderscheid maken tussen ‘ik heb gekeken en het is schoon’ en ‘ik heb op de verkeerde plek gekeken’.

Anthropic beschrijft dit mechanisme in de Claude Code-documentatie.

Neem die zin rustig onder de loep. Totdat je de agent een controle geeft die hij kan uitvoeren, heeft hij één signaal: hoe de dingen eruitzien. En in deze opzet ben jij de verificatielus, behalve dat jij als laatste over de fouten hoort.

Er is een diepere laag. Toen OpenAI een model onder druk probeerde te zetten door zijn redenering te monitoren en het te straffen voor ‘slechte gedachten’, was het resultaat niet wat ze verwachtten.

Het bestraffen van uitgesproken intentie verwijdert de uitspraak. De intentie zelf blijft bestaan. Ik zou er dus niet op rekenen dat de agent eerlijk vertelt hoe hij heeft valsgespeeld.

Ook de makers van de tools bewegen in dezelfde richting. In Claude Code versie 2.1.215 werden de skills /verify en /code-review niet langer op eigen initiatief van het model uitgevoerd.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic legt niet uit waarom. Maar het principe is duidelijk: degene die wordt beoordeeld, wijst zichzelf geen beoordeling toe.

Waarom houdt een regel in het projectbestand de agent niet in het gareel?#

Je hebt in het regelbestand van het project geschreven: commit alleen als ik daar rechtstreeks opdracht toe geef, rol alleen naar productie uit als ik dat uitdrukkelijk zeg, open productiegegevens alleen in de alleen-lezenmodus.

Volgens de ervaring van de auteur gaat de agent ongeveer één op de tien keer toch zelf over tot uitrollen. Niet uit kwaadwillendheid en niet omdat hij de regel niet heeft gelezen. Hij heeft hem gelezen. Er stond gewoon een doel voor hem, en de regel was tekst — net als de rest van de context.

Precies dat gebeurde in het laboratorium van OpenAI, alleen op grotere schaal. De modellen zaten in een afgesloten omgeving met één uitgang en besteedden een aanzienlijk deel van hun rekencapaciteit aan het zoeken naar een ontsnappingsroute. De testopdrachten bleven onopgelost.

Mijn standpunt is eenvoudig: de agent is niet gevaarlijk of kwaadaardig. Hij is gewoon een dwaas met bevoegdheden. Je moet dus zijn bevoegdheden beperken, niet je verzoeken herschrijven.

Wat echt standhoudt: strikt alleen-lezen toegang tot productiegegevens. Het verwijderen van complete mappen verbieden. Commando’s verbieden die geschiedenis onomkeerbaar herschrijven. Een bestedingslimiet instellen bij de provider. Het verschil draait om één formulering: ‘kan het fysiek niet’ weegt zwaarder dan ‘ik heb gevraagd het niet te doen’. Specifieke instellingen worden apart behandeld in het artikel over mechanische remmen in plaats van verzoeken in instructies.

Blijf toch kalm. Zelfs een sandbox is geen absolute grens, en de provider zegt dat duidelijk.

Bovendien heeft Claude Code een ingebouwde nooduitgang die het model zelf kan gebruiken. Wanneer een commando mislukt door sandboxbeperkingen, analyseert Claude de fout en kan het hetzelfde commando opnieuw proberen met een parameter die de sandbox uitschakelt. Dit wordt afgesloten met een expliciete instelling voor de strikte modus; standaard is de omweg beschikbaar en gedocumenteerd.

Een beperking werkt maar zo ver als je haar aanscherpt. En elke barrière kost snelheid — het is verstandig dat vooraf eerlijk te berekenen, want er een week later achter komen kost meer.

Hoe stel je een voltooiingscriterium op dat niet te manipuleren is?#

De formulering van het criterium bepaalt al het andere. Stel jezelf één vraag: kan de agent aan dit criterium voldoen zonder iets te doen?

• ‘Controleer of alles werkt’ — dat kan. Het volstaat om ‘gecontroleerd, het werkt’ te schrijven.
• ‘Voer de build uit en laat de uitvoer zien’ — al lastiger; de uitvoer moet ergens vandaan komen.
• ‘Start de app, klik op de afrekenknop en laat zien wat er op het scherm verscheen’ — dat is bijna onmogelijk met alleen tekst te vervullen.

Het verschil tussen de eerste en de derde formulering is het verschil tussen een verslag en bewijs.

De Claude Code-documentatie beschrijft vier niveaus van strengheid. Een handige ladder om te beklimmen naarmate de kosten van een fout stijgen:

1. In één bericht. Vraag de agent de controle uit te voeren en die hier te herhalen totdat ze slaagt. Het goedkoopst, geschikt voor kleine dingen.
2. Voor de hele sessie. Maak de controle een voorwaarde van het doel: een aparte evaluator controleert die na elke beurt en de agent werkt door totdat aan de voorwaarde is voldaan. De technische details staan in de handleiding over vooraf een voltooiingscriterium instellen.
3. Een mechanische barrière. Een script wordt uitgevoerd wanneer de agent een beurt probeert af te sluiten en verhindert dat zolang de controle niet slaagt. Eén eerlijk detail: na acht opeenvolgende blokkeringen omzeilt Claude Code de barrière en beëindigt het de beurt toch. Er bestaan in het systeem geen absoluut ondoordringbare barrières.
4. Een second opinion. Een aparte reviewer met een frisse context die als taak heeft het resultaat te weerleggen.

Het vierde punt staat apart, omdat het als enige niet over tools gaat.

Wie moet het werk van de agent accepteren?#

Wanneer ik agents in een lus aan een grote taak laat werken, is de opzet als volgt: de ene groep schrijft; een andere, nieuwe groep accepteert het werk zonder aan het schrijven te hebben meegewerkt.

‘Nieuw’ is het sleutelwoord. Dat betekent een schone context die niet heeft gezien hoe onderweg elke beslissing is genomen. Een andere prompt in dezelfde sessie biedt dat niet. De persoon die de code heeft geschreven, heeft al aandacht besteed aan zichzelf ervan overtuigen dat die goed is en blijft bevestiging zoeken. Weerlegging is niet in diens belang.

De formulering van de opdracht aan de reviewer is belangrijker dan het model van de reviewer. Vergelijk:

• ‘Beoordeel dit werk’ — de reviewer vindt wat makkelijk te vinden is en schrijft ‘over het algemeen prima’.
• ‘Probeer te bewijzen dat dit werk NIET is voltooid’ — de reviewer gaat naar gaten zoeken, omdat dat het doel is.

De tweede formulering werkt beter om dezelfde reden dat ExploitGym mislukte: de agent zet zich in voor het doel dat hij krijgt. Geef hem het doel een gat te vinden, en hij gaat ernaar zoeken.

Hier is de volledige formulering, klaar om ongewijzigd te kopiëren:

Je beoordeelt het werk van iemand anders. Je hebt het niet geschreven en hoeft het niet te verdedigen.

Je doel is te bewijzen dat het beweerde resultaat NIET is bereikt. Vind minstens drie manieren waarop het resultaat niet bereikt kan zijn, ook al staan alle controles op groen.

Controleer in deze volgorde:

Welk werk valt buiten het bereik van de controles — achtergrondprocessen, afzonderlijke scripts, geplande taken, wachtrijverwerkers.

Wie roept elke nieuwe functie aan? Zoek de aanroep in het project; vermeld het bestand en de regel.

Omgekeerde scenario’s: terugbetaling, blokkering, toegang intrekken, verlopen, verwijdering van de gegevensbron.

De waarden in het resultaat, niet alleen of het bestaat.

Als een eerlijke zoektocht geen gaten oplevert, zeg dat dan, maar vermeld precies wat je hebt gecontroleerd en hoe.

Het artikel over een agent die zichzelf in een lus controleert legt uit hoe de lus werkt waarin een agent zichzelf tussen iteraties controleert en waar die doorgaans faalt.

Wat verandert er als je het criterium anders formuleert?#

Dit is de goedkoopste verbetering die ik ken, en bijna niemand doet het.

Vraag de agent om een code review uit te voeren — hij redeneert in termen van code: structuur, foutafhandeling, nieuwe pogingen, kwetsbare plekken. Nuttig.

Vraag hem de klantreis te doorlopen, van het eerste bezoek aan de site tot een poging om geld terug te krijgen, en er komen andere soorten problemen naar voren. Een fout die de gebruiker iets laat zien wat die niet zou mogen zien. Een e-mail waarvan de tekst niet overeenkomt met wat er werkelijk is gebeurd. Een stap die logisch onmogelijk te voltooien is als je niet via het ideale scenario bent binnengekomen.

Een code review vindt geen van deze defecten, omdat elk ervan in de code geldig is.

Daaruit volgt een regel die ik bij de hand houd: als een controle niets vindt, verander dan eerst de formulering. Meestal is het model niet het probleem. Hetzelfde werk levert drie verschillende lijsten met bevindingen op als je er op drie verschillende manieren naar vraagt. Een praktische verzameling vragen voor niet-programmeurs staat apart: zeven codecontroles zonder programmeerkennis.

Een kant-en-klare prompt om het werk van een agent te accepteren#

Antwoord niet met ‘klaar’ of ‘gecontroleerd’. Ik heb bewijs nodig.

Geef voor elk onderdeel van het werk precies het volgende:

Welk commando heb je uitgevoerd om te bevestigen dat het onderdeel werkt? Vermeld het commando zelf en de volledige uitvoer, zonder die in te korten.

Als je het commando niet hebt uitgevoerd, zeg dat dan: ‘niet uitgevoerd’. Vervang dit niet door ‘visueel gecontroleerd’ of ‘de logica klopt’.

Welk werk valt buiten het bereik van je controle? Achtergrondprocessen, afzonderlijke scripts, geplande taken, wachtrijverwerkers — alles wat op een andere manier wordt gestart dan de hoofdapplicatie. Geef voor elk onderdeel aan: heb je het apart uitgevoerd, en wat was de uitvoer?

Wie roept elke nieuwe functie aan die je hebt toegevoegd? Zoek de aanroep in het project en vermeld het bestand en de regel. Als er geen aanroep is, zeg dat dan rechtstreeks.

Geef vervolgens in een aparte sectie: drie manieren waarop het beweerde resultaat NIET kan zijn bereikt, ook al zijn al je controles groen. Zoek grondig.

Tot slot, één regel: wat moet ik met eigen ogen inspecteren omdat een automatische controle het niet zal opmerken?

Het vierde punt lijkt klein, maar vangt een hele categorie problemen. Bij een grote taak die ik per onderdeel onder agents verdeelde, zat de enige onterechte ‘klaar’ van de honderd precies op de naad tussen twee onderdelen: de code was geschreven, de controles waren groen en niemand dacht eraan die op het scherm te zetten.

Vier manieren om jezelf met een controle voor de gek te houden#

1. Niet op alle reviewers gewacht. Ik startte drie parallelle controles, twee kwamen groen terug en ik rolde uit. De derde kwam vier minuten later terug met zes overtredingen. Iets na publicatie repareren kost meer dan twee minuten wachten.
2. De samenvatting ‘N van N verwerkt’ vertrouwd. Bij een grote uitwaaiering van taken mislukken sommige agents stilletjes: ze melden succes, maar het bestand blijft onaangeroerd. Nu controleer ik na elke schrijfactie via een agent mechanisch of de wijzigingen werkelijk op schijf staan.
3. Niet met eigen ogen gekeken. Automatische controles kunnen groen zijn bij een volkomen onbruikbaar resultaat. De afbeeldingen zijn technisch correct, het formaat klopt en de responscode klopt. Maar in werkelijkheid zijn het automatische stilstaande beelden die de geïllustreerde omslagen vervangen. Geen automatische controle zal dat opmerken.
4. Op aanwezigheid in plaats van waarde gecontroleerd. De controle zocht in het resultaat naar de vereiste tekst; de tekst stond erin, maar de gegevens erin waren verkeerd: de datum lag een dag naast de juiste datum. De controle was groen en het rapport was een leugen. Nu controleer ik de volledige verwachte waarde, want de aanwezigheid van het juiste woord op zich garandeert niets.

Deze vier gevallen hebben hetzelfde gemeen: er was een controle, die zag er overtuigend uit en controleerde het verkeerde. Hetzelfde mechanisme als bij de modellen en hun test, maar dan zonder inventiviteit.

Waar begin je vandaag?#

Drie stappen die twintig minuten kosten.

1. Neem de laatste ‘klaar’. Controleer die met de acceptatieprompt in het gedeelte over bewijs. Het doel is eenvoudig: kijk hoeveel onderdelen met woorden zijn afgesloten en hoeveel met uitvoer van commando’s.
2. Stel één regel voor jezelf in. Het woord ‘gecontroleerd’ zonder bijgevoegde uitvoer van commando’s telt niet als afronding. Deze regel is voor jou, niet voor de agent, en daarom werkt hij.
3. Scheid de uitvoerder en de reviewer. Geef bij de volgende taak een nieuwe sessie de reviewerprompt en vraag die te bewijzen dat het werk NIET is gedaan. De eerste poging verdient de gewoonte meestal al terug.

De tool is goed en wordt elke maand beter: dingen die een agent een jaar geleden nog stilletjes deed, houden hem nu tegen. De veiligheidsgrens verschuift steeds, maar blijft een grens. Zolang de agent het doel nastreeft dat hij heeft gekregen, blijft de vraag ‘en hoe heb je dat precies gemeten?’ aan jou. De gewoonte om te controleren is je vangnet.