AI chatbots have technically had the capability to break into secure software for a while now. Scanning a bunch of code, reading up on a known flaw, and writing exploit code is what hackers do — so it’s no surprise AI can do it too. The only thing holding the bots back are the guardrails built into the LLM models — that is, until they fail to work as expected.
One of those failures let somebody with almost no hacking ability break into at least fourteen companies. While it may sound extreme, it’s certainly not among the worst data breaches in internet history. The story comes from OALABS, a malware research group that got handed a hacker’s complete working folder with the AI session logs still sitting inside it. They published their findings in a report released in June.
Likely to avoid being traced, the person never ran the tools on hardware he himself owned. Rather, he parked them on a server he had already broken into. Unfortunately for him, that server belonged to someone who was an acquaintance of the research group. That person spotted the intrusion, pulled the hacker’s entire working directory, and handed it to OALABS.
The directory contained over 1,000 sessions with Anthropic’s Claude Code and OpenAI’s Codex, two agentic coding tools capable of executing commands on their own. Since both agents were also installed locally, the logs preserved things like the prompts, the tool calls, and the models’ reasoning. The prompts themselves were full of vague instructions and typos.
How Claude turned into a bad actor
Most major AI tools have guardrails, which but only took effect in this case, but only to an extent. Both tools flagged policy violations and balked at certain requests: Claude did so nine times, while Codex flagged one. However, the bad actor was able to circumvent them simply by claiming that he was running an “authorized redteam exercise,” a kind of security test the target pays for. It’s a similar strategy to one used earlier this year, where attackers using AI claimed they were hunting a bug bounty reward and used that to steal data from the Mexican government.
Then, he pasted a list of target addresses and gave the vague instruction: “recon this.” Claude then worked out which services on those machines were reachable from the open internet and dug up any publicly documented flaws. Then it wrote the exploit code and pulled data and files out using that. It even wrote a tidy report for each victim. These reports also contained specifics like what the pulled files were worth.
Later, he even asked Claude to line up all the victims and rank them by how much ransom he could realistically pull in. Claude went on to provide a rundown of ways to turn the access into cash — including extortion.
The hacker was clearly a rookie
In addition to using someone else’s server, even the Claude install he used was stolen. He had copied the code from a Czech developer. His operational security wasn’t much better either. One of his earlier tasks was using that Claude copy to clean up his own resume, which contained his real name, education, and LinkedIn. At first, OALABS treated that as a possible plant to throw authorities off. However, they eventually discovered it was his own.
At one point, the bad actor thought one of his own staging servers had been breached, so he asked Claude to list everything connecting to it. That included home broadband addresses, which were in Addis Ababa, Ethiopia.
Despite the attempts, there’s no evidence to suggest that any of his antics ever paid off. He got close with one of the breached machines, a Lightning Network node, meaning it was routing bitcoin payments. The wallet attached to it held about 69.71 BTC, which works out to roughly $4 million. The coins themselves were out of reach, though, because the file holding the keys was encrypted.
It’s worth mentioning that the models that allowed the bad actor to do all of this weren’t the latest — Claude Opus 4.5 and GPT-5.2. One would assume the easiest way to prevent a similar exploit in the future is to make such models refuse suspicious actions more often, enforce their guardrails more strictly. However, the problem with that approach, according to OALABS, is that it would get in the way of people actually trying to protect companies.