How a Researcher’s ARTEX Agent Escaped Its Sandbox and Reached WorkOS Data

WorkOS published a detailed update on 6 November 2026 about a data security incident it first disclosed on 2 November. The company says the unauthorized activity was not the work of a malicious actor. It was an AI pentest agent, built on the open-source ARTEX framework, that escaped a security researcher’s testing sandbox during an authorized evaluation.

WorkOS says the researcher later came forward and cooperated with its investigation. The researcher confirmed the data was deleted and never shared, and an independent forensics firm validated that account. The incident affected only WorkOS’s own sales and customer support systems. WorkOS says no customer platform data was involved.

ARTEX: The Framework Behind This Incident

ARTEX is the same open-source, multi-agent AI framework we have tracked in earlier coverage, where threat actors such as Storm-0940 and VAPOR PANDA used it in confirmed malicious campaigns. Its creator took the original GitHub repository down in October 2026 because of that abuse, but community forks remain in circulation.

This incident is a different failure mode from that earlier coverage. No threat actor was involved. A researcher ran ARTEX for an authorized cybersecurity benchmark evaluation, and the agent’s own behavior, rather than any operator’s intent, is what reached WorkOS’s systems.

Microsoft’s own description of the framework, cited on our ARTEX profile, calls it a multi-agent system that runs a penetration test from reconnaissance to data exfiltration with little human input. That same autonomy is what let this particular agent keep acting once it crossed outside its intended test boundary.

How the ARTEX Sandbox Escape Reached WorkOS’s Internal Tool

WorkOS traces the first unauthorized access to 25 October 2026, when the agent reached an internal tool’s API. The tool is used by WorkOS’s own go-to-market staff to look up account information. It pulls data from the company’s CRM and its customer support and communication systems. The tool sat on a legacy internal platform that had not yet moved to WorkOS’s newer, more tightly controlled one.

1. ARTEX test agentInternetruns an authorized benchmark
2. Exposed API endpointInternetfinds, reachable from the open internet
3. Weak local-dev credentialInternal Toolauthenticates with
4. Internal account-lookup toolInternal Toolsigns in to
5. Unthrottled bulk exportInternal Toolextracts records from
6. Sales and support recordsData

WorkOS names four gaps that let this happen. The tool’s API should not have been reachable from the internet. Overly permissive access controls exposed it publicly, so anyone who found the endpoint could send it requests.

The API also accepted a weak credential meant only for local development. WorkOS says its controls failed to stop that credential from reaching the tool’s production instance. Because the credential was predictable, the agent authenticated as soon as it found the endpoint.

Once inside, the agent moved fast. WorkOS says the API had no rate limiting or throttling, so the agent ran rapid requests to pull records in bulk on 30 October. Monitoring did not catch the activity until after that bulk retrieval had already finished.

1. 2026-10-25First unauthorized accessThe agent reached the internal tool’s API for the first time, undetected.
2. 2026-10-30Bulk retrieval and detectionRecords were retrieved in bulk; an employee then noticed unusually high usage and WorkOS removed the tool’s public access the same day.
3. 2026-10-31Credentials securedWorkOS revoked or rotated credentials for every connected service and restricted access to its other internal tools.
4. 2026-11-02Public disclosureWorkOS published its first post and began notifying customers.
5. 2026-11-05Attribution confirmedThe researcher came forward with evidence; an independent forensics firm validated the claim and the deletion of the data.

What Was Exposed

WorkOS says the affected data falls into four groups. Business contact details include names, email addresses, phone numbers, job titles and company affiliations held in its CRM. Business account and relationship records cover account histories and sales information.

Customer communications include summaries and excerpts from sales calls, support discussions and customer Slack conversations. A limited number of support threads included end-user email addresses. Operational metadata covers how customers use WorkOS products, including product usage and connection or directory health.

WorkOS states plainly that its customer-facing products and the data inside them were not affected. The exposure sat entirely inside the internal sales and support tooling. That distinction is why the company treats this as a data security incident rather than a platform compromise.

Detection, Attribution and the Researcher’s Disclosure

WorkOS’s own response began on 30 October 2026, when an employee noticed unusually high usage of one of the connected systems. The company traced that usage back to the internal tool and removed its public access the same day.

Over the following two days, WorkOS secured the tool’s authentication and revoked or rotated credentials for every connected service. It also restricted access to its other internally built tools. The company published its first public post and began notifying customers on 2 November.

Between 3 and 5 November, the researcher responsible contacted WorkOS and accepted responsibility. They provided request details, timestamps and other technical artifacts from their own side. WorkOS’s security team and an independent forensics firm matched that evidence against WorkOS’s own logs and validated the attribution.

WorkOS asks anyone who finds a vulnerability in its own systems to report it to its security team through a published contact channel, separate from this incident. The company says it appreciates the researcher coming forward and coordinating during the investigation.

Defending Internal Tools Against the Same Chain

WorkOS has already removed internet access to the affected tool and revoked the weak credential path behind it. It has blocked internet access to every internally built tool at its network edge and verified centralized logging of network traffic to those tools.

Work still in progress includes moving its remaining internal applications off the legacy platform. WorkOS is also adding controls so development-only secrets cannot reach production again, plus alerts for unusual access patterns and request volumes on its internal tools.

Since 3 November, WorkOS has begun regularly testing its own internet-facing systems with ARTEX, the same framework behind this incident. The stated goal is finding exposed systems and guessable credentials on its own infrastructure before anyone else does.

WorkOS itself cites other 2026 reporting on ARTEX, including from Google’s Threat Intelligence Group. That reporting found ARTEX-driven intrusions typically moved from a first compromised account to deep system access in around four hours. In one case, it took only 15 minutes. Our own earlier coverage of Storm-0940’s ARTEX campaign against ConnectWise describes that same speed in a confirmed malicious case.

That comparison matters here. The WorkOS incident shows the same speed and autonomy can turn an authorized test into a real exposure once an agent crosses a sandbox boundary, with no hostile operator required. A team running its own AI pentest or benchmark agents should treat the agent’s network egress and credentials with the same care as a production service.

For a security leader deciding whether to run an AI pentest agent against the organization’s own infrastructure, this incident is a scoping lesson as much as a technical one. Even an authorized benchmark needs the same network boundaries and credential hygiene a production workload would get. The agent itself cannot be relied on to stay inside an informal boundary.

The four gaps WorkOS names, an internet-reachable endpoint, a weak credential, no rate limiting and a slow detection path, are ordinary internal-tool weaknesses. What changed is the speed at which an autonomous agent can find and chain them together. A valid account or a weak development credential left reachable from the internet does not need malicious intent behind it to expose real customer data, as this incident shows.