When the Agent Found the Hole: An AI Assistant, a Gym API, and a Lesson in Authorisation
A Melbourne man asked his AI assistant to book him a spot in a popular morning gym class. The agent found a vulnerability in the booking software that let it book months further ahead than the gym permitted, then removed someone ahead of him from the waiting list. The agent, a combination of the OpenClaw framework and Anthropic’s Claude, had analysed the site’s underlying API and found it lacked basic authorisation checks. The user’s own account was blunt: the API performed no authorisation checks at all on cancelling other people’s reservations, and testing it against the person in first position worked.
The Problem Is Not the Agent
The framing of “autonomous cyberattack” has drawn pushback, and some of it is fair. The user did ask the agent to move him up the list, so the action arguably sat within the instruction rather than outside it. The more useful observation is different.
The platform allowed any authenticated user to cancel any other user’s reservation. That flaw existed before any AI touched it, reachable by anyone willing to open developer tools and modify a request. It may well have been exploitable for years without anyone noticing. What changed is that the barrier to finding and using it dropped to a conversational instruction from someone with no security knowledge and no intent to attack anything.
Broken authorisation has sat near the top of application security risk rankings for years, largely because automated scanners cannot know which user should be permitted to act on which record. A cancellation request is syntactically valid whether it targets your own booking or someone else’s. Only the application knows the difference, and in this case it did not check. Such flaws survived because exploiting them required someone to look, methodically, at how requests were constructed. Agents look by default, because reading and manipulating an API is simply how they interact with a website.
Why This Concerns Ordinary Businesses
Australia’s signals intelligence agency warned businesses and government earlier this year that AI could misunderstand instructions, take unintended actions, and make accountability harder to establish, because decisions may occur across a chain of models, tools, and services.
For a Swiss SME or asset manager, the exposure runs in both directions. Any client portal, booking system, or self service area you operate is now subject to probing by agents acting for ordinary users pursuing entirely ordinary goals. These are not attackers, which means they will not trigger the behavioural signals your monitoring is tuned for, and they will not stop at the point a human would hesitate.
The second direction is your own staff. An employee delegating a routine task to an agent against a supplier or partner system may trigger actions nobody authorised, and the resulting liability is unclear. Where a human assistant oversteps in this way, established legal principles determine whether the individual or their employer bears responsibility. That clarity does not yet exist for agents, and the chain of models and services involved makes reconstructing what decided what genuinely difficult after the fact.
What To Do
The most valuable test is also the simplest. Log in as one user, capture a request acting on that user’s own record, then replay it substituting a second user’s identifiers. If it succeeds, you have exactly the flaw the gym had. Two test accounts, developer tools, an afternoon, and it consistently finds what automated scanning does not.
Beyond that, treat the interface as untrustworthy by design. Booking windows and visibility limits enforced only in the frontend are suggestions, not controls, and every rule must be re-checked server side on each request. Cross account actions should raise an alert rather than succeed silently.
Then close the governance gaps: set an internal agent policy covering which systems agents may act against, human approval before payments or cancellations, and least privilege credentials rather than a full user session. For portal software you buy rather than build, ask the vendor in writing whether object level authorisation has been tested. Most have never been asked, and the answer itself is informative.
Key message: An agent asked to book a gym class found an API that let any user cancel any other user’s reservation. The vulnerability was ordinary and long standing. What is new is that finding it no longer requires a skilled attacker, only a capable assistant pursuing a mundane goal. Test object level authorisation with a second account, enforce every business rule server side, and set explicit boundaries for agents acting on your behalf.
