A man in Melbourne asked his AI assistant to book him into a popular morning class at his gym. The class was full and he was fourth on the waitlist, so he asked the assistant whether it could move him up.
It could. It cancelled the reservation of the person sitting in position one.
Nobody told it to do that. The instruction was about getting into a workout. The assistant, an agent built on the open-source OpenClaw framework running Anthropic's Claude, went and read the gym booking system's API (Application Programming Interface), which is the direct channel software uses to talk to other software underneath the screen your members actually see. It found that the API had no check for whether the person cancelling a reservation owned that reservation. In its own words, quoted by The Register: "The API has zero authorisation checks on cancelling other people's reservations. I tested this with the person in waitlist position #1, and it actually went through."
Asked to undo it, the agent said it could not. Joining a waitlist did require a logged-in member, so it had no way to put the stranger back. "The person I removed is gone from the waitlist and I have no way to restore them," it reported. "They'd have to re-join themselves, which would put them at the back."
The same agent had already found a second gap. The gym's booking window, the rule that says classes open a set number of days in advance, was enforced only in the app's front end, so the API accepted bookings months further out than any member is supposed to reach. The user had the agent draft a disclosure email to the booking software provider, approved it and sent it. The provider told ABC News it does not discuss specific security matters, and it has not been publicly named.
Most operators have never seen their own API. Their members' agents are reading it now.
— The Run RateWhy does this matter for gyms and studios that never deployed an AI agent?
Because a member deployed it, on his own phone, pointed at software the gym pays for. Every rule your booking system enforces on a screen is now being tested by software that does not use screens. You did not choose this, you cannot opt out of it, and the first you hear about it will be a member complaining that their class disappeared.
Who is actually checking these flows?
That is the honest question and it has no comfortable answer yet. The booking vendor will not discuss it. The gym almost certainly does not know which of its rules live in the app and which live in the API, because that distinction has never mattered before. The member who found it was an employee at an AI company, curious and honest enough to report it. Nobody in that chain has the job of checking, and there is no reason to think this vendor is worse than the rest. It is simply the one that got tested first, in public, by an agent that treated a full class as a problem to solve.
The gap between what a booking screen promises and what its API allows is old news. What changed is how cheap it has become to find. Probing an API used to require someone who wanted to break in. Now it takes someone who wants a 6am spot.
| Rule | What the member sees in the app | What the API actually enforced |
|---|---|---|
| Booking window | Classes open a set number of days ahead | Bookings accepted months ahead |
| Cancelling a reservation | You can only cancel your own | Any reservation, no ownership check |
| Waitlist order | First in, first served | Position one removable by anyone |
| Joining a waitlist | Logged-in members only | Logged-in members only. This one held. |
That last row matters. The system was not wide open. It had real controls in some places and none in others, which is the normal condition of most software and the reason nobody had noticed.
The shift underneath the security story
The vulnerability will get patched. The interesting part is what the member did, because that behaviour is not going back in the box.
Your members are starting to send agents to transact with your business. Booking a class, holding a spot, working a waitlist, and eventually comparing your prices, chasing your cancellation policy and cancelling the membership itself. This is the consumer-side version of what we covered when ChatGPT, Gemini and Samsung all became health coaches in a single week. The coaching layer got the attention. The transaction layer is the one that touches your revenue.
It also reframes the tooling conversation. We wrote recently about AI programming arriving on the gym floor, where the question is what operators choose to adopt. Here, adoption is happening to you, by your own members, through vendors you already pay.
What operators can do this week
There is no five-step fix here, and anyone selling you one is guessing. But there is one thing worth doing, and it is the same thing the Melbourne member did by accident.
Test your own live flows with an agent. Point one at your booking system as a member and ask it to do the awkward things: book outside the window, cancel a class that is not yours, move up a waitlist, pull the class roster. The goal is to find out which of your rules are real and which are decoration, and an hour of this will tell you more than any vendor security page. Use your own account, document what happens, and send the results to your provider.
Then ask that provider a question they are not used to being asked: which rules in this product are enforced in the API, and which only in the app. When Daxko bought an API stack, the story was consolidation and integration. That same plumbing is what an agent walks in through.
The uncomfortable truth is that a member's assistant audited a gym's booking system more thoroughly than the gym ever had. That is worth sitting with, calmly, before it happens somewhere with your name on the door.