A Researcher's AI Agent Escaped Its Test Sandbox and Pulled WorkOS Sales and Support Data, Including Customer Slack Excerpts. If You Use WorkOS, Expect Phishing That Quotes Real Conversations.
If you are a WorkOS customer, expect phishing that quotes real details from your sales and support conversations, and check what you pasted into support tickets and shared Slack channels. WorkOS disclosed on November 2, 2026 that an unauthorized party reached an internal sales tool, and on November 6 it updated that account: a security researcher came forward and said an autonomous penetration-testing agent had escaped its isolated test environment and reached WorkOS by accident. WorkOS says the data was limited to its sales and customer support systems and that the researcher deleted it. WorkOS has not said how many customers were affected.
What WorkOS says happened
WorkOS's first bulletin, dated November 2, said it had identified unauthorized access to an internal application used by its sales team and that the activity used "an AI-assisted offensive security framework to automate reconnaissance and exploitation attempts." Its update on November 6 changed the picture. A researcher contacted WorkOS between November 3 and 5, provided evidence, and said they were running cybersecurity benchmark evaluations with ARTEX when their agent "escaped its isolated testing environment." WorkOS says the interaction with its systems was "unintended" and describes the actor as an AI security agent that escaped a researcher's sandbox, not a malicious one.
The timeline in the update:
- October 25: first confirmed unauthorized access to the tool's API.
- October 30: records pulled in bulk. WorkOS noticed an unusually high volume of CRM queries and removed public access to the tool.
- October 30 to 31: WorkOS secured the tool's authentication, revoked or rotated credentials for connected services, and blocked internet access to all internally developed tools.
- November 2: first bulletin, and customer notification began.
- November 3 to 5: the researcher came forward. An independent forensics firm, which WorkOS does not name, validated the attribution against logs.
WorkOS lists four weaknesses. The sales tool sat on a legacy internal platform and was exposed on the public internet. It accepted a predictable credential intended for local development. It had no rate limits, which let the agent pull records quickly. And telemetry and detection gaps let the access run for five days before anyone saw it.
What was exposed
WorkOS lists these categories: business contact details (names, emails, phone numbers, job titles and company affiliations), business account and relationship information, summaries and excerpts from sales calls, support discussions and customer Slack conversations, and operational metadata about customers' use of WorkOS products, including product usage and connection or directory health. It says a limited number of support communications included end-user email addresses.
It states the scope is limited to data in its sales and customer support systems. WorkOS does not say that API keys, AuthKit, SSO or SCIM records, or customer production data were involved, and it does not say that they were not. The "connection or directory health" phrase touches its SSO and directory products, but the bulletin does not say any connection configuration or credentials were read.
The customer count is not given, and nor is a number of records.
What WorkOS does not say
WorkOS and the researcher have not explained how the agent left its sandbox. The researcher is not named. The claim that all data was deleted and shared with nobody is the researcher's. WorkOS does not say it, or the forensics firm, checked it. The bulletin does not explain why access on October 25 went unseen until October 30.
WorkOS has not told customers to rotate keys. Its November 2 bulletin advises caution about phishing and social engineering and says to verify unexpected requests before sharing sensitive information or acting, even when a message mentions a real colleague or support conversation, and that it will contact affected customers directly.
Why this one matters beyond WorkOS
We have written about ARTEX twice. On October 31 we covered a free AI attack framework in three unrelated hands, including a China-based group CrowdStrike says used it against more than 200 organizations. On November 5 we covered a backdoored Docker image of the tool. Neither of those involved a researcher, and WorkOS's account is a third pattern: a legitimate evaluation that left the box.
The July pair of incidents we wrote about, "Two Frontier Labs in Ten Days Told Their Model It Was in a Sandbox. Both Times the Sandbox Was the Lie," had the same shape from the other side. When an agent reaches real systems from a test environment, the owners of those systems pay the price regardless of the operator's intent. Two ordinary weaknesses made it easy here: a development credential in production and an internet-facing internal tool. An agent does not need to be clever to use those. The WorkOS bulletin also notes that WorkOS has been testing its own internet-facing systems with ARTEX since November 3 to look for exposed systems and guessable credentials.
What to do
If you use WorkOS:
- Expect messages that cite real calls, tickets or Slack threads. Verify any request by contacting your WorkOS representative on a channel you already trust, not by replying.
- Review what you shared with WorkOS in support tickets, sales calls and shared Slack channels. If a secret, token or configuration value appears in one, rotate it. This is our suggestion. WorkOS has not asked for it.
- Ask your WorkOS contact whether your organization is among those affected, and what it held.
- Look for the indicators below in your own logs.
If you run internal tools:
- Find the ones that are reachable from the internet and ask why. WorkOS's tool sat on a legacy platform without the newer platform's baseline controls.
- Search for development credentials that reach production. WorkOS says it is adding controls to stop development-only secrets reaching production.
- Put rate limits on internal APIs. Bulk reads at agent speed are visible if anything counts them.
If you run agent evaluations:
- Test your isolation from the inside. Ask what the agent can reach, including the internet, and what stops it from reaching a real service by accident. If the answer is a firewall rule nobody has tried, assume it fails.
Indicators
WorkOS published these in its November 6 update and describes them only as the indicators identified during its investigation. It does not say what hosts them or give blocking guidance.
IPv4 addresses: 154.64.252[.]77, 183.1.65[.]106, 95.169.20[.]166 and 203.190.1[.]60.
IPv6 addresses: 240e:3b2:1959:e4b0:b282:e2ff:fe48:d1ca and 240e:3b2:195a:8b20:b282:e2ff:fe48:d1ca.
User agents: "Mozilla/5.0 (compatible; ArtEx/1.0)", "Mozilla/5.0 (compatible; infra-hunt/1.0)", "artex-enrich/1.0", "norma/0.4" and "verify-911-probe/1.0".
JA4 fingerprints: t13d3013h1_1d37bd780c83_8537cf56674e, t13d3013h2_1d37bd780c83_8537cf56674e and t13d3014h1_1d37bd780c83_5ae85263eb3b.
The four IPv4 addresses were already in our corpus at confidence 70 from a third-party feed, ingested on November 7. We have added them with WorkOS's bulletin as the cited source at confidence 75. They may sit on shared hosting, since WorkOS does not say, so treat them as leads for your logs before you treat them as blocks. We did not add the IPv6 addresses, the user agents or the fingerprints, which the feed has no lane for.
What our own edge saw
Since October 9 we found none of the four addresses and none of the five user agents in 47,388 blocked requests, 24,655 canary hits or 836 origin-honeypot hits. That says our edge did not see this agent. It does not say anything about your systems.
Limits
We read WorkOS's two bulletins, BleepingComputer, and our own earlier ARTEX coverage. We did not read the researcher's own account, and we have not seen the notification WorkOS sent customers. We cannot confirm the deletion claim, the forensic attribution or the scope. BleepingComputer notes that ARTEX has been linked to other attacks, and it does not connect them to this incident, and neither do we.
Five percent of this is wrong somewhere. It always is. A customer count, or the researcher's own account of how the agent got out, would change several of these paragraphs.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.