On 6 November 2026, WorkOS confirmed that the data taken from one of its internal sales tools was pulled by an AI security agent running the ARTEX framework, which had escaped a researcher's isolated test environment during benchmark runs. The agent found an internal tool that should never have been on the internet, logged in with a weak credential meant for local development, and retrieved records in bulk from an API with no rate limits. In the same fortnight Chainalysis disclosed an intrusion by "an external actor using offensive agentic techniques", and CrowdStrike documented a China-nexus group using ARTEX against more than 200 organisations in 11 days. If you run a startup, the lesson is not "AI hackers are coming". It is that the boring gaps (an exposed internal app, a dev password in production, no rate limiting, no volume alerts) are now found and used at machine speed. Close those four this week.
I'm Kunal Vohra, a fractional CTO and a security researcher and cybersecurity advisor. Last week I wrote about OpenAI's 948 Linux root exploits, which showed what AI can do to software when defenders point it at code. This post is the other side: what it looks like when an agent is pointed at a company, and what WorkOS was honest enough to publish about how it happened.
Who should care
- Any startup with internal tools. Admin panels, sales and support dashboards, a Retool or homegrown CRM, a staging app, an "internal" API a contractor built two years ago. If one of these is reachable from the internet, an agent will find it.
- Teams with old or shared credentials. CrowdStrike's write-up lists unrotated 2022 keys and a VPN key tied to a 2024 email leak among the ways ARTEX operators got in.
- Anyone on AWS, GCP or Azure. One of the documented paths was a web flaw used to reach cloud instance metadata, which is how a small bug becomes cloud credentials.
- Customers of SaaS vendors that hold your API tokens. Chainalysis says names, usernames, password hashes and live tokens for all of its users were exposed. Your security now includes your vendors' internal tools.
- Founders and sales teams. WorkOS warned that stolen business contact data and call summaries make follow-up phishing look legitimate.
What actually happened
WorkOS: an agent that left its sandbox
WorkOS sells authentication and enterprise SSO to SaaS companies, so its incident drew attention fast. It published two security bulletins:
- 2 November 2026. WorkOS said it had identified, on 30 October, unauthorised access to "an internal WorkOS application used by our sales team", and that the investigation found an AI-assisted offensive security framework automating reconnaissance and exploitation. It disabled external access to the app, brought in an independent forensics firm and began notifying affected customers.
- 6 November 2026. After the first bulletin, a researcher came forward. WorkOS says the researcher was running cybersecurity benchmark evaluations with ARTEX when the agent escaped its isolated testing environment, and that it "wasn't the work of an actor with malicious intent". The researcher supplied request details, timestamps and artifacts; WorkOS and the forensics firm matched them to its logs, and the researcher confirmed they deleted all WorkOS data and shared it with no one.
The timeline WorkOS gives: first confirmed unauthorised access to the internal tool's API on 25 October; bulk retrieval of records on 30 October, when an employee noticed unusually high usage of a connected system; public access removed and credentials for connected services rotated 30 to 31 October; customer notification from 2 November.
The data the app gave access to, per WorkOS: business contact details (names, emails, phone numbers, job titles, companies), account histories and sales relationship information, summaries and excerpts of sales calls, support discussions and customer Slack conversations (a limited number including end-user email addresses), and product usage and connection-health metadata. The forensics firm's finding, as WorkOS reports it, is that only data in its sales and customer support systems was affected. WorkOS did not publish how many customers were affected, and it did not explain how the agent escaped the researcher's sandbox.
The most useful part of the update is the root-cause list. In WorkOS's own words, the tool "should not have been reachable from the internet"; its API "accepted a weak credential intended for local development", and controls did not stop that credential reaching production; the API "lacked rate limiting or throttling mechanisms"; and monitoring "did not detect the activity soon enough". The app also sat on a legacy internal-tools platform that had not been migrated, so it missed the safeguards newer tools had.
An AI agent doesn't need a zero-day. It needs one internal tool you forgot was on the internet, and the patience to try every door at machine speed.
ARTEX and Vapor Panda: the same tool, used on purpose
On 29 October, CrowdStrike published research on a China-nexus group it calls VAPOR PANDA using ARTEX, which The Hacker News describes as a Go-based, AI-powered penetration testing framework. CrowdStrike's numbers:
- Activity starting 17 October 2026, touching more than 200 organisations.
- At least 14 countries in an 11-day window from a single ARTEX controller.
- Post-exploitation at nine organisations, with at least 12 more password-sprayed or credential-scanned.
- One intrusion's planning agents consumed on the order of 1.4 billion input tokens.
- Agents switched approach when a path failed, and the human operator intervened mainly at decision points.
The ways in were not exotic: an unsigned SAML assertion and an XML external entity flaw used to reach cloud instance metadata, an unauthenticated orchestration service in a container environment, unrotated keys, VPN configurations recovered from mail, and password spraying. CrowdStrike says this campaign is separate from ARTEX activity Microsoft has reported under a different name. The Hacker News adds that the developer has reportedly taken ARTEX closed source, citing other reporting; I have not seen that confirmed by the developer.
Chainalysis: a disclosure that kept growing
Chainalysis first posted on 30 October that an external actor using offensive agentic techniques had accessed its systems and internal tools, and at that point said it had no evidence that credentials or session tokens were accessed. Its updates then widened the picture: on 4 November an "on-path attack" exposed a subset of customer passwords, and later that day it said names, usernames, password hashes and live tokens for all Chainalysis users were exposed. It took Reactor and Data Solutions offline on 2 November, began a phased restoration of KYT and Address Screening on 6 November with trusted-IP allowlisting and forced password and API key resets, and said on 7 November that Reactor, KYT and Address Screening were back online. Chainalysis does not name ARTEX, and nothing published links its incident to WorkOS. The Hacker News lists Chainalysis and WorkOS alongside Chainstack, OpenCode and Warp as companies that have disclosed AI-driven attacks this autumn.
What changes for a startup
Nothing in the WorkOS or CrowdStrike accounts needed a new class of vulnerability. What changed is cost. A human attacker might never get round to your forgotten staging dashboard; an agent that can run reconnaissance across 200 organisations in 11 days will. I made a similar point in Can AI Hack Systems?: AI mostly makes existing attacks cheaper and more patient. The WorkOS timeline shows the other half. Five days passed between first access and detection, and detection came from a human noticing usage, not from an alert.
What to change in your stack this week
1. Find everything that answers on the internet
Start from the outside, the way an agent would. Certificate transparency logs list most hostnames you have ever issued a certificate for:
curl -s "https://crt.sh/?q=%25.yourcompany.com&output=json" \
| jq -r '.[].name_value' | sort -u
Then check the cloud side. On AWS, list security groups that allow traffic from anywhere:
aws ec2 describe-security-groups \
--filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
--query "SecurityGroups[].[GroupId,GroupName]" --output table
Every hostname and open port should have an owner and a reason. Anything called admin, internal, staging, crm, ops, tools or dashboard deserves a closer look.
2. Take internal tools off the public internet
WorkOS's fix was to block internally developed tools from the internet at the network edge. For a startup, that usually means putting internal apps behind an identity-aware proxy (Cloudflare Access, Google IAP, or a private network such as Tailscale) so a request never reaches the app without a company SSO login. A login page on the app itself is not enough; the app's API is what got scraped.
3. Make it impossible for dev secrets to reach production
A weak credential "intended for local development" ended up guarding production. The cheapest guard is to make the app refuse to start in production with a weak or known development secret:
// lib/assert-prod-secrets.ts: call once at server start
const DEV_VALUES = new Set(["changeme", "password", "dev", "test", "secret", "admin"]);
export function assertProdSecret(name: string) {
const value = process.env[name] ?? "";
if (process.env.NODE_ENV !== "production") return;
if (value.length < 32 || DEV_VALUES.has(value.toLowerCase())) {
throw new Error(`${name} looks like a development secret; refusing to start in production`);
}
}
Pair it with separate secrets per environment in your secret manager, so nobody can copy the dev value across by accident.
4. Rate limit every API, including the internal ones
No rate limiting is what turned access into bulk retrieval. If you run Nginx in front of Node, a basic per-IP limit is a few lines:
# in the http block
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
# in the server block
location /api/ {
limit_req zone=api burst=20 nodelay;
limit_req_status 429;
proxy_pass http://127.0.0.1:3000;
}
Per-IP limits are a floor. For authenticated APIs, also limit per token or per user, and cap how many records one request can return.
5. Alert on volume, not just errors
An agent pulling data in bulk mostly gets successful responses, so error-based alerts stay quiet. Alert when one user, token or IP reads far more than usual in an hour. WorkOS lists alerts for unusual access patterns and request volumes among its in-progress fixes. If you have nothing else, a daily look at top talkers in your access logs is a start:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
WorkOS also published the user agents it saw. They are trivial to change, but a quick check costs nothing:
zgrep -iE "artex|infra-hunt|norma/|verify-911-probe" /var/log/nginx/access.log*
6. Rotate old keys and close the cloud metadata path
CrowdStrike's advice is to rotate signing keys, preauthentication keys and service credentials after any suspected exposure, enforce SAML signature validation, and require IMDSv2. On AWS, IMDSv2 makes the metadata-service path much harder to abuse through a web flaw:
aws ec2 modify-instance-metadata-options \
--instance-id i-0123456789abcdef0 \
--http-tokens required --http-endpoint enabled
Then list every key older than a year and either rotate it or delete it. If nobody knows what a key is for, that is your answer.
7. Keep a vendor token register
The Chainalysis lesson is about the tokens you hand to vendors. Keep a short list: vendor, what the token can do, where it is stored, who can rotate it. When a vendor discloses an incident, you should be able to rotate in minutes, not spend a day finding the token. Prefer scoped, read-only, IP-allowlisted tokens wherever a vendor offers them.
8. Expect better phishing, and say so
WorkOS warned that stolen contact data and call summaries can make phishing look legitimate. Tell your sales and finance people now: an email that quotes your last call accurately is not proof it is real. Verify payment or credential requests on a known channel. My device code phishing guide covers the account settings that blunt this.
9. If you run AI security agents, sandbox their network
The WorkOS agent was a researcher's benchmark run, not a criminal's. If your team experiments with AI pentest agents, run them with an egress allowlist that only reaches the targets you own, and log every outbound request. The same applies to coding agents and anything else that can make network calls, as I covered in AI agent security for startups.
What I'd do as a CTO
I'd treat this as an inventory problem first. The question I'd ask any team is whether it can produce, today, a complete list of what it exposes to the internet, which secrets guard each piece, and who would notice a strange spike in reads. Building that list is the work: one afternoon on steps 1 to 3, a day on rate limits and alerts, then a quarterly review. It is already on my startup security checklist for a reason.
I'd also give WorkOS credit. Its update names four plain mistakes in plain language. That is the bar I'd hold any vendor to, and any company I advise: when something goes wrong, publish what failed, not just what was accessed.
If nobody on your team owns this, it doesn't need a full-time hire. A technical advisor retainer can run the review with your engineers, and a fractional CTO can own security, infrastructure and the rest of the platform end to end.
Frequently asked questions
What happened in the WorkOS breach? WorkOS says an AI security agent running the ARTEX framework escaped a researcher's isolated test environment, reached an internal sales tool that was exposed to the internet, used a weak development credential, and retrieved sales and support records in bulk between 25 and 30 October 2026. WorkOS says the researcher had no malicious intent and deleted the data, and that a forensics firm found only sales and support systems were affected.
What is ARTEX? ARTEX is an AI-powered penetration testing framework, written in Go according to The Hacker News, that uses LLM agents to plan and run reconnaissance and exploitation. CrowdStrike reported a China-nexus group, VAPOR PANDA, using it against more than 200 organisations from 17 October 2026.
Was WorkOS AuthKit or SSO affected? WorkOS's bulletins describe an internal sales application and say the forensics firm found only data in its sales and customer support systems was affected. They do not report any impact on its authentication products. Watch the WorkOS security bulletins for updates.
Is the Chainalysis breach related to WorkOS? Nothing published links them. Chainalysis says an external actor used offensive agentic techniques; it does not name ARTEX. If you are a Chainalysis customer, rotate your passwords and API keys and follow its forced resets.
How do I protect my startup from AI agent attacks? Remove internal tools from the public internet, stop development credentials reaching production, rate limit every API, alert on unusual read volume, rotate old keys, require IMDSv2 on AWS, and keep a register of vendor tokens so you can rotate quickly.
Can AI agents really hack companies on their own? In these cases a human still started and steered the work, but the agents did the reconnaissance and retried failed paths themselves. That makes the cheap, common mistakes far more likely to be found than before.
If you'd like a second pair of eyes on what your startup exposes to the internet, book a 30-minute call. Bring your list of domains and your cloud account owner, and we'll find the internal tools that shouldn't be public.
Sources
- October 30th, 2026 Data Security Incident (WorkOS)
- Update for October 30th, 2026 Data Security Incident (WorkOS)
- VAPOR PANDA Uses AI-Driven ARTEX to Scale a Global Espionage Campaign (CrowdStrike)
- Updated Nov 7: Chainalysis Security Incident Information (Chainalysis)
- Chinese Hackers Use AI-Powered ARTEX to Target Over 200 Organizations Worldwide (The Hacker News)
- Chainalysis Breach Exposes All Users' Credentials, Forces Shutdown of Key Services (The Hacker News)
- ARTEX AI Agent Escapes Security Sandbox and Breaches WorkOS, Exposing Customer Data (Cyber Press)
- WorkOS Says Researcher's AI Penetration-Testing Agent Escaped Its Sandbox (Compsmag)
Written By
Kunal Vohra
Technical Co-Founder & Fractional CTO
I've co-founded 6+ startups across India, the UAE, and the US, spanning AI, Web3, fintech, and cybersecurity. I write about the technical and strategic decisions that determine whether a startup thrives or stalls.
Comments
Loading comments…