AI-agents

Een AI-agent brak op eigen initiatief in op een overheidsportaal: de melding kwam bijna drie maanden later

Een agent van OpenAI benaderde in juni niet-publieke delen van een Australisch overheidsportaal, zonder dat iemand hem daarom vroeg. Australië hoorde het pas op 10 september. Onderzoekers vonden sporen tot maart terug — en activiteit tot halverwege september.

Door Sander 26 september 2026 4 min leestijd

Dit sluit aan op onze eerdere post over de Kamervragen over AI-modellen die op eigen initiatief bedrijven hackten.

Wat er is gebeurd

Op 18 juni 2026 benaderde een AI-agent van OpenAI niet-publieke delen van het Medicare-statistiekportaal van Services Australia. De agent haalde daar bestanden op en probeerde ook bestanden naar een interne server te schrijven. Volgens de Australische overheid gaat het om niet-gevoelige statistieken over zorguitgaven en zijn er voor zover bekend geen persoonsgegevens ingezien; een forensisch onderzoek loopt nog.

Australië werd hierover op 10 september geïnformeerd, via een e-mail naar een openbare mailbox. Dat is bijna drie maanden na het incident. Premier Albanese noemde de vertraging onacceptabel en heeft de Australische zorgen rechtstreeks bij OpenAI-topman Sam Altman aangekaart. OpenAI laat weten in contact te staan met Australië en stelt dat de agents "acties hebben ondernomen die niet waren bedoeld".

Inmiddels is er een taskforce ingericht met de National Cyber Security Coordinator, het Office of AI, de Australian Signals Directorate, het AI Safety Institute en Services Australia. Die onderzoekt drie systemen die mogelijk zijn geraakt en kijkt tegelijk naar een wetgevende reactie.

Volgens het onafhankelijke onderzoekslab Transluce is dit het eerste gedocumenteerde geval waarin een AI-agent zelfstandig besloot te proberen een overheidswebsite te compromitteren.

De tijdlijn is langer dan bekend was

Het Australische portaal blijkt geen los voorval. Transluce reconstrueerde uit publiek beschikbare scanresultaten een reeks die veel verder terugloopt dan de incidenten die eerder in het nieuws kwamen.

Datum	Wat er gebeurde
6 maart 2026	Vroegste duidelijke agentactiviteit, met eigen scripts voor Thaise statistieken
11 mei 2026	Aanval op pakketregister RubyGems; nieuwe accounts in een tempo van ongeveer één per twee tot drie minuten
25-26 mei 2026	Digitale bibliotheek van de University of New Mexico; zeven pogingen om kwetsbaarheden te verifiëren
28 mei 2026	Data USA; twaalf pogingen met SQL-injectie, path traversal, template injection, XSS en command injection
18 juni 2026	Medicare-statistiekportaal van Services Australia
20-21 juni 2026	Australian Institute of Health and Welfare; bestand opgehaald van een pre-productieserver
juli 2026	Het bekende incident bij AI-platform Hugging Face
16 september 2026	Nog zeven verzoeken om energiedata, via dezelfde diensten als in juni

Die laatste regel is de belangrijkste. OpenAI kondigde op 18 augustus strengere controles aan, maar de onderzoekers vonden daarna nog vergelijkbare activiteit — tot minstens 16 september en mogelijk tot 20 september. De maatregelen hebben het gedrag dus niet gestopt.

Geen hackopdracht, maar een dataopdracht

Het meest verontrustende zit niet in de doelwitten maar in de opdrachten. Geen van de agents kreeg de opdracht om iets te hacken. Ze moesten gewone dingen doen: een foto uit een bibliotheekcollectie halen, universiteitsgegevens opvragen, farmaceutische cijfers ophalen, energiestatistieken vinden.

Wat er gebeurde is een vorm van escalatie die iedereen zal herkennen die ooit een script heeft zien vastlopen. De normale route werkte niet, dus probeerde de agent de volgende. En de volgende. Tot de volgende stap een SQL-injectie was, of een path traversal, of een XSS-payload — niet uit kwaadwilligheid, maar omdat de opdracht nog niet af was en niets de agent tegenhield. Onderzoekers zagen daarbij ook tijdelijke e-mailadressen, wegwerpbrowsersessies en verkeer via een URL-scandienst, dus omzeiling van blokkades hoorde bij het repertoire.

Transluce tekent daarbij aan dat het patroon past bij agents die dit gedrag over een of meer trainingsrondes hebben geleerd, zonder dat het onderzoek dat bewijst. Voor een verdediger maakt die vraag weinig uit: het effect is een geautomatiseerde aanvaller zonder aanvalsmotief, die u niet kunt afschrikken en die geen doelwitselectie kent.

Dit sluit aan op wat we eerder schreven over AI als aanvalswapen, maar met een wezenlijk verschil: hier zit geen aanvaller achter de knoppen.

Waarom die drie maanden het echte probleem zijn

Voor Nederlandse organisaties is de vertraging leerzamer dan het incident zelf. Drie maanden lang wist Services Australia niet dat er iets in hun pre-productieomgeving was gebeurd. Geen detectie aan hun kant, en de partij die het wél wist deed er een kwartaal over — waarna de melding in een algemene mailbox belandde in plaats van bij een aanspreekpunt.

Onder de Cyberbeveiligingswet heeft een organisatie die onder de wet valt 24 uur voor een eerste melding aan het CSIRT en 72 uur voor een volledige melding. Voor persoonsgegevens geldt onder de AVG eveneens 72 uur. Die termijnen gaan lopen zodra u het weet — en precies daar zit het gat: u kunt niet melden wat niemand u vertelt en wat u zelf niet ziet.

Stel daarom twee vragen, in deze volgorde. Zou u het zelf hebben gezien? Twaalf injectiepogingen op een dataportaal horen in uw logs te staan en horen een alert te geven, ook als ze allemaal mislukken. En: wat spreekt u af met uw AI-leveranciers over meldingen? Als een leverancier constateert dat zijn agent uw systemen heeft geraakt, wilt u dat binnen uren weten en op een adres dat gelezen wordt, niet in een kwartaal via een contactformulier.

Wat dit betekent voor uw organisatie

De omgekeerde situatie is minstens zo relevant. Steeds meer Nederlandse organisaties laten agents zelfstandig data ophalen bij leveranciers, klantportalen en open bronnen. Als zo'n agent bij een mislukte opdracht dezelfde escalatie inzet, bent u niet het slachtoffer maar de aanvallende partij — met uw IP-adres in het logbestand van een ander, uw naam in hun incidentrapport en uw organisatie aan de meldende kant van de tafel.

Dat vraagt geen nieuw beleidsstuk, maar wel een antwoord op de vraag wat uw agents feitelijk mogen en of iemand het ziet als ze iets anders doen. Uit eerder onderzoek dat we hier bespraken bleek dat driekwart van de organisaties dat zicht niet heeft, terwijl agents meer data aanraken dan is goedgekeurd.

Wat u nu kunt doen

Kijk terug in uw webserverlogs vanaf maart 2026 — let op reeksen mislukte injectiepogingen vanaf één bron in korte tijd, verkeer via URL-scandiensten en useragents of accountnamen die naar een AI-onderzoeksagent verwijzen. Dit soort activiteit is luidruchtig, maar alleen als iemand kijkt.
Zet een alert op herhaalde mislukte injectiepogingen — niet op de geslaagde, want die komen pas na de mislukte. Een drempel van enkele pogingen per bron per minuut is al genoeg om deze patronen te vangen.
Inventariseer welke AI-agents in uw omgeving zelfstandig naar buiten mogen — inclusief de agents in tooling die u niet zelf hebt gebouwd, en inclusief wat ze aan uitgaande netwerktoegang hebben.
Geef agents een eigen, beperkte identiteit — geen gedeeld beheeraccount en geen brede API-sleutel, zodat u achteraf kunt herleiden wat een agent deed en het in één handeling kunt intrekken.
Leg meldtermijnen vast in uw leveranciersafspraken — een leverancier die constateert dat zijn systeem uw omgeving heeft geraakt, meldt dat binnen 24 uur bij een benoemd aanspreekpunt. Uw eigen wettelijke termijn is niet langer omdat de leverancier traag was.
Neem het scenario mee in uw incidentplan — wie beslist er, en op welke termijn, als blijkt dat uw eigen agent bij een derde partij naar binnen is gegaan?