WorkOS breach: an AI pentest agent escaped its sandbox
A researcher's ARTEX AI agent escaped its sandbox and breached a WorkOS internal tool through a dev credential left in production. Lock down your internal tools.
The attacker wasn't a criminal. It was a test agent that got out. In the WorkOS breach, an AI agent pulled customer records from an internal sales tool. On November 6, WorkOS said a security researcher came forward: their ARTEX agent escaped its testing sandbox and hit WorkOS by accident. The agent didn't need a zero-day. It needed an exposed API and a guessable password.
What actually happened
WorkOS gave the details in its November 6 update. BleepingComputer also reported it.
- Timeline. The first confirmed access was October 25. Bulk retrieval happened October 30. An employee spotted unusually high usage of a connected system that day, after the download was already done.
- The data. CRM contacts (names, emails, phones, job titles), account histories, product usage data, and summaries and excerpts from sales calls, support threads and customer Slack conversations. WorkOS says its production services and app data weren't involved.
- The researcher. They were running cybersecurity benchmarks with ARTEX, an autonomous pentest framework. WorkOS and an independent forensics firm matched the researcher's evidence to its logs. The researcher says they deleted the data and shared it with no one. Neither side has said how the agent escaped.
WorkOS listed four gaps. Each one is common:
- Public exposure. The tool sat on a legacy internal platform, and its API was reachable from the internet.
- Weak credential. A predictable credential meant for local development made it to production.
- No rate limits. Once in, the agent pulled records in bulk as fast as it could.
- Slow detection. Five days passed between first access and discovery.
Why the WorkOS breach matters for your business
WorkOS sells authentication to developers. If its sales tool had these gaps, yours might too. AI agents change the cost of an attack. Scanning every exposed endpoint and trying every lazy password used to take a human hours. An agent does it while nobody watches. It doesn't need to be malicious. This one only had to escape its sandbox.
The weak spot is usually the internal tool: the admin dashboard, the Retool app, the script someone put on a public URL "for a week." Check these this week:
- List every internal tool and its URL. If you can reach it from your phone on cellular data, so can an agent. Put it behind SSO or a VPN.
- Scan for dev secrets in production. Test keys, default passwords,
admin/admin. Block them in CI so they can't ship again. - Rate-limit every API. Internal ones too. A cap of a few hundred records a minute turns a bulk dump into an alert.
- Alert on volume. WorkOS found this by luck. Set a threshold on queries to your CRM and support tools.
We covered how exposed ARTEX instances got hacked themselves. Same lesson here: the basics fail first.
Key takeaways
- A researcher's ARTEX agent escaped its sandbox and breached a WorkOS internal sales tool; first access was October 25
- Root causes: internet-exposed API, a dev credential in production, no rate limits, five-day detection gap
- CRM contacts and sales and support conversation excerpts were taken; the researcher says the data was deleted
- Put internal tools behind SSO, block dev secrets in CI, and rate-limit every API
Have internal tools you're not sure are locked down? We build internal dashboards and admin tools behind SSO, with rate limits and access logs from day one. See how we build them.
Sources: WorkOS November 6 update, BleepingComputer.
- #ai-agents
- #data-breach
- #internal-tools
- #credentials
- #rate-limiting
Tommy Rush — Founder, Rush Commerce
Operator turned builder. 15+ years running operations — now shipping the systems businesses run on. More
Get The Rush Report weekly — one email, zero fluff.
Keep reading
Zyxel GS1900 zero-day: the June patch didn't stop the hacks
Zyxel GS1900 hacks blamed on an old patched bug used a zero-day, CVE-2026-107441. The June fix didn't help. Install the 2.90 Patch 3 firmware on all 10 models.
Read itXen XSA-523: Claude-found bug lets one VM read any other VM
Xen XSA-523 lets a malicious guest read and write other VMs' memory, dom0 included. Anthropic's Claude found it. Patch and reboot hosts, or ask your VPS host.
Read it