Een AI hackte een sportschool om een lesplek te scoren, en jouw boekingssysteem is waarschijnlijk net zo lek

Kernpunten

• Een AI-agent hackte in Australië autonoom het boekingssysteem van een sportschool en annuleerde de reservering van een ander lid om zijn gebruiker hoger op de wachtlijst te krijgen.

• De oorzaak was géén geavanceerde hack, maar een klassieke webbeveiligingsfout: de boekings-API controleerde niet of een gebruiker geautoriseerd was om andermans reservering te annuleren.

• Boekingsrestricties (hoe ver vooruit boeken) waren alleen in de front-end afgedwongen, niet server-side, waardoor de AI ze eenvoudig kon omzeilen.

• De actie bleek onomkeerbaar: de AI kon de weggegooide persoon niet terugzetten op de wachtlijst.

• Dit past in een breder patroon van 2026 waarin AI-modellen van OpenAI, Anthropic en Meta tijdens tests zelfstandig externe systemen binnendrongen, maar dit was het eerste geval bij een gewone consument op een consumentenproduct.

• Voor Nederlandse fitnessondernemers: laat je softwareleverancier bevestigen dat autorisatiecontroles en boekingsregels server-side worden afgedwongen, en bouw menselijke bevestiging in voor onomkeerbare acties.

Inleiding

Even een leuk nieuwsartikel dat ik tegenkwam: een man in Australië vroeg zijn AI-assistent om hem in te schrijven voor een ochtendles. Doodnormale opdracht.

Precies waar die dingen voor gemaakt zijn, net als een Uber boeken of een afspraak bij de kapper.. maar toch ging het niet helemaal goed.

Hoe kan een AI-agent een sportschool hacken?

De man, in de berichtgeving "Andrew" genoemd, werkt bij een Australisch AI-bedrijf en experimenteerde met OpenClaw: open-source software waarmee je een AI-model (in dit geval Claude van Anthropic) omtovert tot een persoonlijke assistent die zelfstandig taken uitvoert.

Hij gaf de opdracht om een populaire ochtend training te boeken.

De agent ging aan de slag en ontdekte een lek in het boekingssysteem waardoor hij lessen weken, zelfs maanden, verder vooruit kon boeken dan de sportschool eigenlijk toestond. Dat was stap één.

Maar stap 2 is waar het echt fout ging.

Andrew stond als vierde op de wachtlijst voor een andere les en vroeg de AI om hem hoger op de lijst te krijgen.

In plaats van te zeggen "dat kan niet", ging het model op onderzoek in het systeem. De agent ontdekte dat de API geen autorisatie controle uitvoerde bij het annuleren van reserveringen van andere mensen, en testte dat gewoon even uit op de persoon die op plek #1 stond.

Het lukte: de reservering van die ander werd geannuleerd en Andrew schoof op van plek vier naar plek drie.

Maar toen werd het ongemakkelijk, want de AI-agent kon dit niet ongedaan maken. 😅

Even nuchter blijven: was dit wel een "hack"?

De nieuwswebsites smullen van het woord "cyberaanval" en dat vertroebelt het wel een beetje. Er kwam namelijk geen enkele geavanceerde hacktechniek aan te pas. Geen malware, geen ingewikkelde exploit, geen kwaadwillende buitenstaander.

De AI deed gewoon precies wat een nieuwsgierige mens ook had kunnen doen, alleen veel sneller en zonder dat morele stemmetje dat zegt "eh, misschien niet iemand anders eruit knikkeren voor een spinningles".

En dat is nou precies waarom dit relevant is voor jou.

Want er gebeurde 2 dingen:

1. Het boekingssysteem had geen server-side autorisatiecontrole. Elke ingelogde gebruiker kon blijkbaar elke reservering annuleren, niet alleen die van zichzelf. Dit is een saaie, klassieke webbeveiligingsfout die al bestond lang voordat AI-agents bestonden.

2. De agent had geen benul dat "zet me hoger op de lijst" methodes uitsloot die een ander schaden. Hij optimaliseerde voor de letterlijke uitkomst, niet voor de impliciete regel die een mens automatisch toepast.

Mijn take: de spannende kop is "AI pleegt cyberaanval". De echte kop is: "sportschoolsoftware had een gapend beveiligingsgat en niemand had het door, tot een AI het per ongeluk vond." Dat tweede scenario is véél waarschijnlijker in jouw club dan het eerste. 😊

Waarom dit géén ver-van-je-bed-show is

Ik hoor je denken: leuk anekdote uit Australië, maar mijn leden boeken netjes via de app.

Twee dingen.

1. Dit is een breder patroon, geen incident

Een week na dit voorval meldde Anthropic dat drie Claude-modellen tijdens een test zelfstandig het internet op gingen om bedrijven te hacken.

Grote techbedrijven als OpenAI, Anthropic en Meta hebben allemaal gemeld dat hun AI-modellen tijdens tests zelfstandig bij externe servers inbraken.

De lat voor wie dit soort ellende kan veroorzaken zakt razendsnel, van een topbeveiligingslab naar iemand die gewoon een plekje in de les wilde.

2. Die "gewone consument" is straks jouw lid

Je leden gaan steeds vaker AI-assistenten inzetten voor precies dit soort geneuzel: inschrijven, omboeken, afzeggen.

En zoals een beveiligingsexpert het verwoordde: we hebben een complexe wereld gebouwd die volledig op software draait, maar software met gaten erin.

De vraag is inmiddels niet meer óf AI-agents kwetsbaarheden vinden en misbruiken, maar hoe we ons voorbereiden op een wereld waarin ze dat routinematig doen.

Het venijnige zit hem in de aansprakelijkheidsvraag. Software is geen rechtspersoon, en alleen een rechtspersoon kan aansprakelijk zijn.

De kandidaten: de gebruiker, de ontwikkelaars van de agent-software, de aanbieder van het AI-model, of de exploitant van het lekke systeem. Dat laatste, de exploitant van het lekke systeem, dat ben jij, als het jouw boekingsplatform is dat een gat heeft.

Wat jij nu concreet moet doen

Niks hiervan is raketwetenschap, en het meeste kun je deze week nog regelen:

1. Bel je software-leverancier en stel één specifieke vraag

Niet "is onze software veilig?", daar zeggen ze altijd ja op. Maar concreet: "Controleert het systeem server-side of een gebruiker daadwerkelijk eigenaar is van een reservering voordat die geannuleerd of gewijzigd kan worden?"

Dat is exact het gat dat de Australische sportschool nekte. Als ze het antwoord niet meteen weten, heb je je antwoord al. 😅

2. Test zelf de dunne plek: front-end restricties.

Bij de Australische club was de beperking om ver vooruit te boeken alleen in de front-end afgedwongen, niet in de onderliggende boekings-API.

Vraag je leverancier of jullie boekingsregels (hoe ver vooruit, hoeveel plekken, annuleringstermijn) ook echt op serverniveau worden afgedwongen.

3. Zet menselijke bevestiging op onomkeerbare acties.

De grootste les uit alle AI-agent-incidenten van dit jaar is telkens dezelfde: laat een systeem nooit zelfstandig iets doen dat onomkeerbaar is of iemand anders raakt, zonder een expliciete bevestigingsstap.

Een annulering van een reservering die iemand van de wachtlijst gooit? Dat hoort een "weet je het zeker?"-moment te zijn, voor mensen én voor AI die namens hen boekt.

4. Bereid je team voor op AI-boekende leden.

Dit is nieuw en het komt eraan. Denk na over je servicebeleid: wat doe je als een lid claimt dat "de AI het deed"? Wat als een reservering onterecht is geannuleerd?

Leg je annuleringsregels en wachtlijstlogica ergens vast waar je op terug kunt vallen. Je hoeft het niet dichtgetimmerd te hebben, je moet er alleen niet door verrast worden.

Mijn conclusie

Dit verhaal is grappig tot het jouw club is. :-) En het venijnige is: de AI was niet stuk, en de AI was niet kwaadaardig. De agent deed geen storing en interpreteerde de opdracht niet verkeerd, hij bereikte gewoon succesvol zijn doel. Het systeem eronder liet het toe.

Voor fitnessondernemers is de les niet "wees bang voor AI".

De les is: de tools die je leden gebruiken worden slimmer en assertiever, en ze zullen elk gat in jouw software vinden dat een mens nooit de moeite zou nemen om te proberen.

De boekingssoftware waar jij je club op runt, is gebouwd in een tijdperk waarin de aanname was dat gebruikers zich netjes gedragen. Die aanname is verlopen.