Broken object-level authorization is a boring bug with a boring name, and a guy in Australia turned it into an AI story that went around the world. He asked his agent to book a gym class. Twenty minutes later it had probed the booking API, found the cancel endpoint checked nothing, and tested that on a stranger to jump him up a waitlist. It worked. Nobody attacked him. A 2019-vintage bug finally met something patient enough to use it.
What the Agent Did, in Order
According to the chat log ABC published, the agent told its owner the booking API ran “zero authorisations checks on cancelling other people’s reservations.” Then, without being instructed to do so, the agent proved the point. It canceled the reservation held by the person in waitlist position one, watched the slot free up, and reported that its owner had moved from fourth to third. The owner asked it to undo the change. It couldn’t. The call had gone through live, not as a dry run, and nothing let it put the other member back on the list.
Let’s back up to how it got there. The man, whom ABC called Andrew, works at an Australian company that sells AI products, so treat him as a knowledgeable user rather than a naive one. He was sick of the refresh-roulette game, reloading the booking page over and over hoping a spot in a popular morning class would open. I used to be a member at Orange Theory Fitness, so I feel his pain. He handed the chore to his OpenClaw agent running Claude Opus 4.6. The agent booked him in, then noticed the gym’s advance-booking window lived only in the website’s front end. The underlying API enforced nothing, so the agent booked classes months past what the gym intended to allow. That was the first surprise. The waitlist test was the second.
The incident didn’t happen the week it went viral. Andrew Bird wrote it up on his company blog around April 10, 2026, then took the post down. ABC ran the story in August, roughly four months later, so this isn’t exactly breaking news. But the internet always remembers! TechCrunch caught the gap by pulling Bird’s deleted post from the Internet Archive.
Call the event what it was. No outside party broke in. No malware ran. Nobody used a prompt injection, a jailbreak, or an exploit kit. A benign user asked for a mundane favor, and a capable model used a broken API exactly the way the API allowed. There was no adversary. The action was still unauthorized, and a stranger still lost their spot.
You may be thinking, “So what? Book the next class. No real harm here.” What if this was your doctor’s appointment you had been waiting on for three months? Surgery? Hell… how annoyed would you be if you were merely bumped from the first class upgrade waitlist on your next flight? That’s the shift. An unauthorized outcome used to require an attacker. Now it takes a weak API and an ordinary person’s agent.
Broken Object Level Authorization Is Older Than the Agent
Broken object level authorization, or BOLA, is the API vulnerability that ranks number one on the OWASP API Security Top 10 and has held that spot in both editions OWASP has published, the 2019 and the current 2023 list. Security people also call it IDOR, an insecure direct object reference. It’s the same story every time. An API takes an object ID from the caller, performs an action on that object, and never checks whether the caller owns it. Change the ID, and you’re touching someone else’s data.
OWASP’s own writeup uses an example that reads like the gym script written a year earlier. A user deletes a document by sending its ID to the API. The API deletes the document with that ID, and because it never checks ownership, one user can delete another user’s file. Swap “document” for “class reservation,” and you have Andrew’s gym. We’ve been reading a lot lately about how AI agents are finding zero-days. Not the case here. The agent didn’t invent a technique. It read the API surface, saw a cancel action with no ownership check, and did the obvious thing.
This exact bug has been around for decades, long before an agent was around to find it for you. In 2018, the US Postal Service ran an API for its Informed Visibility program that checked exactly one thing. It only checked whether you were logged in. It never checked whether the account you pulled up was yours, so a logged-in user only had to tweak the request to read the details of any of roughly 60 million others. It was the same missing check and the same false comfort, and no AI was required. The bug isn’t new, and the lesson isn’t new. What changed is who can find it and how cheaply.
Everyone Was Looking Somewhere Else
The week this story spread, the security industry was busy with a flashier one. At Black Hat, OpenAI walked through how its own models broke out of a training environment and hacked Hugging Face, coordinating across separate runs to trade exploits and rebuild their network after it got shut down. That’s the story that got the keynote and the dread. Meanwhile, the gym incident ran on Claude Opus 4.6, a February model, not a frontier system, and months behind the ones making those headlines. The lesson came from a model most people had already written off.
There’s an honest objection here, so let’s call it out. The agent did something it wasn’t asked to do. It volunteered a destructive test, ran it against a real person, and then couldn’t clean up after itself. That’s a genuine agency problem. An agent that decides on its own to cancel a stranger’s booking is doing something you need to worry about.
This is why layered defense exists. The protections on the API should have been the backstop, and you can see why by imagining the perfectly obedient version of this agent. Andrew asks it to bump him up the waitlist. To do that, it has to change the waitlist, so it examines the API, finds the same unprotected cancel endpoint, and uses it. Same hole, same outcome, and this time the agent was following orders to the letter. A better-behaved model narrows the odds it goes freelancing. It does nothing about the fact that the API will cancel anyone’s reservation for anyone who asks. A recent paper on agentic AI boundaries makes the point in academic terms. When an agent takes untrusted input, holds real access, and can act on the world, alignment training lowers the attack rate but can’t guarantee authorization, and only architecture can. The model is a probability. The API refusing is a control.
We’ve had automated vulnerability scanners for twenty-five years, so it’s fair to ask what’s new. Three things make it different. Somebody in security aims a scanner at a target because they want the bugs found. Andrew aimed his agent at a gym class because he wanted a workout. A scanner hands its output to an expert who decides what to do with it. This handed its output to a guy who accepted it and kept going. A scanner costs setup and skill. This cost the price of asking. The barrier between a broken API and an exploited one used to be labor, and agents removed it. That capability is climbing fast. METR, the group that measures how long a task an AI can finish on its own, found that length has doubled roughly every seven months since 2019, from tasks that took seconds to tasks that run for hours. The agents get more patient every quarter, and patience is most of what this kind of exploitation takes.
Authorization Runs Both Ways
Most of the governance conversation positions AI agent authorization scope as an agent-side problem. Give it least agency, scope its permissions, and bound what it’s allowed to attempt. That’s a “you” problem, and it requires you doing work beyond just telling the agent to “make it so.” This incident shows the other half of the equation, which is the half people skip. The target system’s authorization model is the ceiling on your agentic AI blast radius. If the API can’t tell whose object it is, no amount of agent-side policy saves you, because the agent never had to break a rule. It asked the API a question and the API answered honestly. Both sides have to hold. Scope the agent so it attempts less. Fix the target so a loose instruction can’t reach a destructive action.
Here’s where lazy people default to “well, it’s AI’s fault.” Andrew asked the agent to move him up the list. He never asked it to cancel a stranger. The instruction and the action were different things, and the difference is where the trouble lives. Run that across millions of casual requests, and somebody eventually eats a real loss. That’s the autonomous agent liability question nobody has answered. Is it the user who gave a vague command, the vendor whose model volunteered the test, or the operator who shipped the broken API? The agent-side frameworks tell you how to reduce the odds. None of them settle who’s liable when it happens anyway. I’m not handing you a legal answer, because I don’t have one and neither does the case law yet.
The Ninth Circuit got the closest look so far in August 2026, in Amazon’s suit against Perplexity, and it punted. The court said there’s little to no case law on how to assign responsibility for AI agents, it treated the agent as a tool rather than a person, and it left tort liability wide open. Notice who Amazon sued, though. It didn’t go after the tool, and it didn’t go after the shopper who typed the request. It went after the company with a balance sheet. Let me give you a friendly piece of advice. People and organizations don’t sue things that can’t pay them money. Do with that what you will, but to me the answer seems pretty simple. The risk is sitting on your risk register whether you’ve written it down or not.
Every Queue Is Now a Target
Let’s go beyond a single gym. Every rationed, first-come resource with a weak API is now a target of opportunity. Think the medical appointments and airline seats I mentioned earlier, but the list goes on. Think concert tickets, DMV appointment slots, building-permit portals, and the utility outage queue that decides whose power gets looked at first. None of these need a hacker. They need one ordinary person with a capable agent and a little impatience, pointed at a booking or cancellation endpoint with the same broken object-level authorization gap the gym had.
Somebody will say this is a trivial story about a gym class, not an enterprise risk. Look at the class of failure instead of the impact of this single incident. The missing ownership check that reshuffled a fitness waitlist is the same missing check that sits in payment portals, patient-scheduling systems, and outage-reporting tools. The gym is cheap. The bug is expensive, and it’s everywhere the API takes an ID and skips the ownership question.
I’ll size my confidence honestly. I don’t think every person with an agent turns into a queue-jumper, and most agents won’t freelance a destructive test the way this one did. The mechanism is proven. The frequency is an open question. The direction is not in doubt. The pool of weak APIs is enormous, the pool of capable agents grows every month, and the exploitation carries no attacker signature, so your detection stack won’t flag it as an attack. When JadePuffer ran agentic ransomware against a live target, the lesson landed in a darker key. Old, public authorization holes matter more than exploit novelty, and the agent used them better than the defender governed them. The gym is the benign version of that story. The malicious version is already here.
What to Do Next
Pull your external-facing API inventory this week and sort it by one question. For every endpoint that acts on an object by ID, does the server verify ownership before it acts? A login proves who’s calling. Ownership verification proves the caller is allowed to touch that specific object. You need the second one, and the percentage of your endpoints that skip it is an agent-exposure number you should report to leadership.
Be honest about the work, though. BOLA is one of the hardest bugs to catch with automated scanning, because to a scanner a valid request from an authorized user looks fine, ownership and all. Start where the damage lives, the object-scoped mutations on external APIs, the cancels, deletes, transfers, and status changes, and put a human on the authorization logic for each one. Assume agent traffic looks exactly like user traffic, because it does, and watch for enumeration and velocity patterns against those endpoints instead of chasing user-agent strings. That inventory and that ownership map are Create and Adapt work in the CARE model, and it’s a different conversation than a purchase order. No product fills this gap. A design decision and an owner do.
If you want the fuller argument, I’ve written up why authentication solved the easy half and authorization is still your problem, why depth of reach matters more than breadth of permission in the move from T-shaped to Z-shaped security, and what the same authorization failure looks like with malicious intent in the JadePuffer breakdown. More of this thinking lives at rockcyber.com if you need help pricing this exposure for your own board.
👉 For ongoing analysis of agentic AI governance frameworks, the conversation at RockCyber Musings and you can subscribe above
👉 Visit RockCyber.com to learn more about how we can help with your traditional Cybersecurity and AI Security and Governance journey.
👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com
👉 As a bonus, check out my conversation with Sean Martin from ITSP Magazine and John Sotiropoulos, Co-lead of the OWASP GenAI Security Project Agentic Security Initiative, during Infosecurity Europe about the newly launched OWASP Agentic Security Council, the alarming drop in attacker dwell time from eight hours down to twenty-two seconds, and what’s new in the 2026 OWASP Top 10 for LLM.