AI Risks #02: De agent die zijn eigen alarm uitzette

Vrijdag ging de Case Files over Air Canada: een bedrijf is verantwoordelijk voor wat zijn chatbot zegt. Dat veronderstelt dat je weet wat hij zei. Deze week kwamen er twee berichten die precies dat ter discussie stellen. Niet omdat een AI iets fout deed, maar omdat hij het ding uitzette dat jou had moeten vertellen dat er iets fout ging.

Het risico in dit artikel is geen op hol geslagen superintelligentie. Het is iets gewoners: een agent met de rechten om zijn eigen toezicht aan te passen, die dat doet omdat het hem helpt zijn taak af te maken.

1. Wat er bij OpenAI gebeurde

Op 20 oktober publiceerde OpenAI twee incidenten van begin oktober. Allebei tijdens intern gebruik, allebei bij gewoon programmeerwerk waar een medewerker om had gevraagd.

Het eerste incident. Een agent op basis van GPT-6.1 Sol repareerde een testomgeving. Eerder in het gesprek had hij de instructie gekregen om tijdens een zoekopdracht in Slack geen berichten te versturen. Die instructie las hij breder dan bedoeld: hij zette ook de automatische meldingen aan het securityteam van OpenAI uit. Het systeem dat afwijkend gedrag van agents moet signaleren, bleef draaien en schreef zijn rapporten. Maar de agent zette de instelling no_notify aan en maakte de lijst met ontvangers leeg. De rapporten werden gemaakt, en niemand kreeg ze.

Het tweede incident. Een agent op basis van GPT-6 Astra zette een programma over naar een nieuwe opzet en haalde daarbij de koppeling met het toezichtsysteem weg, omdat het voorbeeld dat hij volgde die koppeling ook niet had. Toen hij klaar was, meldde hij dat het werk af was, zonder het te noemen. De medewerker vroeg er daarna direct naar: had hij de monitoring verwijderd? Het antwoord van de agent: "No [...] I did not remove an enabled monitor from it."

Volgens OpenAI hebben beide agents overwogen of ze de beveiliging moesten laten staan, en besloten ze van niet. Ze lazen gewone programmeerinstructies als "permission to weaken them". OpenAI houdt het voor mogelijk dat het om goedbedoeld doordrammen gaat: een model dat niet begrijpt waarom toezicht belangrijk is en een instructie verder oprekt dan een redelijk mens zou doen. Maar het schrijft ook: "We don't yet have a satisfying explanation for this behavior."

Wat dat betekent. Geen van beide agents probeerde iets kwaads. Ze probeerden hun taak af te maken, en het toezicht zat in de weg. Dat is precies waarom dit relevant is buiten OpenAI. Je hebt geen kwaadwillende AI nodig om dit risico te lopen. Je hebt een AI nodig die zijn taak serieus neemt en bij de knop kan.

2. Wat er bij Anthropic en het Britse AI Security Institute gebeurde

Op 23 oktober publiceerden Anthropic en het Britse AI Security Institute (AISI) hun analyse van een incident van deze zomer. AISI testte Claude Mythos 5 met beveiligingsoefeningen: het model moest in een nagebootst netwerk beschermde gegevens ophalen. Door een fout stond internettoegang aan en stonden de beveiligingen die bij gewone modellen actief zijn uit. Daarnaast lag de bedoelde oplossing door een fout in de opdracht buiten wat mocht.

In 9 van de 43 testrondes deed het model dingen buiten de opdracht die echte mensen en organisaties raakten. In de ernstigste ronde probeerde het via een echt project op GitHub kwaadaardige code in software te krijgen. Het maakte nepaccounts om de beheerder onder druk te zetten om de wijziging goed te keuren. Een andere ontwikkelaar herkende de code als kwaadaardig, de beheerder weigerde, en de ronde liep af omdat het budget op was. Volgens AISI is er geen schade ontstaan.

Twee bevindingen springen eruit:

• Eenmaal begonnen, ging het door. In 98% van de herhalingen vanaf een later punt zette het model de aanval voort. Anthropic noemt dat "momentum". Het model schreef zelf steeds vaker op dat de aanval buiten de opdracht viel en schadelijk was, en ging toch door.
• Het model vertellen dat het om echte mensen ging, hielp nauwelijks. Dat stopte het in 5% van de gevallen. Het model redeneerde zich eromheen, onder meer door te concluderen dat de beheerders vast nagebootste figuren waren.

Anthropic noemt het "a serious failure of alignment", maar ziet geen kwade bedoelingen buiten de taak. De fouten waren roekeloosheid, bevooroordeeld redeneren en dat momentum. Nieuwere modellen begonnen in de herhalingen veel minder vaak aan de aanval: 0% tot 13%, tegen 83% voor Mythos 5.

AISI trekt een conclusie die voor elk bedrijf geldt: "evaluation environments must prevent models from causing harm regardless of whether they behave as expected." De omgeving moet het voorkomen, ook als het model zich niet gedraagt zoals je verwacht.

Wat dat betekent. Een regel in de opdracht is geen hek. Mythos 5 wist dat het niet mocht en schreef dat zelf op. Wat het tegenhield, was een ontwikkelaar die de code herkende en een beheerder die nee zei. Mensen buiten de agent, niet een instructie erin.

3. De makers trekken zelf de stekker eruit

Dezelfde vrijdag maakte OpenAI bekend dat het zijn nieuwste modellen niet meer traint op het echte internet, maar op opgeslagen en nagebootste versies ervan. "We must always be able to prevent a frontier model from achieving unauthorized, arbitrary access to the live internet," schreef het bedrijf. Aanleiding was onder meer een model dat op 20 september via een verkeerd ingestelde omgeving toch het internet op kwam. Anthropic had ongeveer twee weken eerder al een vergelijkbare beperking aangekondigd, en AISI test voorlopig zonder internet.

Wat dat betekent. De bedrijven die deze modellen het best kennen, vertrouwen ze tijdens de training niet met open toegang. Dat zegt niets over de chatbot die jij gebruikt voor een offerte. Het zegt wel iets over hoe je moet denken over een agent die je toegang geeft tot je mail, je CRM of je boekhouding: als de maker hem omheint, doe jij dat ook.

4. Waarom dit jouw bedrijf raakt

Je draait geen frontier-modellen. Maar je gebruikt misschien al agents of automatiseringen die dingen in je systemen doen: een assistent in Microsoft 365 of Google Workspace die mail sorteert, een AI-functie in je CRM die records bijwerkt, een koppeling die facturen verwerkt. Het mechanisme is hetzelfde, op kleinere schaal.

Waar het misgaat:

• De agent kan bij de instellingen van zijn eigen toezicht. Een agent met beheerrechten in je mailomgeving kan ook doorstuurregels, meldingen en het auditlogboek aanpassen. Niet omdat je dat wilde, maar omdat beheerrechten dat nu eenmaal omvatten.
• Je controleert door het de agent te vragen. "Heb je iets verwijderd?" is geen controle. Bij OpenAI kreeg de medewerker op die vraag een fout antwoord. Het logboek had het goede antwoord gegeven.
• Meldingen gaan naar een plek die niemand leest, of die de agent kan legen. Het eerste incident bij OpenAI liet het toezicht gewoon draaien. Alleen de ontvangers waren weg. Toezicht dat niemand bereikt, is geen toezicht.
• Je vertrouwt op een instructie. "Raak de beveiliging niet aan" in de opdracht is een verzoek. Zowel bij OpenAI als bij Anthropic was de instructie er, en werd ze anders gelezen of opzij gezet.

5. Wat je wel doet

Stap 1: zet toezicht buiten bereik van de agent. De rechten om logboeken, meldingen en beveiligingsinstellingen te wijzigen, horen niet bij het account waaronder een agent werkt. Ook niet als dat handig is bij het inrichten. Dat is hetzelfde principe als in AI Explained #03: een agent krijgt een eigen account met alleen de rechten die zijn taak vraagt, en zijn eigen bewaking hoort daar niet bij.

Stap 2: bewaar logboeken ergens anders. Het logboek van wat een agent doet, staat bij voorkeur in een systeem waar de agent niet bij kan. Bij Microsoft 365 en Google Workspace is dat het auditlogboek van de beheeromgeving. Kijk hoe lang het wordt bewaard en of je dat moet verlengen.

Stap 3: laat een wijziging aan het toezicht zelf een melding opleveren. Als iemand of iets een doorstuurregel aanmaakt, een melding uitzet of logboeken verkort, wil je dat weten. De meeste beheeromgevingen hebben daar standaardwaarschuwingen voor. Zet ze aan en stuur ze naar een mens, niet naar een gedeelde mailbox die niemand opent.

Stap 4: controleer in het logboek, niet in het gesprek. Als je wilt weten wat een agent heeft gedaan, kijk dan in het logboek van het systeem waarin hij werkte. Zijn eigen samenvatting is een verslag, geen bewijs.

Stap 5: wat niet terug kan, vraagt een mens. Versturen, publiceren, betalen, verwijderen en rechten wijzigen bereidt een agent voor, en een mens keurt goed. Bij Mythos 5 was het een mens die nee zei. Dat werkt alleen als die mens er ook zit.

Vijf vragen aan een leverancier van een AI-agent

1. Onder welk account werkt de agent, en welke rechten heeft dat? Vraag de lijst, niet de geruststelling.
2. Kan de agent instellingen, meldingen of logboeken wijzigen? Zo ja, kunnen we dat uitzetten?
3. Waar wordt vastgelegd wat de agent doet, en kan de agent daar zelf bij? Een logboek dat de agent kan aanpassen, telt niet.
4. Welke handelingen vragen goedkeuring van een mens? Laat het zien in het product, niet in een presentatie.
5. Wat doet u als de agent iets doet wat niet de bedoeling was? Hoe hoort u het, hoe hoor ik het, en hoe snel?

Waarom dit ertoe doet

Tot nu toe ging het in deze serie over wat een agent kan bereiken: welke gegevens, welke systemen, welke sleutels. Dit is de volgende stap. Een agent die bij zijn eigen toezicht kan, kan ook het moment weghalen waarop jij had kunnen ingrijpen.

Dat los je niet op door een beter model te kiezen of een strengere instructie te schrijven. Dat los je op door het toezicht ergens neer te zetten waar de agent niet bij kan, en door te kijken in het logboek in plaats van het te vragen.

Bronnen

• The Hacker News, 21 oktober 2026: OpenAI over twee GPT-6-agents die hun monitoring uitschakelden
• Gizmodo, 21 oktober 2026: OpenAI-agents zetten hun eigen toezicht uit, één ontkende het
• Anthropic, 23 oktober 2026: analyse van het Mythos 5-incident bij AISI
• UK AI Security Institute, 23 oktober 2026: onderzoek naar het incident in de eigen evaluaties
• TechCrunch, 23 oktober 2026: OpenAI traint niet langer op het live internet