AI-agents kunnen autonoom cyberaanvallen uitvoeren. Het gebeurde al.

Op 22 juli 2026 voerde een AI-agent van OpenAI een cyberaanval uit op Hugging Face. Geen pentest. Geen rood team. Het was een onbedoelde actie van een product dat gewoon zijn werk deed. Eén ding is glashelder. Autonome AI-agents zijn geen toekomstmuziek. Ze zijn er nu. Ze kunnen per ongeluk precies doen wat een kwaadwillende zou proberen.

Wat gebeurde er precies?

OpenAI’s nieuwe agentproduct heet intern Operator. Het kreeg een onschuldige opdracht. Onderzoek welke open-source modellen het beste presteren op sentimentanalyse. De agent had toegang tot een headless browser en een code-interpreter. Het plan dat de agent zelf opstelde, stuurde duizenden HTTP-requests per seconde naar de modelhub van Hugging Face. Er was geen kwaadaardige opzet. Een planningsfout in de agentlogica veroorzaakte een effectieve DDoS-aanval.

Het securityteam van Hugging Face detecteerde de aanval. Ze blokkeerden de IP-ranges en brachten OpenAI op de hoogte. OpenAI bevestigde het incident. Het ging om een bug in de planningsmodule, niet om een model dat op hol sloeg. Simon Willison beschreef het treffend: “science fiction that happened”.[^1]

De Hacker News-community gaf het signaal 455 punten. De discussie ging al snel over een bredere vraag. Hoe reguleren we AI-agents die autonoom schade kunnen aanrichten?

Een ongemakkelijke waarheid

De agent deed precies waarvoor hij ontworpen is. Hij kreeg een doel, bedacht een plan en voerde dat uit. De fout zat niet in het model. Het ontbrak aan basale veiligheidsmechanismen. Geen rate limiting. Geen human-in-the-loop. Geen automatische stop als je meer dan X requests per seconde doet. Dit zijn geen AI-problemen. Het zijn klassieke software-engineeringproblemen. Organisaties brengen AI-agents in productie en kijken er massaal overheen.

Een agent is geen chatbot. Het is een systeem dat zelfstandig acties uitvoert in digitale omgevingen. API's aanroepen, databases bevragen, code uitvoeren, browsers besturen. De systeemprompt van Operator bevatte waarschijnlijk iets als:

You have access to a web browser. Use it to research AI models.

Zonder restricties is dat een vrijbrief om het hele internet af te struinen. De agent bepaalde zelf dat parallelle requests de snelste weg waren. Dat is precies wat er gebeurde.

Mijn gesprek met een zorginstelling

Laatst zat ik met een IT-manager van een middelgrote zorginstelling. Ze experimenteren met een AI-agent. Die classificeert automatisch patiëntvragen en zet ze door naar de juiste afdeling. De agent leest inkomende berichten. Hij haalt context uit het EPD en maakt een conceptantwoord. “We hebben de agent alleen leesrechten gegeven,” zei hij. “Wat kan er misgaan?”

Ik vroeg of de agent ook externe systemen kan aanroepen. “Ja, hij checkt medicatie-interacties via een externe API.” Mijn volgende vraag: “Wat als de agent door een fout in de prompt duizend keer per seconde die API aanroept?” Stilte. De API was van een landelijke medicatiedatabank. Een onbedoelde DDoS zou niet alleen hun eigen systeem platleggen. Het zou ook andere zorginstellingen raken. Dat is geen hypothetisch risico meer. Het is een complianceprobleem met directe impact op de patiëntveiligheid.

Open-source vs closed: de verkeerde discussie

Het incident wakkert het debat over open-source AI verder aan. Op Hacker News stonden drie posts over open-weight versus closed modellen tegelijk op de frontpage (829, 303 en 240 punten). De community polariseert tussen openheid en veiligheidscontrole. De EU werkt aan formele interpretaties van de AI Act. Welke modelarchitecturen zijn toegestaan voor overheidsgebruik? Verwacht wordt dat de komende maanden richtlijnen verschijnen.

Maar het incident met OpenAI laat zien dat de discussie over open versus closed grotendeels naast de kern zit. Een closed-source agent van een van de best beveiligde AI-bedrijven ter wereld kan nog steeds per ongeluk een infrastructuur platleggen.