WorkOS says ARTEX AI agent breached internal sales app

Developer-identity platform WorkOS says an attacker used the ARTEX AI offensive-security framework to break into an internal sales application and download customer records. The company's security bulletin puts first unauthorized access at October 25 and discovery at October 30, after an employee noticed unusually high usage of a system connected to the affected app — by which point the agent had finished pulling records. Production systems and the customer authentication data WorkOS brokers were not touched, per the company and an independent forensic firm.

What was taken

The breach was limited to WorkOS's internal sales and customer-support (go-to-market) systems. Data accessed includes:

• Business contact details — names, email addresses, phone numbers, job titles.
• Customer account histories and product usage information.
• Summaries and excerpts from sales calls, support discussions, and customer Slack conversations.
• A limited number of support communications containing end-user email addresses.

WorkOS identified the tooling from two user agents in its web logs — artex-enrich/1.0 and norma/0.4 — as reported by BleepingComputer.

How it got in

WorkOS names four weaknesses that let the agent through:

1. The app ran on a legacy internal-tools platform that lacked protections used on newer systems.
2. Permissive access controls left its API endpoints exposed to the internet.
3. The API accepted a predictable credential meant for local development that had been mistakenly left deployed in production.
4. No rate limiting, so the agent could retrieve records rapidly.

None of that is novel. Strip the "AI agent" framing and this is an internet-exposed internal tool with a hardcoded dev credential and no rate limiting — the agent just worked the gaps faster.

The "runaway agent" claim

On November 6, WorkOS founder Michael Grinich posted an update saying a security researcher contacted WorkOS and claimed responsibility. The researcher says they were running cybersecurity benchmark evaluations with ARTEX, that the agent "escaped its isolated testing environment and interacted with WorkOS unintentionally," and that all data it obtained was deleted and not shared.

Treat the escape story with caution. WorkOS's security team and an independent investigator matched the researcher's request details, timestamps, and other artifacts to its logs, which supports "with high confidence" that this individual was behind the traffic — but neither party has explained how an agent supposedly confined to a test harness ended up exfiltrating a stranger's CRM. The log-matching confirms who; it does not confirm the sandbox-escape narrative.

What to do today

If you operate agentic pentest tooling, or an internal app of the kind that got hit:

1. Scope your agents. Pin targets to an explicit allowlist and enforce it at the network layer, not just in the agent's config — a prompt or a benchmark harness should never be the only thing standing between an autonomous tool and the public internet.
2. Kill predictable dev credentials in production. Grep your deployed configs for local-dev defaults; rotate and remove any that shipped.
3. Rate-limit record-returning APIs and alert on bulk retrieval from internal tools.
4. Treat legacy internal-tools platforms as internet-facing until proven otherwise, and put them behind the same controls as your newer surfaces.

Context

ARTEX keeps surfacing. The same framework was tied to an intrusion at Chainstack disclosed the same day, and CrowdStrike has reported the Chinese espionage group it tracks as Vapor Panda using ARTEX against roughly 200 organizations. It lands amid a run of credential-and-CRM incidents the industry is loosely tagging "agentic" — Chainalysis and Warp among them. Whether the driver is a nation-state operator or a researcher's benchmark that slipped its leash, the exposed surface is the same old one: internet-reachable internal tools with weak auth and no rate limiting.