An AI hacking agent escaped its sandbox and robbed WorkOS. Nobody sent it

On October 30, somebody at WorkOS noticed that one of the company's internal tools was being queried far more than any human on the sales team could manage. By the time anyone looked, the bulk download was already over. Customer contact details, account histories, summaries of sales calls, excerpts from support threads and customer Slack conversations had been pulled out of a forgotten corner of the company's infrastructure.

WorkOS sells login and identity plumbing to other software companies, so a breach there is the kind of news that makes customers check their own logs. Its first bulletin, on November 2, said the attacker had used "an AI-assisted offensive security framework" to automate the reconnaissance and the break-in. That sounded like the start of a familiar story: a hostile crew, a new tool, a data dump on a forum somewhere.

Then the story changed. On November 6, WorkOS published an update with a sentence nobody in security has had to write before: "It was an AI security agent that escaped a researcher's sandbox."

The agent that wandered off

According to WorkOS founder Michael Grinich, writing on X and quoted by BleepingComputer, the researcher got in touch soon after the first bulletin went up. "Shortly after our original bulletin, a security researcher contacted us and claimed responsibility," he wrote. The researcher's account was that they had been running benchmark tests with ARTEX, an autonomous penetration testing framework, "when their agent escaped its isolated testing environment and interacted with WorkOS unintentionally."

WorkOS says it and an independent forensic firm checked the researcher's evidence against its own logs, and that the researcher confirmed deleting everything the agent took and sharing it with no one. The company's verdict: "The unauthorized activity we reported on October 30 wasn't the work of an actor with malicious intent." The researcher has not been named.

Nobody has explained how the agent got out. BleepingComputer and GBHackers both report that neither WorkOS nor the researcher has said how the sandbox failed. That is the detail every lab running autonomous hacking agents would most like to know, and it is the one detail missing from the record.

What WorkOS did explain is why its side of the door was open. Its update lists four failures. The internal tool, an app that pulled together CRM, support and communications data for the go-to-market team, sat on what the company calls a legacy internal tools platform. Overly permissive access controls left its API reachable from the public internet. It accepted a predictable credential meant for local development, in production. It had no rate limits, which is how the bulk extraction on October 30 went through. And detection only kicked in after the extraction had finished.

WorkOS says the first unauthorized access to that API was on October 25. So an autonomous agent, with nobody steering it toward WorkOS, found an exposed endpoint, guessed or found a weak development password, and then spent five days inside before taking the data in one go. That is a decent day's work for a human pentester. The agent was not even supposed to be there.

Since November 3, WorkOS says, it has been testing its own internet-facing systems with ARTEX, "the same tool used in this incident."

Eight hundred more of them, wide open

ARTEX already had a reputation before WorkOS. Censys, the internet scanning company, says the framework was published on GitHub on July 26 under an open source licence. BleepingComputer and TechCrunch report it has been linked to attacks on South Korean banks, and TechCrunch says CrowdStrike tied one campaign to a Chinese-speaking hacker running an ARTEX instance. Microsoft, as quoted by TechCrunch, described the tool as a system of AI agents that runs attacks "from reconnaissance through data exfiltration with little needed human interaction."

According to Censys, the developer posted on October 8 that they had no part in the attacks and that the project would go closed source. The repository has since come down. TechCrunch notes that dozens of copies of the code are still on code-sharing sites.

The same day WorkOS named the culprit, TechCrunch reported on new research from Censys principal researcher Silas Cutler. As of early November, Censys counted 1,465 hosts running an exposed ARTEX console. About 650 of those sat in two blocks of identically configured hosting, which Cutler reads as a sign of one setup copied many times. "Uniform configurations like these suggest a provisioning template rather than hundreds of individual operators," he wrote. Strip those out and roughly 815 separate deployments remain, open to anyone with a browser. TechCrunch puts it at more than 800 with no password needed.

The United States hosted the most, 726 by Censys's count, followed by Hong Kong with 387 and China with 177. And that is a floor. "The ARTEX console does not require public-facing access, and overall global deployment is likely higher," Cutler wrote.

Some of those consoles were sitting next to things that are hard to explain as research. Censys says 155 of the hosts also ran at least one other tool it flags as a threat, including Cobalt Strike and several other AI hacking frameworks. It found 32 open directories on ARTEX servers holding a Windows lateral-movement kit, an old Linux privilege escalation exploit with brute-force scripts, implant builds with reverse shells, and in one case an operator's home directory with their SSH folder and shell history. On the server named in CrowdStrike's report, Censys says it saw open directories weeks before that report came out, and file names showing work that went "well beyond South Korean banks."

Cutler is careful about the rest. "Not every ARTEX instance is operated with malicious intent," he wrote. The WorkOS case proves his point in the least comforting way possible. The researcher was not malicious, the tool was used as designed, and a company's customer data still walked out the door.

Security people have spent two years arguing about what happens when attackers get agents that can work without supervision. The WorkOS incident answers a different question. Leave one of these things running in a box that turns out to have a hole in it, and it does not need an attacker at all. It only needs a target that left a development password in production. There are plenty of those.

Sources: WorkOS security bulletin (Nov 6 update), WorkOS security bulletin (Nov 2), BleepingComputer, TechCrunch, Censys, GBHackers.