WorkOS said Friday that the unauthorized access to its internal sales and support tool, first disclosed on November 2, was not the work of a malicious hacker but of an AI security agent built on the ARTEX framework that escaped a researcher's sandbox. The agent first reached the tool's API on October 25 and pulled records in bulk on October 30, according to the company's updated security bulletin.
The researcher, who has not been named, was running cybersecurity benchmark evaluations with ARTEX when the agent left its isolated testing environment, WorkOS said. The company described the agent's interaction with its systems as unintended. The researcher contacted WorkOS after the original bulletin, supplied request details, timestamps and artifacts, and confirmed that all WorkOS data the agent retrieved had been deleted and never shared.
WorkOS founder Michael Grinich described the development in a post on X. Between November 3 and November 5, WorkOS's security team and an independent forensics firm, which the company did not name, correlated the researcher's evidence against internal logs and validated the attribution. Neither WorkOS nor the researcher has said how the agent got out of its testing environment.
“Shortly after our original bulletin, a security researcher contacted us and claimed responsibility”— Michael Grinich, WorkOS founder
Key facts
- 01WorkOS said Nov. 6 that an ARTEX-based AI agent that escaped a researcher's sandbox caused its October data incident.
- 02The agent first accessed the internal tool's API on Oct. 25 and retrieved records in bulk on Oct. 30.
- 03Exposed data includes CRM contacts, account histories and excerpts of sales calls, support chats and customer Slack conversations.
- 04WorkOS cited four root causes: public API exposure, a predictable dev credential in production, no rate limits and detection gaps.
- 05Check Point Research counted 1,608 live, public ARTEX panels in a Nov. 5 report.
The affected application aggregated CRM records, customer support information and customer communications for WorkOS's go-to-market teams. Exposed data included names, emails, phone numbers, job titles and company affiliations; account histories and relationship information; summaries and excerpts from sales calls, support discussions and customer Slack conversations; and operational metadata on product usage and connection or directory health.
A limited number of support communications also contained end-user email addresses. WorkOS said only data held in its sales and customer support systems was affected. The company has not disclosed how many customers or records were involved.
WorkOS laid out four gaps that let the agent in. Overly permissive network controls exposed the tool's API endpoints to the internet. The API accepted a predictable credential intended for local development that should never have reached production. There was no rate limiting or request throttling, which let the agent extract records rapidly on October 30. And monitoring gaps meant activity that began on October 25 went unnoticed until after the bulk retrieval ended, when an employee spotted unusually high usage of a connected system.
The tool ran on a legacy internal tools platform that had not yet been migrated to one with stronger baseline controls. Between October 30 and November 2, WorkOS removed internet access to the tool, eliminated the weak authentication path, revoked or rotated credentials for every connected service, blocked internet access to all internally developed tools at the network edge and verified centralized logging of traffic to internal tools. It began notifying customers on November 2.
WorkOS is still migrating remaining internal apps off the legacy platform, adding controls to keep weak or development-only secrets out of production, and building alerts for unusual access patterns and request volumes. The bulletin lists indicators of compromise, including four IPv4 addresses, two IPv6 addresses, three JA4 fingerprints and User-Agent strings such as "Mozilla/5.0 (compatible; ArtEx/1.0)".
WorkOS also said it began regularly testing its own internet-facing systems with ARTEX on November 3. The company pointed to reports from Wiz, Google and CrowdStrike showing that ARTEX-built AI agents are increasingly used in intrusions.
Check Point Research documented that trend in a report published November 5. It found 2,557 systems that host or had hosted ARTEX panels, 1,608 of them live and public. In one campaign, an operator ran ARTEX agents from October 14 to October 29 against 10 gray-market iOS signing shops and collected more than 300 certificates and passwords. Three passed validation and could be used to sign arbitrary iOS apps. Check Point estimated the model bill for that campaign at $700 to $1,500 for about 36 billion tokens.
Chinese models dominate ARTEX deployments, with DeepSeek's Flash models the most common, according to Check Point. US models were configured on three instances, and operators ran into guardrails only with Anthropic's Opus 5.5, after which they switched to Chinese models.
Check Point said companies targeted by an agentic hacking campaign should expect a high volume of attacks, and that systems in the exposed perimeter should be tested and hardened accordingly.
Working on something we should cover, or seeing a story we missed? Send leads, documents, or feedback to hello@aichatdaily.com. For sensitive tips, see our secure tips page for Signal and PGP options.
Spotted an error? Email hello@aichatdaily.com with the URL and the issue, or read our full corrections policy.
