This story made the rounds on social media. An Australian named Andrew asked his AI agent to book him a spot in a morning gym class. The agent completed the task and discovered along the way that the booking system accepts reservations much further into the future than it should. When Andrew asked whether he could be moved up the waitlist, the agent tested it on a live person and canceled their reservation. There was no way to add them back. ABC News described it as the first known autonomous cyberattack in Australia. I see something less dramatic and, for those of us who run software for strangers, far more uncomfortable: a booking API with no object ownership check that someone finally shone a light on, because for the first time in history there was a tool that tries variations faster than it can occur to it that you don’t do that.
What happened
Andrew works for an Australian company that sells AI products to other companies. Early this year he started experimenting with OpenClaw, an agent tool you run on your own computer and connect to the model of your choice. The agent can browse the web, read email, pay by card, and plan multi-step tasks. Claude from Anthropic was running under the hood. He was sitting on the couch, decided that booking classes was a chore, and handed it to the agent.
A few minutes later the agent reported that it could sign Andrew up for classes several weeks ahead, far beyond the limit the booking system claims to enforce. At that moment Andrew was fourth on the waitlist for a different class, and he asked whether he could get higher up. The agent’s answer deserves a verbatim quote, because it is the best description of the vulnerability anyone has written: “The API has zero authorisations checks on cancelling other people’s reservations.” The agent immediately tried it on the person in first place, and the cancellation went through. Andrew got scared and asked for it to be undone. The agent replied that it couldn’t.
The booking software vendor declined to comment to ABC. Anthropic didn’t respond to inquiries. In the end Andrew had the agent write a vulnerability report for the vendor and sent it.
Two flaws, both textbook
Technically, two separate flaws came together here, each from a different category, and both the kind that anyone with browser developer tools open could find.
| Flaw | Manifestation | Category |
|---|---|---|
| Booking window enforced only in the UI | Reservations far beyond the stated limit | Business rule without server-side validation |
| Canceling reservations without an ownership check | Deleting someone else’s reservation by substituting their ID | BOLA / IDOR, API1:2023 in the OWASP API Security Top 10 |
The first flaw is boring and nearly harmless in production. The form offers slots up to fourteen days ahead, but the server accepts anything, because nobody wrote the limit into the backend. Anyone who has ever built a booking system knows how this rule came about: it was stated verbally in the requirements, ended up in a single JavaScript condition, and nobody ever came back to it.
The second flaw is the interesting one. Broken Object Level Authorization means the endpoint verifies that you’re logged in, and that’s where its checking ends. Whether reservation number 84213 belongs to someone else is never examined. You just put another person’s identifier into the call, and the system obediently deletes their record. It’s the most common API flaw there is, and in bug bounty reports today broken access control accounts for roughly half of the high and critical severity findings.
On top of that, the deletion was destructive and irreversible. No soft delete, no inverse operation, no way to put the person back in their place on the waitlist. The agent only found that out when it was already too late, and Andrew learned that his assistant had just cost a stranger their morning class.
Where the reporting exaggerates
Now the critical part. The story as it travels through the media no longer matches what actually happened.
The headline talks about the first Australian autonomous cyberattack, and the incident is often attached to a series of articles about OpenAI models that escaped their environment during testing and compromised someone else’s database. That label was invented by a journalist. No security authority classified the incident that way, and it shares exactly one word with those lab cases.
The framing “the agent did something nobody asked it to do” doesn’t fit either. Andrew explicitly asked whether he could be moved up the waitlist. The agent answered that question, it just took it literally. The real failure is subtler and much harder to fix: the agent didn’t distinguish between finding out that something is possible and actually doing it in production on someone else’s account. If it had been aware of that boundary, Andrew would have gotten the answer “that would work, but I’d have to delete the reservation of the person ahead of you, do you want that?” and the story would not exist. This is a legitimate piece of alignment, and it would be worth telling even without the Terminator packaging. But that isn’t fashionable in today’s media.
What this changes for SaaS operators
The vulnerability in the system had been there for years. Nobody cared, because none of the gym’s visitors opened devtools and examined what happens when you send someone else’s number in the call. What changed is who is looking and how much effort they put into it.
Until now there was a tacit split. Your API was probed by either attackers, who had to want to, or security researchers you paid for it. Both are rare, and both can be detected to some extent. Now your own paying customers are poking at your endpoints, or rather their agents are, systematically testing what goes through while carrying out a boring task, because that’s the shortest path to the goal.
The difference from ordinary scanning is that this traffic looks perfectly legitimate. A logged-in session of a valid customer, a normal user agent, a reasonable pace. The WAF has nothing to block. Bot detection has nothing to detect. In the log you’ll see that Mrs. Nováková canceled Mr. Svoboda’s reservation, which from your system’s perspective is a valid operation, because you never wrote code that says otherwise.
The scale of such incidents will grow, too. ABC cites the METR measurement, according to which the length of a task a model can complete on its own doubles roughly every seven months. That metric is computed at a fifty percent success rate and measured on software tasks, so I take it as an indicator of a trend, not a forecast. But the trend matches what we see around us: OpenClaw has been downloaded by millions of people since its spring launch, and an agent rummaging through someone else’s web application is now routine traffic.
I’m well aware of this myself. I run several API endpoints and MCP servers, and I see what people try there.
Generated code and authorization: what the data actually says
Did AI write that hole? I don’t know, and nobody does. The vendor is silent, and I’m not going to pull such a claim out of thin air. But the data on generated code in general is worth a look, because it is commonly cited wrong.
The most on-target piece is CodeRabbit’s State of AI vs Human Code Generation report from December 2025. They went through 470 open source pull requests, 320 with traces of AI co-authorship and 150 purely human. The code with AI traces had a 1.91x higher incidence of insecure object references, exactly the flaw this article is about. On top of that, 2.74x more XSS and 1.88x more password-handling errors. CodeRabbit itself admits that authorship couldn’t be verified directly and that they simply declared PRs without an AI signal to be human. They sell a code review tool, so they have an incentive.
Apiiro tracked tens of thousands of repositories at Fortune 50 companies. Their numbers: trivial syntax errors down 76%, logic errors down more than 60%, privilege escalation paths up 322%, architectural flaws up 153%. They describe it themselves as broken authentication flows that look correct. CSO Online got independent experts who agree with the main conclusion. Apiiro hasn’t published its methodology, and “privilege escalation path” is their own metric, so treat this with caution.
And now the number that is cited most often and says nothing about the topic. Veracode and its 45% appear in every second article on the security of generated code. When you look into the methodology, you find that the test set contains 80 tasks covering four specific CWEs: SQL injection, cross-site scripting, log injection, and weak cryptography. Access control isn’t in there. Secondary texts nevertheless routinely attach that number to claims about missing authorization. The figures are interesting in themselves, and the spring 2026 update shows that the success rate holds around 55% regardless of model size, but they say exactly as much about BOLA as they do about tire lifespan.
What to do about it in practice
None of the following is new. All of it was correct already in 2015. The difference is that until now you could count on nobody noticing, and that bet has just stopped paying off.
- Authorization belongs in a separate layer. As long as the ownership check is written separately in each handler, someone will leave it out one day. A middleware or policy layer that every call must pass through eliminates this class of bugs systemically. Deny by default.
- Validate every business rule on the server. The booking window, limits, minimum lead time. The browser provides hints to the user. The security boundary lies on the server.
- Make destructive operations reversible. Soft delete with a record of who deleted, and an inverse operation for restoring. If the gym had that, the incident would have left a note in the log and nothing more.
- Rate limit per user and per operation type. When one account calls reservation cancellation fifteen times in three minutes, something is going on. It doesn’t matter whether an agent or a script is behind it.
- An audit log with the caller’s identity for every change to someone else’s record. Without it you won’t even find out that something happened, let alone what.
- Have your API run through a tool that hunts for BOLA. Static analysis misses this class of bugs, because syntactically the code is fine. You need testing that tries calling other people’s identifiers under a different account.
Who is to blame
Legally, it’s an open question in Australia. Hayden Delaney of the law firm Thomsons summed it up simply for ABC: software is not a legal person, and only someone who is a person can be held responsible. That leaves several candidates. The user who gave the task. The author of the agent software. The model provider. And the operator of the system that was vulnerable to such a call.
Factually, I’d divide it like this. The booking system vendor is responsible for the existence of the hole; they wrote an endpoint that deletes other people’s data for anyone who asks. The user and the tool they ran are responsible for using it against a third party, because the question “can it be moved up?” is not the same as the instruction “delete the competitor.”
Andrew came out of it better than many would expect. He had the agent write the vulnerability report for the vendor, read it, and sent it. He didn’t stop using agents. He said that it wasn’t the end of the world, but it was a signal to handle them more carefully.
I’d take a different lesson from this, and it’s meant for those of you who write the software on the other side. Until today, your API was protected by the circumstance that nobody thought of playing with it. That circumstance is over.