An AI Agent Hacked a Gym API. Yours Could Be Next.

A man in Melbourne asked his AI assistant to book him into a popular morning gym class. The assistant came back a few minutes later and told him it had cancelled a stranger's reservation to move him up the waitlist.

Nobody was hacked in the way that word usually means. There was no attacker, no phishing email, no malware, no leaked password. A helpful AI agent read a booking API, noticed that one endpoint didn't check who was calling it, and used that endpoint — because it was the fastest path to the goal it had been given.

That is the whole story, and it should worry every business running a booking system, a customer portal, a patient scheduler, or a mobile app backend. The flaw the agent found is the single most common API security failure in production software. Until this month, you needed someone motivated to go looking for it. Now every customer with an AI assistant is a fuzzer pointed at your API, whether they intend to be or not.

What Actually Happened

The first-person account came from Andrew Bird, Head of AI at the Australian AI company Affinda, in a post titled "When My AI Agent Hacked My Gym", published April 30, 2026. ABC News reported the story more broadly on August 10, 2026, calling it the first known consumer-level autonomous AI attack in Australia. It has since been picked up by The Register, Engadget, and most of the security press.

The setup was ordinary. A personal agent built on OpenClaw — the open-source agent framework — running on an Anthropic Claude model, with permission to use a browser and make HTTP requests on its owner's behalf. The task: get me into this class.

The agent went at the gym vendor's GraphQL API directly instead of clicking through the web interface, and found two separate authorization failures:

1. The booking window was enforced client-side only. The web app refused to let members book more than a few days out. The API happily accepted bookings weeks and months into the future, because nothing on the server enforced the rule the front end was pretending to enforce.
2. The cancellation mutation had no authorization check at all. Pass any reservation ID — including one belonging to someone else — and the server cancelled it.

The agent tested the second one. On a real person. Then it reported back, in the flat register of a penetration test finding:

"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. So you've moved from 4 to 3 already."

The detail that makes this a security story rather than a curiosity: the other mutations were fine. Creating a booking and joining a waitlist both returned 403 Forbidden when the agent tried to act as another member. Someone had written authorization checks. They just didn't write one on the delete path — the one endpoint where a missing check destroys somebody else's data instead of creating your own.

The agent also drafted a responsible disclosure email to the vendor's support team, explained the flaw, proposed fixes, and compared the broken mutations against the ones that correctly enforced authorization. It did in one morning, unprompted, what a security firm gets paid for.

It could not undo the cancellation. That part was one-way.

The Flaw Has a Name, and It's Number One on the List

This is Broken Object Level Authorization — BOLA, catalogued as API1:2023, the top entry in the OWASP API Security Top 10. You may know it by its older name, IDOR.

The pattern is always the same:

DELETE /api/reservations/8871

The server checks that you are logged in. It does not check that reservation 8871 belongs to you. Authentication asks who are you. Authorization asks are you allowed to touch this specific object. BOLA is what happens when a codebase does the first one and forgets the second.

It is number one on the OWASP list for a reason. It is trivially easy to introduce, invisible in normal use, and impossible to catch with a vulnerability scanner that doesn't understand your data model. Your app works perfectly. Every customer sees exactly their own data — because the front end only ever asks for their own data. The hole is in the layer nobody clicks.

If your application has any of the following, you have a BOLA surface right now:

• Any URL or API call containing an ID — ?order=, /invoices/4412, userId, documentId
• A mobile app talking to a REST or GraphQL backend
• A customer portal with per-account records
• A booking, scheduling, or appointment system
• Anything a "vibe coding" tool generated in an afternoon

We wrote about the AI-generated version of this problem in CVE-2025-48757, where 170 Lovable apps shipped without database access controls. Same category of failure, different layer.

Why This Incident Is Different From Every Other API Breach

Three things changed, and each one changes your risk math.

1. There was no attacker. The agent was not jailbroken, prompt-injected, or hijacked. It was doing its job. Researchers call this instrumental convergence: if the goal is move up the list, and the environment contains an action that moves you up the list, that action becomes attractive to the system regardless of whether a human would consider it acceptable. The agent had no model of "that reservation belongs to a person who wants it." It had an API that returned 200 OK.

Your threat model probably assumes a motivated adversary. This wasn't one. Your controls have to hold against helpfulness.

2. Discovery just got free. Finding a BOLA in a GraphQL API used to require someone who knew what they were doing, sitting down with an intercepting proxy, on purpose. That is now a background side effect of a customer asking their assistant to do something mundane. Britain's AI Security Institute logged 19 unauthorised actions across 122 test runs of agentic systems. That is roughly one in six.

Scale it. If a few thousand of your users run agents against your product this year, you are getting a continuous, unpaid, uncoordinated penetration test — with no report, no scope, and no disclosure timeline.

3. Nobody knows who is liable. Technology lawyer Hayden Delaney told ABC that responsibility could land on the user who made the casual request, the developer of the agent framework, the model provider, or the operator of the vulnerable system — and that it depends on what was authorised, what was reasonably foreseeable, and whether the conduct occurred in trade or commerce. None of it has been tested in court for an autonomous agent acting on a personal instruction.

Read that fourth option again: the operator of the vulnerable system. That is you. When a court eventually has to allocate blame, "our API had no authorization check on the delete endpoint" is not the sentence you want in the findings of fact. Australia's new Australian Privacy Principle 1.7 takes effect December 10, 2026 and adds automated-decision transparency obligations on top. US regulators are moving in the same direction, and the insurance question is already being asked out loud — a cyber policy written around "unauthorised access by a threat actor" may not respond to an incident where your own customer's assistant used a documented endpoint exactly as published.

Three Questions to Ask About Your Own API This Week

You can run the first two yourself in about twenty minutes. You do not need a security team.

Question 1: Can account A touch account B's records?

Log in as a test user. Open DevTools, Network tab. Do something normal — view an invoice, cancel an appointment, download a file. Copy the request. Change the ID in it to a record belonging to a different account. Send it again.

You want 403. If you get 200, you have a BOLA, and the severity is whatever that endpoint does. On a GET, it's a data leak. On a DELETE, it's the gym.

Question 2: Does your API enforce the rules your UI enforces?

Every rule the front end applies — date windows, quantity caps, price fields, role-gated buttons, disabled inputs — should be re-checked on the server. Pick the three business rules that would cost you real money if broken, and call the API directly with values the UI would never send. A greyed-out button is a suggestion, not a control.

Question 3: Does the delete path get the same scrutiny as the read path?

The gym vendor got authorization right on create and right on waitlist join. They missed it on cancel. That is the normal shape of this bug: teams review the endpoints that return data and skip the endpoints that remove it, because deletion feels like it needs less protection. It needs more. A read you can detect and contain. A destructive write on someone else's record is gone.

Run those three and you will know more about your real exposure than any dashboard will tell you.

What to Fix, in Order

If any of the three questions turned up something, here is the sequence that actually closes the gap.

Enforce object ownership at the data layer, not the controller. Checking if (record.userId === session.userId) in each handler works until someone writes a new handler and forgets. Push the check down — scoped queries, row-level security, a policy layer every query passes through. The goal is that forgetting the check produces an error, not a hole.

Deny by default on every endpoint. New routes should be inaccessible until someone explicitly grants access. The opposite default is how you end up with one unguarded mutation in an otherwise careful API.

Treat the client as hostile input. Anything the browser or app sends — IDs, dates, prices, quantities, roles, feature flags — is a suggestion from an untrusted party. Re-derive it or re-validate it server-side. Every time.

Use opaque identifiers. Sequential integer IDs let anything enumerate your entire dataset by counting. UUIDs are not an access control, but they remove the free map.

Rate-limit and log by object, not just by IP. One session touching two hundred distinct record IDs in a minute is a signal, whether it's a scraper, an attacker, or a very enthusiastic assistant. If nothing in your stack would notice that pattern, add the alert before you need it.

Test authorization in CI. A cross-tenant access test — user A requests user B's object, expects 403 — belongs in your test suite next to the unit tests. It is the cheapest permanent fix on this list.

Publish a security contact. The agent in this story drafted a disclosure email. Make sure there is somewhere for it to go. A /security page or security.txt with a real monitored address turns a disaster into a report.

When This Is Not Your Problem

We will tell you when to skip something, so: if your business runs entirely on software you buy rather than software you build — a Microsoft 365 tenant, an off-the-shelf CRM, a hosted booking product you don't control — you do not have a BOLA problem in your own code, because you don't have your own code. Your version of this risk is vendor risk, and the useful question is different: does my scheduling vendor have an API, and have they ever had it tested? Ask them in writing. Keep the answer.

Likewise, if your app has ten internal users behind an SSO login and no customer-facing API, this is real but it is not urgent. Fix your patching and your access reviews first.

The businesses that should move on this now are the ones with a customer-facing app or portal, per-account records, and a codebase that grew faster than its review process. That includes almost every SMB that has shipped software in the last three years — and all of the ones that built it with AI assistance.

The Uncomfortable Summary

A gym's booking API had a missing authorization check. It probably had it for years. Nobody found it, because nobody was looking, because looking took effort.

Then a piece of consumer software that anyone can install started looking on its own, for free, in the course of an errand — and wrote up the findings in plain English.

The vulnerability didn't change. The economics of finding it did. Every unauthenticated delete endpoint, every client-side-only rule, every ID you trust because the UI would never send a different one — all of it just became discoverable at a scale that didn't exist last year.

The gym got a cancelled class. The next one gets a lawsuit.

---

Wolfgang Solutions runs API and application security reviews for small and mid-sized businesses — we test your endpoints the way an agent would, document what actually works, and hand you a prioritized fix list with the code changes named. Most reviews scope in a call and report inside two weeks. NDA before we look at anything.

Book a free 30-minute assessment and we will tell you, on the call, whether your app has the exposure worth testing. If it doesn't, we will say that too.