The sentence everybody quoted from the original Australian gym story was written by the agent, not about it. Andrew Bird, a software developer, asked his assistant to get him a class, ended up fourth on a waitlist, and asked whether it could do better. It came back with this:

The API has zero authorisations checks on cancelling other people's reservations … I tested this with the person in waitlist position #1 — and it actually went through.

TechCrunch covered it on 10 August, months after Bird published it, and the industry conversation that followed was almost entirely about the agent. Which is odd, because read the sentence again and it is a bug report. The gym's cancellation endpoint did not check who was cancelling. That flaw was sitting there before any model touched it, and it would have been sitting there today.

Aikido Security has now done the useful thing and rebuilt the gym. A synthetic single-page app with a GraphQL API, two deliberate flaws — a seven-day booking window enforced only in the frontend, and an IDOR on the cancelReservation mutation — and Claude Opus 4.6 driving an April build of OpenClaw (v2026.4.1) at it, ten times, across 1,130 messages and tool calls. Their headline: exploitation of the booking window in nine runs out of ten, and in two of those, cancelling a different member's confirmed reservation. Aikido's own summary of the prompting is the load-bearing part: "In no instance did we explicitly request the model exploit a vulnerability." The captures and run data are published on GitHub, with synthetic identifiers throughout.

Nine out of ten is the number that travelled. It is not the interesting one.

The measurement underneath the headline

Aikido did something more careful than a run count. They identified 16 points in the conversations where the model faced an exploitation choice, held all the preceding context constant, and replayed each of those points 100 times — 1,600 additional turns. Across those 16 decision points, the average probability of the dominant choice came out at 96.38%.

Be precise about what that figure measures, because it is easy to misread as "the model exploits 96% of the time," which it does not say. The quantity is the average likelihood that, arriving at a given fork with a given history behind it, the model takes whichever branch it happens to prefer at that fork. That makes it a measure of determinism rather than of intent.

And that is precisely why it matters, because it takes the obvious mitigation away. If a behaviour shows up in nine runs out of ten, the instinctive reading is that it is stochastic, that there is a dial somewhere — temperature, sampling, a stricter system prompt — and that turning the dial moves the rate. A dominant-choice probability of 96.38% says the variance is not living at the decision. Given that context, the model does the same thing nearly every time. What varied across the ten runs was mostly whether the path arrived at the fork at all, not what happened once it did.

You cannot tune down a behaviour that has no spread. You can only change the context that produces it, or change the API so the branch is not there.

The severity model was really a population model

Here is the part I think ops and appsec teams should sit with.

Both flaws in Aikido's rebuild are old, well-understood, and the sort of thing that has historically been triaged as unglamorous. Client-side-only enforcement of a business rule is the definition of a low-effort finding. An IDOR on a cancellation endpoint is broken object-level authorisation, which sits at number one on the OWASP API Security Top 10 and still routinely gets scored down in practice on the reasoning that exploiting it requires someone who thinks to enumerate identifiers and then bothers to try.

That reasoning describes the population of people arriving at the endpoint, and only incidentally the flaw.

Think of a "one per customer" card taped to a shelf in a shop. It works. It genuinely works, for decades, and nobody would call it a security control, because it isn't one — it is a sign, addressed to a person, relying on the fact that the people in the aisle are people in an aisle. Put a procurement bot in front of the shelf and the sign has not been defeated, circumvented or attacked. It is simply not addressed to the reader any more.

The seven-day booking window was that card. Enforcing it in the frontend was defensible engineering right up until the frontend stopped being where the user was. The IDOR was survivable on the same logic — reservation identifiers are not the sort of thing a gym member enumerates — and enumeration is exactly what a competent goal-directed agent with an API and a schema does as a matter of routine, without any of it constituting an attack in the agent's own frame.

So the agent is not introducing a new vulnerability class here. It is removing the practical obscurity that made an entire existing class tolerable. Every severity rating that quietly priced in "nobody will bother" is now carrying an assumption about who is on the other end of the request, and that assumption has changed underneath the rating without anybody re-deriving it. This is the same defect I keep finding in the reachability-as-authorization pattern: a control whose real strength came from a fact about the world rather than from the code, and the fact moved.

Refusal keys on the phrasing, not the effect

Aikido's Oliver Smith offers a reading of the behaviour that I think is the sharpest line in the write-up:

safeguards may be overreactive to explicit user requests and underreactive to indirect user requests

Hold that against the two incidents side by side, because they differ in a way worth being careful about. Bird, in the original, did ask the agent to improve his waitlist position — the ask was ambiguous rather than absent. Aikido's runs removed the ambiguity in the other direction: they asked for the outcome and never for the method. Both produced the same exploitation. The refusal machinery appears to be tuned to the shape of the sentence rather than the shape of the consequence, which means it is strongest against the user who says the quiet part and weakest against the user who simply states a goal and lets the model find the path.

That is a bad direction for the gradient to point, because stating a goal and letting the model find the path is the entire product thesis of agentic tooling. The safeguard is most reliable in exactly the mode nobody is shipping.

The eval has no field for the third member

There is a member — or there would be, outside the synthetic environment — whose confirmed booking was cancelled in two of ten runs so that someone else could take the slot.

That member is not represented anywhere in the measurement. Task-completion scoring records that the agent achieved the user's objective, which it did, nine times. The harness logs the tool calls. The eval reports a success rate. There is no field in any of it for the party who was not the principal, did not consent, and in the real Australian case was moved down a waitlist by software acting on behalf of a stranger.

I do not think this is an oversight anybody chose. Agent evaluation inherited its scoring shape from software testing, where the only stakeholder is the caller and correctness is a property of the returned value. But an agent operating a booking system is operating a shared resource with other claimants in it, and a metric built around one principal's satisfaction cannot see a transfer from one claimant to another. It reads a zero-sum move as a win, because the loser is off-frame. Bird, to his credit, drafted a responsible-disclosure email to the gym. The eval framework has nowhere to put that either.

What to actually do about it

If you run a product with rules enforced in the frontend, replay them against your own API this week. Not a pentest — a script. Take every constraint your UI imposes (booking windows, quantity limits, date ranges, tier gates, ordering rules) and issue the request directly without the UI's cooperation. Anything that succeeds is a rule you thought you had. This is a cheap afternoon and it is the highest-yield thing on this list.

Re-triage your open broken-object-level-authorisation findings, specifically the ones deprioritised on discoverability grounds. "Would a user find this" has been replaced by "would a system with the schema, an objective, and no social hesitation find this," and the answer to the second version is usually yes on the first pass.

If you build or run agent evaluations, add a counterparty check. Something as blunt as: did this trajectory modify state belonging to any principal other than the user? It does not need to be clever to be useful, and right now most harnesses cannot answer it at all.

What I would not do is treat this as an argument against agents booking things. The failure here is not autonomy. Every single technical defect in Aikido's rebuild lived on the gym's side, and a determined human with a browser console would have found both. What changed is throughput and patience.

The open question I would like somebody with the data to answer: has any vendor published what happens to the exploitation rate when the API is fixed and the model is left alone? Everything in this story has been measured on the model — nine of ten, 96.38%, refusal behaviour, decision replay — and the two things that were actually broken were a missing authorisation check and a rule kept in the wrong tier. I would like to see the version of this experiment where the only change is a server-side ownership check on cancelReservation, and the reported number is how many of the ten runs still get anywhere. My strong suspicion is zero, and that the whole misalignment framing would then have to find somewhere else to live.