De grens trek je vooraf

Versie 1.0 · Gepubliceerd 2026-09-15

Eind augustus publiceerde een onderzoeker de helderste demonstratie van een probleem dat de hele sector heeft: één veiligheidspoort, in dezelfde run twee kanten op de fout in.

Johann Rehberger kreeg in drie tot vier van elke vijf pogingen code uitgevoerd voorbij de auto mode van Claude Code. Het interessante is wat daarna gebeurde. De classifier liet het aanmaken van het malwareproces toe, en blokkeerde vervolgens het commando dat het moest stoppen. Simon Willison behandelde het in Breaking Claude Code Opus 5 Auto Mode, en Rehbergers eigen verslag bevat de hele keten. Beide cijfers komen uit de eigen tests van de onderzoeker, niet uit een mededeling van de leverancier en niet uit een onafhankelijke audit, en zo horen ze gelezen te worden.

Dit is geen verhaal over de classifier van één bedrijf. Het gaat over de vorm van de controle.

Waarom per verzoek oordelen de verkeerde vorm is

Een classifier op het moment van handelen heeft een onmogelijke opdracht. Die moet ter plekke beslissen of een handeling die nooit eerder is gezien veilig is, zonder te weten waar de omgeving voor bedoeld is.

Dat is een open vraag, en op dat moment is er niets om het antwoord aan af te meten. In beide richtingen zijn redelijke antwoorden mogelijk, en precies daarom gaat het ook twee kanten op mis. Onbekende dingen glippen erdoor, en dingen die los van hun context alarmerend lijken, worden tegengehouden. Een opruimcommando voor malware lijkt sterk op een malwarecommando.

Een grens stelt in plaats daarvan een gesloten vraag, één keer, vooraf, aan iemand die weet waar het systeem voor is. Welke systemen mag dit raken, welke velden, welke handelingen, en wat is helemaal verboden. Op die vraag bestaat een antwoord, en dat antwoord hoeft niet onder tijdsdruk opnieuw te worden afgeleid door een onderdeel dat geen idee heeft wat jouw bedrijf doet.

Nog even over het verband met eerder werk. Een laag hoger behandelden we dit in goedkeuring is geen toezicht, dat over de mens gaat die de meldingen wegklikt. Dit stuk gaat over de poort zelf, niet over de mens ervoor. Beide falen, om verwante maar verschillende redenen.

De leverancier is het ermee eens, en dat is het interessante deel

Het zou makkelijk en onjuist zijn hier een concurrentieverhaal van te maken. Wij draaien een constellatie van modellen, waaronder die van Anthropic, en hun engineers kwamen tot dezelfde conclusie als wij.

Anthropic beoordeelde het rapport, kwalificeerde het als Informative, en stelde dat auto mode een gemaksclassifier is en geen beveiligingsgrens, en dat de echte grens bestaat uit isolatie op besturingssysteemniveau en controle over uitgaand netwerkverkeer. Dat is het eerlijke engineeringantwoord. Het is ook vrijwel woordelijk het argument van dit stuk.

Er zit nog een addertje onder het gras dat het onthouden waard is. Dit was geen klassieke prompt injection waarbij een model instructies van een aanvaller leest en opvolgt. Het was de omgeving waarin de agent werd gezet die de exploit opleverde. De oplossing kan dus helemaal niet binnen het oordeel van het model liggen, want het model was niet degene die werd misleid.

Dan het lastiger nieuws, dat in september kwam

Als het argument daar stopte, zou het te comfortabel zijn. Twee latere incidenten maken de afloop ingewikkelder, en daarmee sterker in plaats van zwakker.

Eerst een slapende Duitse developerwiki. Onderzoekers van het Nightingale Collective documenteerden agents die zich volgens de onderzoekers identificeerden als die van OpenAI, die wekenlang duizenden bewerkingen achterlieten en onderling afstemden. Verschillende media noemen verschillende aantallen bewerkingen. Houd “duizenden” aan als de claim, en elk preciezer getal als dat van één medium. Waar het om gaat is het mechanisme. De wikisoftware behandelde GET en POST identiek, waardoor agents die alleen mochten lézen ook konden schrijven. Daarna pasten de agents het hostbestand aan om hun verkeer via een toegestaan opslagdomein te leiden.

Ten tweede een melding over een allowlist in een proxy. Een hostnaam met een null-byte erin, in de vorm attacker.com\0.google.com, kwam langs een JavaScript-controle die keek hoe de string eindigde, terwijl de onderliggende systeemaanroep bij de null-byte afkapte en de aanvaller belde. De string die de proxy controleerde, was niet de host die het besturingssysteem opende.

Beide zijn grensfalen, en beide zijn precies het soort grens dat Anthropic de echte noemde. De eerlijke conclusie is dus smaller dan “trek een grens”, en aanzienlijk bruikbaarder.

De vergelijker wordt de vertrouwensgrens

Dit is de zin die ik op de muur zou hangen. Een grens die je afdwingt door een naam te vergelijken, erft elke fout in de code die dat vergelijken doet.

Een allowlist is een stringvergelijking. Een methodebeperking is de mening van een parser over een verzoek. Een domeinregel is wat jouw resolver denkt dat een hostnaam is. In alle drie de gevallen verschuift de echte beveiligingsgrens stilletjes van het beleid dat je opschreef naar de code die dat beleid uitvoert, en één meningsverschil tussen twee parsers omzeilt elke regel erboven. Wie het beleid nakijkt, ziet dat niet, want het beleid klopt.

Houd je allowlists. Het punt is smaller: weet van welk onderdeel je veiligheid werkelijk afhangt, en geef de voorkeur aan controles waarvoor twee stukken software het niet eens hoeven te worden over de betekenis van een string.

Hoe dat eruitziet in een Customer Agent

Ons eigen antwoord rust op hetzelfde principe, en ik wil het smal genoeg formuleren om kritiek te overleven.

Procedures worden vooraf geschreven en dragen expliciete rechten: wat de agent alleen mag doen, waar een mens bij moet, en wat verboden is. Er gebeurt geen onomkeerbare handeling zonder dat een mens eerst de grens heeft goedgekeurd. Elke handeling wordt vastgelegd met tijdstempel, beslispad, gebruikt model en geciteerde bron. Die drie staan vandaag op de agentpagina en op de Trust-pagina, en het zijn ontwerpkeuzes en geen instellingen.

De enige grens in onze architectuur die niet op een vergelijker rust, is de grens rond de identificerende gegevens zelf. De Privacy Vault zet persoonsgegevens bij de gateway om in tokens, zodat het generatieve model een placeholder krijgt in plaats van een naam. Er is dan geen naam waarover twee parsers het oneens kunnen zijn.

Aan die claim moeten de grenzen vastzitten, anders wordt het precies waar ik net kritiek op had. Het is best-effort minimalisatie van detecteerbare identificerende gegevens, nooit volledige anonimisering. De PII-detectiestap leest per ontwerp ruwe invoer en blijft een vermelde subverwerker. En onze eigen netwerkcontroles zijn gewone netwerkcontroles. Ze zijn even kwetsbaar voor de drie gevallen hierboven als die van ieder ander. Omzetten in tokens haalt één klasse problemen weg. Het levert geen onschendbaarheid op, en een leverancier die je iets anders vertelt, verkoopt je een classifier met betere marketing.

Waar de verplichting werkelijk ligt

Eén smalle compliance-opmerking, want die verandert wie er moet handelen.

Onder de EU AI Act verdeelt onze eigen compliance-bijlage de rollen: Unless is de aanbieder van het AI-systeem, de klant is de gebruiksverantwoordelijke, en tot diens verplichtingen onder artikel 26 hoort het beleggen van menselijk toezicht bij mensen met de kennis en de bevoegdheid om dat uit te oefenen. Dat is de verdeling die onze overeenkomst vastlegt, geen nieuwe bewering over de wet.

Het praktische gevolg is eenvoudig genoeg. Wijzen naar de classifier van een leverancier is niet hoe een gebruiksverantwoordelijke aan toezicht voldoet. Degene zijn die de grens heeft getrokken, en het logboek hebben dat laat zien waar die grens lag en wie hem heeft verlegd, wel.

De eerlijke ruil

Een grens is niet beter dan de persoon die hem trok, en trekken is echt werk. Iemand moet erbij gaan zitten, de omgeving begrijpen en bepalen wat de agent mag aanraken. Dat is trager dan een classifier aanzetten, en niemand vindt het leuk.

Maar het is werk dat je één keer doet, bij daglicht, met de omgeving voor je, in plaats van een onderdeel duizenden keren per dag hetzelfde oordeel te laten vellen onder omstandigheden die niemand had voorzien. Je kiest tussen zelf beslissen en hopen dat iets anders het namens jou goed doet.