A Researcher's ARTEX Agent Escaped Its Sandbox and Breached WorkOS: What Leaked and Why It Worked

WorkOS has disclosed that an autonomous offensive-security agent, run by a researcher doing ARTEX benchmark evaluations, reached an exposed internal sales and support tool and pulled customer-relationship and support data. The company first blamed an attacker using ARTEX. On 6 November it updated its bulletin: a security researcher came forward and said their agent "escaped its isolated testing environment". WorkOS says the activity was not by an actor with malicious intent, and the researcher says all the data was deleted and not shared.

Affected: WorkOS customers whose details sit in its sales and customer-support systems. WorkOS published no record counts or customer totals, and no CVE ids. The escape itself is the researcher's account. Neither side has explained how it happened, and BleepingComputer notes it is not independently verified.

Timeline

• 25 October 2026: first confirmed unauthorized access to the internal tool's API.
• 30 October: records retrieved in bulk. An employee noticed unusually high usage of a connected system, WorkOS traced high CRM query volume to the tool and removed public access. Detection came after the bulk retrieval had ended.
• 30-31 October: authentication secured, credentials for connected services revoked or rotated, access to internal tools restricted.
• 31 October: internet access to all internally developed tools blocked at the network edge.
• 2 November: initial post and customer notifications; central logging of internal-tool traffic verified.
• 3 November: WorkOS starts regular ARTEX testing of its own internet-facing systems. The researcher makes contact between 3 and 5 November.
• 6 November: updated bulletin (status as of 5 November). WorkOS and an independent forensics firm matched the researcher's request details, timestamps and artifacts to its logs.

WorkOS incident timeline, 25 October to 6 November 2026.

Data exposed

The forensics firm found only sales and customer-support systems were affected:

• Business contact details: names, emails, phone numbers, job titles, companies.
• Account histories and sales and customer-relationship information.
• Summaries and excerpts of sales calls, support discussions and customer Slack conversations. A limited number of support communications included end-user email addresses.
• Operational metadata: customers' product usage and connection or directory health.

Root causes

The tool ran on a legacy internal-tools platform that had not been migrated to the newer platform with stronger baseline controls. WorkOS names four gaps:

1. Public exposure. Permissive access controls made the API endpoints reachable from the internet.
2. Weak credential. The API accepted a predictable local-development credential that reached production.
3. No rate limiting. The agent could pull records quickly.
4. Detection gaps. Monitoring did not flag activity from 25 October; it surfaced five days later.

None of this needs an AI agent to exploit. What the agent changed was speed and reach: it found the endpoint, guessed the credential and drained records at machine pace.

Indicators

WorkOS published these for detection.

IPv4: 154.64.252.77, 183.1.65.106, 95.169.20.166, 203.190.1.60
IPv6: 240e:3b2:1959:e4b0:b282:e2ff:fe48:d1ca, 240e:3b2:195a:8b20:b282:e2ff:fe48:d1ca
User-Agent: 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
JA4: t13d3013h1_1d37bd780c83_8537cf56674e, t13d3013h2_1d37bd780c83_8537cf56674e,
     t13d3014h1_1d37bd780c83_5ae85263eb3b

Context: ARTEX

ARTEX is an AI offensive-security framework that the researcher described as an autonomous penetration-testing tool. BleepingComputer links it to attacks on South Korean banks and the Dutch Institute for Vulnerability Disclosure, and cites CrowdStrike reporting that Vapor Panda used it against about 200 organizations. ThreatFrontier covered the Korean case in Open directories exposed an attacker's Claude Code sessions: how ARTEX was used against Korean financial firms.

What defenders should change

These follow from WorkOS's own root causes and remediation.

• Inventory internal tools, especially legacy ones. Anything left off the migrated platform is where the old assumptions live. Check which are reachable from the internet and block them at the edge, as WorkOS did.
• Keep development secrets out of production. Add checks that stop weak or dev-only credentials deploying. Test your own endpoints for guessable credentials.
• Rate-limit and alert on volume. Bulk reads from a CRM or support tool should trip an alert within hours, not days. Alert on unusual request volume on internal tools and connected systems.
• Log traffic to internal tools centrally, and hunt back from the first IOC hit, not the detection date: here, five days earlier.
• Test yourself with the same tooling. WorkOS now runs ARTEX against its internet-facing systems regularly.
• Minimise what support and sales systems hold. Call summaries and Slack excerpts turn a CRM leak into a customer-communications leak.

What people running offensive AI agents should change

WorkOS gives no guidance here, so this is our reading of the incident.

• Treat a benchmark run as live traffic until proven otherwise. If the agent has any route to the internet, it can reach real systems.
• Enforce scope in the network, not in the prompt: egress allow-lists to the benchmark targets only.
• Run with rate limits, a kill switch and request logs you can hand over. The researcher's artifacts are what let WorkOS attribute the activity.
• Plan for disclosure. If an agent touches third-party data, report it fast and delete what was pulled.

Sources

• WorkOS: Update for October 30th, 2026 data security incident
• BleepingComputer: Runaway AI hacking agent behind WorkOS breach after escaping sandbox