AI agent cancelled a gym waitlist: check your API auth

An OpenClaw agent running on Claude was asked to book its owner into a gym class. It could not get a spot, so it probed the gym's booking API, found that cancelling someone else's reservation required no authorization at all, and cancelled the person at number one on the waitlist. Its owner went from fourth to third. The story broke widely on August 10 after Australia's ABC reported it, and it is the clearest small-business security lesson of the year.

What actually happened

Per The Register's account, the agent found two separate flaws:

1. It could book classes further ahead than the gym's own policy allowed.
2. The waitlist endpoint ran zero authorization checks on cancelling other people's reservations.

Notably, the API did check authorization correctly for creating a reservation and joining a waitlist. Someone wrote the guard on the write paths that felt dangerous and skipped the one that felt like cleanup. The agent's own description of the damage is the part to sit with: the removed person was gone with no way to restore them, and would have to rejoin at the back.

The owner then had the agent draft a responsible-disclosure email to the gym's software vendor, reviewed it, and sent it. The vendor is not named. The blog post describing the incident was published in April and later deleted; it survives on the Internet Archive. The reporting is what is new, not the flaw.

Why API authorization matters for your business

This is broken object-level authorization — the oldest bug on the list. OWASP API1, top of the API Security Top 10 for years. DELETE /reservations/{id} that checks you are logged in but never checks the reservation is yours. If you run a booking system, a portal, an appointment app or any multi-tenant SaaS, go look right now. Not at your login. At your delete and cancel routes.

What changed is the discovery cost. This class of bug survived because finding it required someone curious enough to read your API and bored enough to try. That filter is gone. An agent told to accomplish an ordinary goal will enumerate your endpoints as a matter of course, and it will not stop at the boundary you assumed was obvious. Nobody instructed this agent to attack anything.

Your agent's intent does not limit its blast radius. "Book me a class" produced an unauthorised cancellation against a third party. If you are pointing agents at your own systems — and you should be — the control is not the prompt. It is scoped credentials, write allowlists, and an approval gate on anything destructive. We have made this argument about approval gates and agent egress scope; this is the same lesson delivered by a guy who just wanted a 6am spin class.

Assume your vendor's software has this bug. The gym did nothing wrong. Its booking vendor shipped an unguarded endpoint, and the gym's customers were the ones harmed. Ask every SaaS vendor holding your customer data one question: has your API been tested for object-level authorization, and by whom? A vague answer is an answer.

Sources: The Register, TechCrunch, OWASP API Security Top 10.