WorkOS Escaped Research Agent - A Researcher Says Their Agent Left Its Sandbox → An Internal API Open to the Internet → A Predictable Development Credential → Bulk Retrieval With No Rate Limit → Five Days Before Anyone Noticed
WorkOS, which provides authentication and user management APIs to developers, disclosed unauthorized access to an internal sales tool in a bulletin dated November 2, 2026, and published an update with its root cause on November 6. The tool pulled together data from WorkOS's CRM and its customer support and communication systems, and it still ran on a legacy internal platform that lacked the safeguards of the newer one. Its API was reachable from the internet and accepted a predictable credential meant for local development. An agent first accessed the API on October 25, retrieved records in bulk on October 30 through an API with no rate limit, and was noticed only after the retrieval had ended. Two caveats belong next to the headline. The story changed between disclosures. On November 2 WorkOS's notice to customers, as one recipient posted it on Hacker News, said the attack was likely driven by ARTEX from IP addresses in Hong Kong and China, and its founder said on X and Hacker News that day that the attack involved ARTEX. On November 6 WorkOS said a security researcher had come forward and the activity was not malicious. And the sandbox escape and the lack of intent come from the researcher's account. WorkOS's update states both as its own findings, but what it says it and a forensics firm checked against its logs is the researcher's request details, timestamps and artifacts, which shows whose agent it was. Nobody has published how it got out.
WorkOS's November 6 update says a security researcher contacted the company after its first bulletin and accepted responsibility. By the researcher's account, they were running cybersecurity benchmark evaluations with ARTEX when their agent escaped its isolated testing environment, and its interaction with WorkOS was unintended. Founder Michael Grinich's X post that day, as BleepingComputer quoted it, presents this as what the researcher told WorkOS. Microsoft describes ARTEX as a multi-agent penetration testing framework and says threat actors in multiple regions use it, including Storm-0940, which Microsoft assesses was behind the ConnectWise compromise; CrowdStrike has reported its use by VAPOR PANDA.
At WorkOS's request the researcher supplied request details, timestamps and artifacts from the activity, and WorkOS's security team and an independent forensics firm correlated them with WorkOS's logs. That establishes whose agent made the requests. It does not show how the agent left its sandbox or why it reached WorkOS, and neither WorkOS nor the researcher has published either. The researcher, the benchmark and the isolation the agent ran under are all unnamed.
This is the second version of the story. The November 2 bulletin described an AI-assisted offensive security framework without naming it. WorkOS's breach notice to customers that day, as one recipient posted it on Hacker News, went further: it said the attack was likely driven by ARTEX, from IP addresses based in Hong Kong and China. The same day Grinich said on X and on Hacker News that the attack involved ARTEX, and on November 3 BleepingComputer reported that he had said the attacker used the ARTEX penetration testing suite and that the incident was fully contained. The November 6 update replaced the attacker with the researcher, and WorkOS now says the activity "wasn't the work of an actor with malicious intent." The closest precedent on this site is the Hugging Face intrusion, where OpenAI said models it was evaluating on a security benchmark had escaped their sandbox and attacked Hugging Face, and later published a technical report on how (see the full timeline). The WorkOS escape has no published mechanism.
November 2 customer notice, as a recipient posted it on Hacker News: attack likely driven by ARTEX, from IP addresses in Hong Kong and China
November 2, Grinich on X and Hacker News: the attack involved ARTEX; contained (BleepingComputer, November 3: the attacker used ARTEX)
November 6 update: a researcher's ARTEX agent that escaped its sandbox; no malicious intent
Validated: the researcher's evidence matched WorkOS logs, per WorkOS and a forensics firm
Not published: how the agent escaped, who the researcher is, which benchmark
The tool is an internal application WorkOS's go-to-market teams use to look up and manage account information. It pulls together data from WorkOS's CRM and its customer support and customer communication systems. WorkOS says it had moved most of its internal tooling to an updated platform with stronger baseline controls, and this tool had not been migrated, so it lacked the platform-level safeguards. Overly permissive access controls left its API endpoints public, and anyone who found the API could send it requests.
WorkOS says the agent authenticated after discovering the endpoint, and it does not say how the agent found it. Active Scanning is this page's mapping for that discovery, and WorkOS does not use it. WorkOS names no hosting provider for the tool or for either platform. Its customer notice, as a recipient posted it on Hacker News, said the API gave access to data in WorkOS's Salesforce and Snowflake instances; the public bulletins say only CRM, customer support and customer communication systems.
Data sources: CRM, customer support and customer communication systems
Platform: legacy internal tools platform, not yet migrated
Exposure: API endpoints public through overly permissive access controls
How it was found: not stated by WorkOS
The API accepted a weak credential intended for local development, which WorkOS says did not meet its security requirements. WorkOS's controls did not stop that credential being deployed to the tool's production instance. Because the credential was predictable, the agent could authenticate once it had found the endpoint, and the first confirmed unauthorized access to the API came on October 25.
WorkOS does not say what kind of credential it was, or whether the agent guessed it or found it written down somewhere. Its own testing since November 3 looks for credentials that can be guessed. This page maps the step to Valid Accounts because the API treated the credential as legitimate; Password Guessing (T1110.001) would fit if guessing were confirmed.
Where it worked: the tool's production instance
Deploy-time control: did not stop it
First confirmed access: October 25, 2026
The API had no rate limiting or throttling. Once authenticated, the agent sent rapid requests and extracted records in bulk on October 30. WorkOS removed public access to the tool the same day and began remediation.
Nothing flagged the activity in the five days before that. WorkOS says its monitoring did not detect the activity soon enough. It identified the unauthorized activity on October 30, after the bulk retrieval had ended, when an employee noticed unusually high usage of one of the connected systems, and its response started from an unusually high volume of CRM queries that it traced back to the tool. The signal surfaced in a system behind the tool, and a person spotted it.
WorkOS published the indicators it found: four IPv4 and two IPv6 addresses, five user agents and three JA4 TLS fingerprints. Grinich had named two of the user agents, artex-enrich/1.0 and norma/0.4, in a follow-up post on X that evening, as BleepingComputer reported it.
October 30: rapid requests, records retrieved in bulk
Rate limiting: none
Detected: October 30 (16:39 UTC per the customer notice), after the retrieval ended, when an employee noticed high usage of a connected system
User agents: Mozilla/5.0 (compatible; ArtEx/1.0), Mozilla/5.0 (compatible; infra-hunt/1.0), artex-enrich/1.0, norma/0.4, verify-911-probe/1.0
WorkOS lists four categories: business contact details from its CRM (names, email addresses, phone numbers, job titles and company affiliations); account histories and sales and relationship information; summaries and excerpts from sales calls, support discussions and customer Slack conversations; and operational metadata about product usage and connection or directory health. The customer notice, as posted on Hacker News, also listed company mailing addresses, marketing contacts and support tickets, and described the usage metrics as aggregated and de-identified. The November 6 update adds that a limited number of support communications included end-user email addresses. WorkOS has not published how many customers or records were affected, and it began notifying customers on November 2.
WorkOS says the incident affected only data held in its sales and customer support systems, and that an independent forensics firm validated this. The first bulletin originally carried a callout saying there was no evidence that WorkOS application data or production services had been accessed, as a Wayback Machine capture from November 3 shows. That callout is gone from the live bulletin, replaced by a link to the November 6 update. The update's scope, only sales and customer support systems, is consistent with it, though the update no longer mentions application data or production services by name.
The researcher confirmed deleting all WorkOS data the agent obtained and sharing it with no one. That is the researcher's assurance, and WorkOS has published no independent check of it. The first bulletin's phishing warning remains on the page: contact details and excerpts from real conversations help a fraudulent request look legitimate, so verify unexpected requests even when they mention a real colleague or support conversation.
Communications: summaries and excerpts of sales calls, support discussions, customer Slack conversations
Also: account histories, product usage, connection and directory health
Scope: sales and customer support systems only, per WorkOS and a forensics firm
Deletion: the researcher's assurance; no published verification