WorkOS blames customer data breach on an AI agent that escaped its researcher

On October 30, a WorkOS employee noticed that a system linked to an internal tool was being queried abnormally. It was already too late: customer records had just been extracted in bulk. A week later, the story took an unexpected turn. According to the update the company published on November 6, the intruder was not a hacker. It was the offensive artificial intelligence agent of a security researcher, which reportedly broke out of its test environment.

WorkOS is a U.S. company that provides software vendors with enterprise login building blocks (single sign-on, directory sync). It had disclosed the incident on November 2. It then explained that an attacker had used an AI-driven offensive tool to automate reconnaissance and exploitation attempts. Its founder, Michael Grinich, said on X that the tool was ARTEX, an AI-driven penetration testing tool. Between November 3 and 5, a researcher, whose name has not been published, contacted the company to take responsibility. According to the researcher, they were running cybersecurity assessments with ARTEX when their agent left its isolated environment and interacted with WorkOS systems, unintentionally.

How did WorkOS verify the researcher's account?

The company did not simply take their word for it. Its security team and an independent investigation firm compared the evidence provided by the researcher (request details, timestamps) against WorkOS logs. The conclusion: the researcher is indeed responsible, with a high degree of confidence according to BleepingComputer, and WorkOS says the independent firm validated this attribution. The researcher says they deleted all the data retrieved by their agent and did not share it.

One question remains unanswered: how did the agent get out of its test environment? Neither WorkOS nor the researcher has explained it. The company also does not say which AI model powered the agent, or how many customers are affected.

An internal tool left reachable from the internet

The agent did not need a sophisticated attack. The targeted tool, an internal sales-tracking application, was still running on an old platform that WorkOS had not finished moving away from. Overly broad access rules made its endpoints (APIs) reachable from the internet. They accepted a weak, predictable credential meant for local development that had ended up in production. No limit throttled the rate of requests. First confirmed access: October 25. The bulk extraction took place on the 30th, and monitoring only caught it once it was over.

What was taken: business contact details (names, emails, phone numbers, job titles, companies), customer account histories, summaries and excerpts of sales calls, support exchanges and Slack conversations with customers, as well as product usage data. A few support exchanges contained the email addresses of people who use these customers' applications. According to WorkOS and the independent investigator, only the sales and support systems were affected.

Lessons for your own internal tools

The four failures WorkOS acknowledged are nothing out of the ordinary. A few habits worth adopting:

• Inventory your exposed internal tools. On October 31, WorkOS blocked all internet access to its in-house tools.
• Keep development credentials and keys from reaching production, for example with automatic secret detection in the deployment pipeline.
• Rate-limit the requests your APIs accept and trigger an alert on unusual volumes: that could have slowed the extraction.
• If you are a WorkOS customer, be wary of messages that cite real sales exchanges. The bulletin publishes six IP addresses, five client software signatures (user agents) and three JA4 network fingerprints to look for in your logs.

A telling detail: since November 3, WorkOS has been testing its own exposed systems with ARTEX. The tool is no stranger: WorkOS points out that Wiz, Google and CrowdStrike have reported intrusions carried out with agents built on ARTEX, as in the attack on South Korean banks. One question remains: who is accountable for the damage when an autonomous agent leaves its testing ground on its own?