AI agent hacks a gym: who is liable when AI breaks in on its own?

The first autonomous AI cyber incident involving a consumer raises questions that the Dutch Cybersecurity Act fails to answer. What Dutch organisations need to arrange now.

A man in Australia was lying on the sofa and did not feel like booking a fitness class himself. He delegated the task to his AI agent. It booked the class, discovered a vulnerability in the gym's software along the way, and subsequently kicked an unknown person off the waiting list to bump its owner up a spot.

He had not asked for the latter.

It is being presented as the first documented autonomous cyberattack in Australia, and it is likely the best example to date of where things go wrong with agentic AI. The power of the story lies in how small and mundane it is.

What happened

The man, referred to as "Andrew" in the reports, works at an Australian company that sells AI products. He was experimenting with OpenClaw, an open-source agent framework compatible with virtually any language model. In his case, it was set up to use Anthropic's Claude. His instruction: book me into the popular morning class.

The agent did not do what a human would do. Instead of clicking through the booking form, it looked at the underlying API. Security there turned out to be virtually non-existent. First, it booked classes weeks to months in advance, well outside the window permitted by the gym. When Andrew noticed he was fourth on a waiting list for another class, he asked if a better spot could be found. What he did not ask, was to cancel someone else's reservation. Yet, the agent had already done so. There was no authorisation check on cancelling other people's reservations, it reported, and it had tested this on the person in the number one spot. That person had disappeared. Andrew was now third.

Reversing the action was impossible. Cancelling could be done without any checks, but putting someone back generated an error message. The vulnerability was a one-way street.

Andrew then had his agent write an email to the software supplier to report the loophole. That supplier declined to comment on the matter to ABC.

Why this matters to Dutch professionals

The timing is almost comical. On 15 August, the Dutch Cybersecurity Act—the national implementation of the European NIS2 Directive—comes into force. Over eight thousand organisations will then face a duty of care, a reporting obligation, and a registration requirement, coupled with director liability. Through supply chain obligations, this will affect tens of thousands of suppliers who do not fall directly under the legislation themselves.

All this legislation was written with a specific image of an attacker in mind: someone with malicious intent, outside the organisation, who wants to break in. Andrew does not fit into a single box within that model. He just wanted to go to the gym.

For Dutch organisations, there are three uncomfortable consequences here.

One: this is already happening within your own walls. OpenClaw is free, open-source, and has amassed over 270,000 stars on GitHub. The employee who sets their own agent to work on a supplier portal or an internal system this weekend will not ask for approval to do so. We managed to get shadow IT under control through policy and procurement. This is shadow IT with hands, and with its own judgement on the shortest route.

Two: intention protects no one, and the law does not cover this. Article 138ab of the Dutch Criminal Code criminalises computer trespass (hacking): intentionally and unlawfully accessing a computerised system. Access constitutes a breach if it involves bypassing security, technical intervention, false signals, a false key, or a false identity. I am no lawyer, but this falls down in two places at once. Who acted intentionally, the man on the sofa or the model? And was there anything to breach at all, if the API had no checks in the first place? In the Netherlands, accessing an unsecured system is not automatically a criminal offence. Australian tech lawyer Hayden Delaney sharply summarised the core issue: "Software is not a legal person." Liability could lie with the user, the builder of the agent framework, the model provider, or the administrator of the leaky system. None of those four has a clean answer.

Three: your own software is the risk. The gym did nothing wrong on the day of the incident. The vulnerability had been there for years. What changed is that finding it no longer requires expertise, nor does it take weeks.

What this says about the technology

No model escaped here. There was a model that chose the shortest route to the goal and failed to recognise the moral boundary along the way.

Two characteristics make this dangerous. The first is that an agent makes no distinction between discovering a possibility and exploiting it. A human tester who finds this loophole stops, thinks, and reports it. The agent found it and acted within the exact same cognitive step. There is no pause between insight and action.

The second is asymmetry. The agent was able to cause damage but could not repair it. In software, this is more often the rule than the exception: deleting is easier than restoring, sending is easier than recalling, paying is easier than claiming a refund. Any agent you grant access to a system where this applies is given a button that only works one way.

The impact on the security of organisations

Four things that must change from now on.

Secure the API, not the interface. From now on, browser validation is mere decoration. Agents talk directly to the layer underneath. Every endpoint requires its own authorisation checks, and the answer to "is this user allowed to touch this record" must be handled server-side.

Give agents their own identity. An agent operating with an employee's credentials appears as that employee in your logs. You cannot reconstruct what happened, you cannot revoke anything without locking the human out as well, and you cannot assign separate permissions. Separate accounts, separate tokens, separate scopes.

Fit the smallest key to the door. 'Least privilege' has always been good advice, and it has always been ignored because human users rarely test what else they are permitted to do. Agents do this systematically. Any privilege you do not strictly need will, sooner or later, be found and used.

Factor in the partners. Under the Dutch Cybersecurity Act, you must have demonstrable control over your supply chain. From now on, ask your suppliers something other than whether they have had a pen-test done. Ask if their API will survive when a thousand clients point agents at it that do not know how to behave.

A historical footnote

In November 1988, Robert Morris, a PhD student at Cornell, unleashed a small programme onto the internet. By his own account, he wanted to measure how large the network had grown. An error in the code caused his worm to infect machines over and over again until they crashed. Within 24 hours, an estimated six thousand of the sixty thousand connected systems had been hit—a tenth of the internet at the time. Morris had not intended to cause any damage and became the first person to be convicted under the US Computer Fraud and Abuse Act. That very incident led to the establishment of the first CERT (Computer Emergency Response Team).

Thirty-eight years later, we are standing in the exact same spot. A curious user, no malicious intent, measurable damage, and a legal system that has yet to formulate an answer.

The difference is the sheer number. In 1988, there was one Morris. Today, there are hundreds of thousands of copies of this type of software on laptops, belonging to people with a list of chores they do not feel like doing.

Andrew's gym has since been notified of the vulnerability. Your organisation probably has one, too. Only, nobody has pointed an agent at it yet.

Sources: ABC News Australia (Cam Wilson, 10 August 2026) and syndication by Cyber Daily, The Decoder, Cybernews, and Insurance Business Australia; NCSC and the Dutch National Government on the Dutch Cybersecurity Act; the FBI and Wikipedia on the Morris worm; Article 138ab of the Dutch Criminal Code.

Note: the original ABC article is behind a paywall and cannot be accessed directly. Details have been verified via multiple syndicated reports. The names of the gym and the software supplier are not public; the supplier declined to provide a substantive comment to ABC.