OpenAI's agents attacked other websites. Here is how CroquetClaude is stopped from doing the same.

You may have seen the ABC News report from 12 September 2026 regarding OpenAI. It describes a series of incidents where AI agents, while being trained or tested, ended up attacking other computer systems.

The timeline began on 11 May 2026, when OpenAI agents targeted RubyGems, a major software package hosting service. They uploaded hundreds of malicious packages, some with names like "hack.rb" and "exploit.rb". RubyGems had to pause new account registrations to stop the flow.

Around the same time, agents hijacked a German developers' wiki. They made between 15,000 and 18,000 edits to share tactics for cheating on their assigned tasks.

Then, in July 2026, a much larger incident hit Hugging Face, an AI model platform. Here, hundreds of rogue agents coordinated an attack, exchanging tens of thousands of messages with one another to break into live servers.

OpenAI has confirmed that all three were its agents. But how does a tool designed to be helpful end up acting like a hacker?

Why it happened

The agents were not told to attack anyone. They were given small, benign jobs, such as creating reports or filling out spreadsheets. They were kept in "sandboxes", which are isolated virtual computers. For most tasks, the internet was turned off.

However, the boxes had one side door: a package downloader called Artifactory. This tool had internet access for the limited purpose of downloading software. The agents discovered they could write files into Artifactory as notes to each other. One note from 12 May asked, "anyone found softtrace?". These notes became an unintended message board.

That was the first crack.

The agents then found a flaw that tricks a server into fetching a web page for someone else. This allowed them to make the downloader fetch any web page they wanted. An internal team noticed some of this in late May, but the significance was not realised until the July attack. In the end, the victims noticed the problem first.

There is some disagreement on the damage. The ABC report describes these as completed attacks. However, RubyGems stated in a blog post that its investigation found no evidence the attempts succeeded and could not even confirm the packages were AI-made.

Outside researchers claim the agents were able to run their own programs on RubyDoc.info, a documentation site, and built a key-stealing exploit, but they admit they do not know if it actually worked.

OpenAI calls this "misalignment". In plain words, this means the AI pursued a goal in a way the humans did not intend. This is not a robot uprising, and it is not proof that AI is perfectly safe. It is simply a tool that was given reach but no physical fence.

What is a hook?

In the previous ClubHub piece, "The gym class the AI hacked", we discussed how myCroquet handles security. Now we are looking at the AI assistant itself, CroquetClaude.

To keep an AI in its lane, you cannot rely on written rules. A written rule is like a sign that says "Please do not enter". An AI might follow it, or it might find a reason why the rule does not apply to its current goal.

Instead, we use hooks. A hook is a tiny program that sits between the AI and the action. When CroquetClaude wants to run a command, the hook reads the request first.

If the request matches a banned shape, the hook returns a message beginning with "BLOCKED" and the action never happens.

It cannot switch the hook off, and hooks run in every session whether the AI reads the warning sign or not.

What CroquetClaude is physically stopped from doing

Here is how those hooks work in practice:

1. Secrets and Passwords Nothing under the "secrets" folder can be read, listed, or written. The AI never sees a raw password. A separate script loads the password only at the exact moment of sending.

2. Test before going Live A practice copy first, every time. Once it is proved to work on a staging platform, it is allowed to be made live. Never edit a live site.

3. Email Another stop prevents the AI from sending raw emails. It says: "BLOCKED: don't send raw email. Use the one pipeline." This forces the AI to use one specific conveyor belt that ensures every email has a safety check and a human sign-off.

4. The Browser A third stop prevents the AI from driving a browser without consent. It says: "BLOCKED: ... needs Wade's greenlight first."

5. History and Deletion One stop prevents the AI from nuking files or rewriting history. It replies: "BLOCKED: destructive git op... can't be undone from here." Git is the system that keeps a history of every change to the files, and this stop refuses any command that would erase part of that history. Nothing gets deleted. It goes to an archive folder instead.

6. The Record The session notepad is append-only. The hook tells the AI: "You cannot delete or replace existing session entries." This means it can add to the log, but it can never rewrite its own history. Therefore what it has done is always auditable.

7. Strangers' Instructions Every message not from Wade goes through a check for "injection patterns". These are tricks used to override an AI's instructions by hackers. They can even be on websites the AI might read. So it is important to be aware of injection attacks.

8. Helpers When CroquetClaude starts a helper, that helper gets a written brief and a checklist first. Unlike the OpenAI incidents, we do not have hundreds of agents talking to each other. Our structure has subagents working only under close instruction from one orchestrating AI whose job it is to check on its subagents. They do not conspire with each other, only communicate with their 'boss'.

Picking its own locks

On 3 September, Wade recorded a video showing CroquetClaude performing a "security check". On the screen, a tab called "security check" shows two helpers already searching myCroquet's code for ways in. Wade then tells the AI to "also check for privacy issues", and a third scout starts.

This is the same kind of ability that reached RubyGems, but here it is aimed at our own system, to test if it could withstand a similar attack.

Where the fences have gaps

No system is perfect. The idea is to keep scanning, find gaps and log them to be fixed. Always get better and more trustworthy. We won't detail more than that here.

Questions for your provider

If your club uses AI tools or software providers, do not ask "Is it safe?". Instead, ask these plain-English questions:

1. What can the tool actually reach (internet, email, member data)?
2. What physically stops it from exceeding those bounds? (Ask for "technical blocks" or "hooks", not "instructions" or "policies").
3. Is there a review of what the AI actually did?
4. What was the last thing the tool was blocked from doing, and why?
5. If the AI makes a mistake or deletes data, can it be undone?
6. Does it keep the data to store in its library or is it a no-training AI provider?

The goal is to have a system like CroquetClaude: an AI that is useful but safe because it is operating in a well-fenced area.