An AI Attack Framework Got Into WorkOS's Sales Tool. It Held Customers' Slack Excerpts

• Book: AI Agents Pocket Guide
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

---

WorkOS sells SSO, directory sync and audit controls to "thousands of SaaS companies", according to RuntimeWire. On November 2 it published a security bulletin about unauthorized access to an internal application its sales team uses. The attacker used "an AI-assisted offensive security framework to automate reconnaissance and exploitation attempts", the bulletin says.

The contact list is the part people will skim past. The part to read twice is the third bullet of what that app held: "Summaries and excerpts from sales calls, support discussions, and customer Slack conversations" (WorkOS).

What WorkOS says was in the sales tool

The bulletin lists four kinds of data:

• Business contact details from CRM systems: names, email addresses, phone numbers, job titles and company affiliations.
• Account and relationship information, including customer account histories.
• Summaries and excerpts from sales calls, support discussions and customer Slack conversations.
• Operational metadata: product usage and connection or directory health information.

WorkOS's notice to customers, reposted on Hacker News, adds detail the public bulletin leaves out. It dates detection to October 30 at 16:39 UTC, says the attacker reached an internal API used by sales and marketing tools, which gave access to Salesforce and Snowflake data, and says the attack was likely driven by ARTEX, with traffic from IP addresses in Hong Kong and China. It also says: "We have no evidence that your application data was accessed." A user of the site posted it there, not WorkOS, and WorkOS hasn't confirmed the detection time, the Salesforce and Snowflake detail or the IP locations on its own site.

In the same thread, WorkOS CEO Michael Grinich wrote: "WorkOS's production systems are secure. No customer platform data was accessed" (Hacker News). He also disclosed the incident on X on November 2, and that post said ARTEX was involved, RuntimeWire reports.

WorkOS says it disabled external access to the affected application, is reviewing access controls on its internal tools, and has hired an independent forensics and incident response firm. The review of affected records is ongoing, and WorkOS says it will contact affected customers directly (WorkOS).

ARTEX, the framework named in the notice

ARTEX is not new to defenders. Wiz described it on October 22 as "an open-source autonomous penetration testing framework" that a Chinese developer published on GitHub in July 2026. The developer made it closed-source on October 8, after the code had more than 12,000 forks.

Google Threat Intelligence Group and Mandiant published their own analysis on October 30, the day WorkOS detected its incident. They describe ARTEX as "an autonomous, multi-agent LLM-driven pentesting and offensive command-and-control (C2) platform" that splits the attack lifecycle across "six specialized sub-agents" and calls "APIs from frontier and open source models". Google also lists variations, including a localized one called ScopeWeaver and a commercial version, ARTEX PRO.

Google says the actor it tracks as UNC7228, which overlaps with Storm-0940, typically went "from their first compromised account to deep system access in around four hours and in one case as rapidly as 15 minutes" (Google Cloud). Individual execution sequences ran in bursts of 2 to 25 seconds.

ARTEX splits an intrusion across six sub-agents, per Google's analysis. WorkOS's customer notice says its incident was likely driven by it.

Wiz said the ARTEX activity it saw overlaps with Microsoft's report on Storm-0940, which Wiz describes as "a Chinese-state aligned actor", and that it focused on IT and software vendors, especially identity providers. Neither Wiz nor Google mentions WorkOS, and WorkOS hasn't named an actor. Don't read the WorkOS incident as attributed to any group yet.

The contact list is the smaller problem

A list of names and emails gets you generic phishing. Call notes and Slack excerpts get you phishing that knows your integration, your account manager's name and the bug you reported last month. WorkOS's own guidance points the same way: contact details and past conversations can make fraudulent requests look legitimate, so "verify unexpected requests before sharing sensitive information or taking action" (WorkOS).

For an identity vendor, the requests to watch are the ones that change who can sign in to your app, like a new SAML certificate or a "reconnect your directory" link. That's my reading of the risk, not something WorkOS has said. Either way, make any SSO config change through the dashboard you already log in to, never through a link in a message.

Then look at what your team has pasted into shared vendor channels and support threads. Developers paste logs, config files and, sometimes, a key "just to reproduce it". WorkOS hasn't said whether any secrets were in the excerpts it lost, and its bulletin doesn't mention API keys. You don't need its answer to check your side. Export the shared channel or ticket history and scan it with TruffleHog:

# Scan an exported channel or ticket history
# for anything that looks like a credential.
trufflehog filesystem ./vendor-channel-export

Anything it finds that is still live gets rotated, whoever you shared it with.

The bulletin lists summaries and excerpts of sales calls, support discussions and customer Slack conversations among the data involved.

If you run internal tools, harden them like production

The WorkOS target was a go-to-market app, not production. Internal go-to-market apps often get less hardening than the product itself. Wiz lists what ARTEX operators probed for: JavaScript source maps, runtime config files, Swagger/OpenAPI docs, password-reset endpoints and self-signup with disposable email addresses.

The source-map check is one command:

# Print the first bytes of the map, if it is served
curl -s https://app.example.com/assets/main.js.map \
  | head -c 40

If you get back JSON that opens with a "version" field, the map is public and anyone can read your original front-end source, routes included. Don't go by the status code alone: many single-page app hosts answer every unknown path with index.html and a 200. Swap in a real bundle path from your build output.

Google's recommendations are short enough to paste into a ticket:

• "Restrict all admin APIs, consoles & CI/CD to trusted networks"
• "Migrate to short-lived workload credentials; eliminate secrets"
• "Monitor unusual bursts of password resets, account creation, credential additions, permission changes, or other lifecycle activity."
• Watch server egress to previously unseen destinations, especially webhook services. In the activity Google tracked, ARTEX posted results to rotating webhook.site URLs, 491 of them.

What we still don't know

WorkOS hasn't said how the attacker first got in. A commenter in the Hacker News thread asked about the initial vector and lateral movement, and that question had no answer there at the time of writing. There's no word yet on how many customers' records were in the tool, and the ARTEX attribution comes from WorkOS's own investigation, with no independent confirmation yet. The forensics firm's findings, and the direct notices WorkOS says are coming, should fill those gaps.

If you're a WorkOS customer, watch for that direct notice. When it arrives, compare what it lists against what your team shared with the vendor, and rotate any credential that turns up in it.

---

If this was useful

ARTEX is an agent system pointed the wrong way: sub-agents, tool calls and model APIs chained toward a goal, at a speed no human operator keeps up with. The AI Agents Pocket Guide covers how those loops are built and where to put guardrails, which helps whether you're building agents or defending against one.

I also build Hermes IDE, a desktop app for running coding agents side by side. Each agent uses its own CLI sign-in and Hermes never asks for your tokens. It's free, source-available, and on GitHub. Hermes IDE is not affiliated with Nous Research, WorkOS or any vendor named here.