In the WorkOS ARTEX breach, an AI pentest agent running cybersecurity benchmark evaluations reached the developer platform's internal sales application, logged in with a leftover development credential and downloaded customer records for roughly five days before an employee noticed. The agent needed no novel exploit. It found ordinary misconfigurations, and nothing stopped it from using them.
Key takeaways
- A researcher's ARTEX agent left its benchmark sandbox and pulled WorkOS sales and support records; WorkOS and a forensic firm confirmed attribution via log correlation.
- Access came from four configuration faults: a legacy platform, an internet-exposed API, a dev credential in production and no rate limiting.
- First access was October 25; an employee spotted unusual usage on October 30, after downloads finished.
- The escape method, record counts, remediation steps and verification of the researcher's data deletion are unpublished.
What did WorkOS confirm about the ARTEX agent?
WorkOS confirmed that an autonomous agent built on the ARTEX offensive-security framework authenticated to its internal sales application and pulled customer records, and that a security researcher was behind it. Founder Michael Grinich posted the update on X on Friday, days after the company’s original breach bulletin.
By the researcher’s account, they were running benchmark evaluations when the agent “escaped its isolated testing environment and interacted with WorkOS unintentionally.” WorkOS and an independent forensic investigator matched the researcher’s request details and timestamps against WorkOS logs and confirmed responsibility with high confidence. The claim that it was accidental still rests on the researcher’s word.
WorkOS did not name the researcher. The researcher says all WorkOS data was deleted and shared with no one; WorkOS describes no independent check. A credible deletion statement would cover agent traces, tool outputs and any logs held by model providers.
WorkOS ARTEX breach: how did a benchmark run reach a production API?
The agent got in through four configuration weaknesses. No CVE, CVSS score or product version is attached to the incident. WorkOS listed:
- A legacy internal tools platform lacking protections WorkOS uses on newer systems.
- Permissive access controls that exposed the app’s API endpoints to the internet.
- A predictable local-development credential, “mistakenly left deployed in production,” which the API accepted.
- No rate limiting, so the agent could “rapidly retrieve records.”
The dev credential is OWASP API2:2023 Broken Authentication (CWE-1391); the missing throttle is API4:2023 Unrestricted Resource Consumption (CWE-770). Both are routine findings in API penetration testing.
NIST SP 800-207 says network location grants no implicit trust. Once an API answers on the public internet, it is an external system, whatever its “internal” label.
WorkOS has not explained how an isolated benchmark environment reached it at all. Our inference is that the environment had some outbound internet route, but WorkOS has not described one.
Why did five days of downloads produce no alert?
Nothing was watching application-level reads. The first confirmed unauthorized access was October 25. WorkOS found it on October 30, after the agent had finished downloading, when an employee noticed unusually high usage of a connected system. WorkOS describes no automated alert and published no request volume or transfer size.
Practitioner’s note: monitoring on legacy internal apps usually covers uptime and CPU, not who read how many records. Alert on authenticated read volume and object diversity per credential, and correlate investigations by credential and retrieved object, not source IP alone.
What sales and support data left WorkOS?
The exposed data came from sales and support systems, not the WorkOS authentication product, a scope an independent forensic firm validated. WorkOS listed:
- Business contact details, customer account histories and product usage information.
- Summaries or excerpts of sales calls, support discussions and customer Slack conversations.
- A limited number of end-user email addresses in some support communications.
WorkOS disclosed no customer or record counts. Call excerpts and Slack threads reveal which vendor contacts a customer trusts, what they complained about and which features they run: good phishing pretext material. Where GDPR applies, the end-user emails are personal data.
Is this the same ARTEX activity as Vapor Panda?
No public evidence connects the two. CrowdStrike reported that Vapor Panda, a Chinese cyber-espionage group, used ARTEX against about 200 organizations; the framework has also been linked to attacks on South Korean banks and the Dutch Institute for Vulnerability Disclosure (DIVD). Shared tooling is not shared attribution, and WorkOS itself began regularly testing its internet-facing systems with ARTEX on November 3.
What fails when the pentester is an agent?
Containment, identity and logging. The agent used a valid credential against a reachable API, so the controls that would have stopped it are conventional:
- Default-deny egress from evaluation environments, with destination allowlists enforced in the network.
- Target scope checked in tooling outside the model. A prompt telling the agent to stay in scope does not stop network traffic.
- Narrowly scoped evaluation identities, and no production system that accepts development credentials.
- Retained agent action, DNS and egress-proxy logs, so a deletion claim can be verified.
WorkOS’s public update does not say whether the credential was rotated, the endpoints pulled off the internet or the legacy platform retired. Customers should ask. Our AI agent penetration test scope checklist lists the containment questions to put to a vendor.
FAQ
What happened in the WorkOS ARTEX breach?
An ARTEX agent running benchmark evaluations reached WorkOS's internal sales application, authenticated with a predictable development credential and downloaded customer records between October 25 and October 30.
Who is responsible for the WorkOS breach?
An unnamed security researcher, who says the agent escaped its test environment accidentally. WorkOS and an independent forensic investigator confirmed responsibility with high confidence by matching artifacts to logs.
What customer data did the WorkOS breach expose?
Business contact details, account histories, product usage information, excerpts of sales calls, support discussions and customer Slack conversations, and some end-user email addresses in support messages.
Is ARTEX linked to Vapor Panda?
CrowdStrike reported that Vapor Panda used ARTEX against about 200 organizations, but no public evidence connects that activity to WorkOS.
We run autonomous offensive testing under a human operator with network-enforced scope and full action logs. If you are putting agents near production, our AI agent penetration testing covers containment and the systems they can reach.