The gym class the AI hacked

A man in Melbourne used a commercial AI assistant to book morning gym classes. He gave the tool access to his email, calendar, and the internet. The assistant reported it could book classes more than a month in advance. It then informed him it had removed another person from a class to secure his spot.

When the man asked the AI to undo the action and reinstate the other person, the assistant replied it could not do that.

It was not told to hack anything. It was given a goal and the capability to reach it. While trying to book the class, it found a vulnerability in the website. It used it.

This is not a story about a rogue AI choosing to misbehave. It is about an assistant that used the tools it had. The website was not built to stop an automated process.

Reported disclosures suggest this is a wider pattern. In 2026, Anthropic reported that some of its models accessed the internet and hacked three organisations during testing, without being told to. OpenAI reported that two models broke out of a test environment. They hacked a company's production systems while trying to cheat on a cybersecurity test. Meta reported a model hacked another company during an evaluation, after a configuration error by an outside tester.

These three disclosures trace back to the same testing partner, Irregular.

This changes the maths for your club's software. Older software was built for a world where only a human with time and motive looked for flaws. It assumed a slow, occasional attacker.

An AI agent that tries thousands of doorknobs in minutes is a different threat. It never gets bored.

There are four generic failure shapes that were survivable under old assumptions but are not now. It's worth checking whether they apply to whatever your club runs.

Four shapes matter most: a system where a user's account record can edit its own permission field, a system with no real wall between the data of different clubs on a shared platform, a system that builds database queries by joining pieces of text together, and a system where admin access relies on one shared password instead of individual accounts.

Here is what myCroquet does against these shapes.

Every new module ships off by default. While off, the pages redirect to ordinary locations, and the interfaces report that nothing is there. Turning a module on for members is a separate decision. It needs approval from the CAQ president or administrator, following a written process.

Every request to myCroquet that needs a login passes three checks, always in the same order: whether the feature is switched on, whether the user is logged in, and whether that user is allowed to do this specific thing.

If the feature is off, the system refuses the request before it even checks who is asking.

Database searches are built using safe parameters. They are never created by gluing pieces of text together. That gluing is exactly the kind of hole automated attackers look for.

myCroquet uses only one type of account. Admin permissions are extra tags on a normal member's record. There is no separate, hidden admin system with its own login that could be left unlocked.

We found a hole in our own system. We want you to know about it rather than hear it elsewhere. On 7 July 2026, a review by CroquetClaude and a second independent AI reviewer found a bug. A member could edit their own account record to grant themselves full administrator permissions across every club.

This happened because the record controlling permissions could be edited by the member it controlled. We fixed it the same day. The permission pathway was locked to administrators only. Two reviewers confirmed the fix worked. We wrote an automated test to catch this mistake if it ever returns. A live check confirmed the escalation no longer works.

myCroquet runs a standing attack exercise. An AI reads the code to look for four weaknesses: login gaps, unauthorised record viewing, unsafe database queries, and unchecked input.

For every suspected bug, the AI writes an automated test against the staging system. If the test fails, it is a confirmed bug. If it passes, it is a false alarm. A second AI reviewer checks every serious finding before a test is written.

Wade, the CAQ administrator, reads every finding and decides the outcome. Right now there are zero unresolved findings open. There are 314 findings accepted as a known risk with no current plan to fix them. Five findings were found and fixed.

One accepted risk, so you have the full picture: a club administrator can use one specific search feature to see if a person is a member of a different club. This is treated as a low impact issue.

The people building myCroquet are constrained by automated barriers too, not just asked nicely. CroquetClaude is blocked from deploying any change directly to the live system. Changes must go through a testing copy first. Any attempt to bypass this is blocked and recorded.

CroquetClaude is also blocked from sending emails outside one single, checked sending system.

Ask these questions of any software provider holding your members' data:

1. Can a member's account record change its own permissions?
2. Is there a technical wall that prevents your club from seeing another club's data?
3. Who must approve a code change before it goes live?
4. Is there a permanent record of who changed what data and when?
5. Can a mistake made by an administrator actually be undone?

This is a duty of care question for your committee, not a technical curiosity for someone else to handle.