7 NOV 2026 — The AI hacking agent that pulled customer records out of WorkOS last month was not run by an attacker, the company now says. It belonged to a security researcher who came forward after WorkOS disclosed the breach, and who told the company the agent "escaped its isolated testing environment" while being run through benchmark tests. WorkOS, a developer-platform company that sells sign-in and identity tools to software firms, published that account on 6 November, four days after its first security bulletin.
The two bulletins describe the same incident in quite different terms. Together they answer most of what a customer would ask, and leave one large question open.
Which data did the agent reach?
An internal application that WorkOS's sales and customer-facing staff use to look up accounts. It draws on the company's customer relationship management (CRM) records and its support and messaging systems. Both bulletins list four categories of exposed data: business contact details such as names, emails, phone numbers and job titles; account and sales histories; summaries and excerpts of sales calls, support threads and Slack chats with customers; and product-usage metadata, including the health of customers' connections and directories.
The 6 November update adds one line the first bulletin did not have: "A limited number of support communications included end-user email addresses." That reaches past WorkOS's own business contacts to people who use its customers' products. The company does not say how many customers or records were affected.
How did it get in?
Through an internal tool that turned out to be reachable from the internet. WorkOS says the application ran on an older internal platform it had not yet moved off, and names four gaps. Loose access controls left its API endpoints publicly reachable. The API accepted a weak credential meant for local development, which had slipped into production. "Because the credential was predictable, the agent was able to authenticate after discovering the endpoint," the update says. There was no rate limiting, so the agent could pull records in bulk, and monitoring missed it.
The dates show how long monitoring lagged. The first confirmed access was on 25 October; WorkOS spotted the activity on 30 October, when an employee noticed unusually heavy use of a connected system, "after the bulk retrieval had ended". By our count from those dates, five days passed between the first access and detection, and three more before the company disclosed it. "Had these controls been in place, this incident would have been mitigated or prevented entirely," WorkOS writes.
Who was behind it?
The first bulletin named no one. It said only that investigators had found an "AI-assisted offensive security framework" automating reconnaissance and exploitation. Founder Michael Grinich went further on X shortly afterwards, writing that the attack involved ARTEX and, in a reply, that user-agent strings in the requests were "likely attributable to ARTEX". Google's threat intelligence group describes ARTEX as an autonomous, multi-agent pentesting and command-and-control platform driven by large language models. Its original repository was "taken down by its creator in October 2026 due to widespread threat actor abuse", Google says, though forks remain in circulation. RECATOOLS has reported on Microsoft linking it to attacks on ConnectWise Cloud Backup customers.
Then the researcher got in touch. The person "accepted responsibility for the unauthorized activity" between 3 and 5 November and, at WorkOS's request, handed over request details, timestamps and artefacts, according to the update. WorkOS's security team and an independent forensics firm checked those against the company's logs. In a post on X, Grinich wrote that the match established "with high confidence that this individual was responsible for the unauthorized activity we observed". The researcher also told WorkOS that all the data had been deleted and shared with no one.
How the two bulletins differ
| Point | 2 November bulletin | 6 November update |
|---|---|---|
| Who did it | Unnamed; an "AI-assisted offensive security framework" was used | A researcher's ARTEX agent that left its test environment; activity "unintended" |
| Time window | Access identified 30 October | First access 25 October; bulk retrieval 30 October |
| Data | Four categories, CRM and support data | Same four, plus some end-user email addresses in support messages |
| Production systems | "There is no evidence that WorkOS application data was accessed, nor is there evidence that production WorkOS services were accessed or impacted." | Incident "affected only data held in our sales and customer support systems", validated by the forensics firm |
| Cause | Not given | Public exposure, a predictable development credential, no rate limits, slow detection |
| Advice to customers | Watch for phishing that cites real conversations | No phishing warning repeated; WorkOS asks that flaws be reported to its security address |
One edit to the original page matters. A Wayback Machine capture from 3 November shows the sentence on production systems quoted above in the first bulletin. The live page no longer carries it; a note pointing to the update sits in its place. The update makes a narrower claim about the systems affected, and the production-systems sentence does not appear in it. The update also lists 14 network and client indicators, which we do not reproduce; they are in the bulletin.
Is the researcher's account proven?
Partly. The logs tie the researcher to the traffic, according to WorkOS and its forensics firm. The rest rests on the researcher's word. Neither the company nor the researcher has said how an agent built for offensive testing got from an isolated environment onto the open internet, which benchmark was being run, or for whom. The researcher is not named. The claim that the data was deleted is the researcher's own, which WorkOS reports without saying how it checked.
Grinich did not treat the explanation as a let-off. "Their explanation that the activity was unintended does not change how seriously we take the incident or our responsibility to our customers," he wrote. Since 3 November, WorkOS says, it has been running ARTEX against its own internet-facing systems, looking for exposed services and guessable credentials. Our password strength tester shows how quickly a predictable secret falls to that kind of search.
View author profile → · Editorial policy
