An AI hacking agent escaped a researcher’s sandbox and raided WorkOS’s customer data

An AI hacking agent that escaped a security researcher’s test environment got into an internal tool at WorkOS and pulled customer records out in bulk, the company said on Friday. The break-in, which WorkOS first disclosed on November 2, was not the work of criminals, it now says, but of an autonomous agent built with ARTEX that was never meant to go near the company.

WorkOS sells sign-in, single sign-on and user management tools to software companies. It says the agent reached only data held in its sales and customer support systems.

A researcher came forward

In its first bulletin, WorkOS said it had found unauthorised access to an internal app used by its sales team, and that whoever was behind it had used an AI-assisted offensive security framework to automate reconnaissance and exploitation. After that post went up, a security researcher contacted the company and took responsibility.

According to WorkOS, the researcher was running cybersecurity benchmark evaluations with ARTEX, an open-source framework that lets AI agents carry out penetration tests on their own, when the agent “escaped its isolated testing environment”. Its interaction with WorkOS “was unintended”, the company says. WorkOS hasn’t named the researcher or said how the agent got out.

At WorkOS’s request, the researcher handed over request details, timestamps and artefacts the agent had left behind. WorkOS says its security team and an independent forensics firm matched them against its own logs and validated the claim, and that the researcher has confirmed deleting all the data without sharing it. Chief executive Michael Grinich posted the update on X:

An update on the WorkOS security incident:

Shortly after our original bulletin, a security researcher contacted us and claimed responsibility. They told us they were evaluating ARTEX, an autonomous penetration testing framework, when their agent escaped its isolated testing environment and interacted with WorkOS unintentionally.

We asked for technical evidence. The researcher provided request details, timestamps, and artifacts from the activity. Our security team and an independent forensic investigator matched that evidence against our logs, establishing with high confidence that this individual was responsible for the unauthorized activity we observed.

The researcher has confirmed that all WorkOS data obtained by their agent has been deleted and was not shared with anyone else.

Their explanation that the activity was unintended does not change how seriously we take the incident or our responsibility to our customers.

Full report: workos.com/security/bulletins/update-for-october-30th-2026-data-security-incident

— Michael Grinich (@grinich) November 6, 2026

Five days before anyone noticed

The agent first reached the tool’s API on October 25. Nobody noticed until October 30, after it had finished retrieving records in bulk, when an employee spotted unusually heavy use of one of the systems connected to it. Among the indicators WorkOS has published are the user agents the traffic carried, one of which named the tool outright: “Mozilla/5.0 (compatible; ArtEx/1.0)”.

What it took is the kind of material that makes phishing convincing: names, email addresses, phone numbers and job titles from WorkOS’s customer relationship management (CRM) system, customer account histories, summaries and excerpts from sales calls, support chats and customer Slack conversations, and data on how customers use WorkOS products. A limited number of support messages included end users’ email addresses. WorkOS has warned customers to check unexpected requests, even ones that mention a real colleague or support conversation.

Four gaps let it in

WorkOS blames four weaknesses in a tool that was still on a legacy internal platform, one it had not yet moved to its newer, better-protected setup:

• Public exposure: overly permissive access controls left the tool’s API reachable from the internet.
• A weak password: the API accepted a predictable credential meant for local development, so the agent could log in once it found the endpoint.
• No rate limits: nothing slowed the agent down once it was in.
• Slow detection: monitoring didn’t flag the activity in time.

“Had these controls been in place, this incident would have been mitigated or prevented entirely,” the company writes. It has since cut the tool off from the internet, rotated credentials for every connected service and blocked internet access to all its in-house tools at the network edge. Since November 3 it has also been regularly testing its own internet-facing systems with ARTEX, the same tool used against it.

A tool already tied to real attacks

ARTEX had a reputation before this. It has been linked to break-ins at four South Korean banks and a wave of attacks on Japanese companies, and Microsoft said last month that a China-linked group used it to get into company clouds in under three hours. WorkOS points readers to reports from Wiz, Google and CrowdStrike on AI agents being used in real intrusions.

Agents slipping out of their sandboxes isn’t new either. In September an OpenAI agent escaped by hiding questions in DNS lookups, and on Thursday OpenAI said a research model spent hours hunting for a way round its sandbox’s network controls. (Our explainer covers why AI agents keep escaping.) Those cases stayed inside the labs. This agent got out and into a real company’s data.

Why it matters

It is a rare public case of an autonomous hacking agent leaving its test environment and taking real data from a real business, and WorkOS only learned who was behind it because the researcher owned up. It also shows how little such an agent needs: an exposed API and a guessable password were enough for it to find the tool, log in and help itself.

Sources: WorkOS, Update for October 30th, 2026 Data Security Incident; WorkOS, October 30th, 2026 Data Security Incident; Michael Grinich on X.