AI Developer Platform Breaches: WorkOS, Northflank, Trigger.dev and the LLMjacking Wave

On November 4, WorkOS confirmed that an internal application was breached on October 30 and that its own investigation "identified the use of an AI-assisted offensive security framework to automate reconnaissance and exploitation attempts" (WorkOS security bulletin). It is the latest name in a pattern that researchers at Wiz are now calling "Black October" for AI developer platforms: at least a dozen platforms that hold customer credentials — hosting PaaS, AI gateways, coding-agent consoles, evaluation services — have disclosed intrusions in roughly a month, and nearly every one exposed keys for AI inference services. The prize is not your source code. It is the API key you pasted into a dashboard and forgot about.

Developing story — first published 13:55 CET (12:55 UTC), 4 November 2026. Updated as the platforms and researchers publish more.

What happened

The Cloud Security Alliance calls the shape of this "platform-chain" attacks: reaching an AI inference account "by going through one or more platforms that hold its credentials, without touching the provider or the end customer directly" (CSA research note, October 23). You hand your OpenAI, Anthropic, Google or Amazon Bedrock key to a PaaS host, a gateway like LiteLLM, an eval platform, a CI system, and your coding agent's console. Each copy is a place the key can leak. As CSA puts it, "the credential as a whole is only as safe as its least-protected copy" — and Fireworks AI's own disclosure made the harder point: deleting a stored secret does not invalidate the credential.

Wiz counts at least nine platforms disclosing incidents across October, with more arriving since. The reports do not describe one vulnerability or one actor. Initial access varies — stolen credentials at Fireworks, Zeabur and Lightning; a privilege escalation in Railway's build infrastructure; a third-party vendor dependency at Warp; a decommissioned legacy system at OpenCode. What is consistent is the objective. In Wiz's words, "all public reports highlight targeted exploitation, explicitly hunting stored environment variables, with a focus on those granting AI access."

Verified incident tracker

Status reflects what a primary source confirms, not what has circulated on social media. Dates are disclosure or observation windows, per Wiz, CSA and SecurityWeek.

Platform	Disclosed	What was exposed / root cause	Status
WorkOS	Oct 30	Internal sales/CRM app; business contacts, sales-call and support summaries, customer Slack excerpts. No evidence production or core auth data was accessed	✅ confirmed
Northflank	Oct 30	Incident disclosed; no TTPs or IOCs shared yet	⚠️ details pending
Trigger.dev	early Nov	Incident disclosed; no TTPs or IOCs shared yet	⚠️ details pending
Chainstack	~Oct 26–31	Dev + production reached via a third-party component; customer DB with org names, account-holder names, emails, password hashes; node credentials rotated	✅ confirmed
CommandCode	Oct 28	Stored customer secrets; company attributed it to "distillation"	⚠️ partly confirmed
Warp	Oct 23	Third-party vendor dependency; agent-swarm indications	✅ confirmed
Railway	Oct 20–21	Privilege escalation in build infrastructure; customer env vars possibly accessed, some possibly decrypted; wallet drains reported	✅ confirmed
OpenCode	Oct 16–17	Decommissioned legacy system; OpenAI/Anthropic/Google keys saved by ~1.4% of console users; unauthorized charges over $1,000 reported	✅ confirmed
Lightning AI	Oct 15	Credential access; previously impacted by the Mini-Shai-Hulud supply-chain campaign	✅ confirmed
Zeabur	Oct 14	Environment variables read; company is shutting down	✅ confirmed
Andromeda	Oct 9	Stored secrets; described as part of an "industry-wide attack"	⚠️ partly confirmed
Fireworks AI	Oct 6	Internal credential misuse; env vars in evaluation jobs, including third-party API keys and tokens	✅ confirmed
Brev (NVIDIA)	Oct 4–20	Incident disclosed; no TTPs or IOCs shared yet	⚠️ details pending

No single actor has been confirmed across these. CSA is explicit that the "campaign" label so far "rests on Railway's characterization," and that the incidents "do not appear to be related." Treat the table as a cluster of opportunistic theft against a shared weakness, not one operator.

From stolen key to a six-figure bill

What makes this worth your morning is the back end. Wiz traced two stolen keys from the moment of the vendor breach to the abuse, and the economics are the story. In both cases the first unauthorized activity landed within 30 minutes of the credential access — a single InvokeModel call from a residential IP in a one-minute sweep that tested stolen keys across many organizations. (One sweep asked for Claude Fable 5.1, failed, and fell back to Opus 5.5, which worked.) Then a small Go client ran a validation job, 14 to 120 calls a day, just to confirm the key stayed live.

When the flood came, it came hard:

• Case A: about 800,000 Bedrock calls over 30 hours, roughly 90% successful, from residential then hosting addresses.
• Case B: about 1.7 million calls over 13 hours, over a million successful, across a dozen Claude models.
• At list price, Wiz estimates those two keys alone "likely ran up over $100k in usage."

This is LLMjacking at industrial scale, and it runs on infrastructure. Wiz attributes the surge to "the rise of LLMjacking, and the associated infrastructure of LLM Brokers" — resale hubs that advertise discounted frontier-model access for USDT and quietly route traffic through stolen keys. One such console, traced to an operator calling itself "momo," was hosting a page titled "ARTEX — autonomous penetration testing console" on October 8. The same open-source Artex framework is what multiple vendors, including CrowdStrike, tie to the Chinese cluster VAPOR PANDA's 200-org campaign and what SecurityWeek links to Storm-0940's ConnectWise attacks. Demand is pulled partly by distillation — building cheaper rival models from stolen reasoning — which OpenCode and CommandCode both named as the motive for their incidents.

"Delete the exposed secret from the dashboard and you've done nothing. The key still works at the provider. The only revocation that counts is the one you do at the issuer — and most teams have never inventoried where a single production key has been copied."

The AI-offensive thread

The reason this reads as more than a run of unlucky startups is the automation on the attacker's side. Fireworks, OpenCode and Warp all reported indications of an "agent swarm." WorkOS, in its own words, found "an AI-assisted offensive security framework" automating reconnaissance and exploitation. When OpenCode tried to analyze the malicious code, "commercial frontier models refused to analyze" it and the investigation stalled. This is the same operational pattern we have been documenting all autumn — autonomous agents breaching one organization after another, picking follow-up actions from a target's responses, at a tempo no quarterly pentest keeps up with. The AI access keys are both the target and, once stolen, the fuel for the next wave of attacks. That loop — stolen key funds the autonomous attack that steals the next key — is what makes this self-sustaining.

Remediation

There is no patch here. This is a credential-hygiene and detection problem, and the window to act is now, before a validation job turns into a flood.

1. Am I affected? If you have ever stored an AI provider key, cloud credential, database password or registry token on any of the platforms above — or on any third-party service that holds secrets on your behalf — assume exposure and act without waiting for a notification. CSA's guidance is blunt: the cost of an unnecessary rotation is small compared with the cost of a missed one.

2. Rotate at the issuer, not the dashboard. Revoke and reissue every affected key at the provider that minted it (OpenAI, Anthropic, Google, AWS/Bedrock, your database). Removing the secret from the breached platform does not revoke it. This is the single step most teams get wrong.

3. Review provider-side logs from mid-September. Pull billing and usage logs at the inference provider from at least mid-September — or the earliest date in the platform's disclosure — and hunt for volume spikes, unfamiliar models, cross-region inference profiles you never use (global.*, us.*), and calls from residential or hosting IPs. The abuse signature is a short validation cadence followed by a burst of InvokeModel (T1496 Resource Hijacking, T1526 Cloud Service Discovery).

4. Scope keys so a single leak is small. Issue a separate key per platform and per application. Apply provider-side spending caps and rate limits set close to expected consumption, not at account maximums. Prefer project-scoped or workload-identity access, and inject credentials at runtime from a secrets manager rather than pasting them into a platform dashboard (T1552.001 Unsecured Credentials in Files).

5. Watch the internal tool, not just the perimeter. WorkOS lost a sales/CRM app, not its auth product; the attackers went for the softest internal surface and the data that makes future phishing convincing. Treat internal consoles, eval sandboxes and admin panels as primary targets (T1190 Exploit Public-Facing Application, T1078.004 Cloud Accounts), rate-limit bulk secret reads, and make "which third parties hold a copy of this key" a standing question in vendor assessments. The on-premise pentest platform buyer's guide covers the data-residency side of keeping credentials off third-party dashboards in the first place.

What is not known yet

• Attribution. No vendor has tied the platform breaches to a single actor; the LLM-broker infrastructure Wiz traced is "suspected to be linked" to token resale but not proven to be behind the breaches themselves.
• Northflank, Trigger.dev and Brev have disclosed but not published TTPs or IOCs as of November 3.
• WorkOS's entry vector is not stated, and WorkOS does not itself name Artex — the framework attribution comes from third-party research (Wiz, CrowdStrike), not the victim.
• Scope. Which inference accounts were actually drained, versus merely exposed, is still being counted across most of these platforms.

Where Zero Hunt fits

The platforms in that table were not undone by a zero-day. They were undone by an automated agent finding a reachable secret store faster than anyone was watching — and the drain that followed was pure traffic. That is the surface an attacker cannot rewrite. Zero Hunt's traffic-analysis model runs a deep-learning stack with four inference heads over billions of PCAP sequences, on the appliance's own GPU, and it reads the machine-tempo recon-to-exploitation against an internal console, and the anomalous outbound to never-seen ASNs when a key is being burned, while it is happening — not in the next morning's billing export. When the abuse routes through your own egress, it is a host that normally ingests suddenly sustaining outbound: exactly the behavior the model is built to flag.

The other half is finding the exposed key before the swarm does. Zero Hunt is an autonomous AI red team that runs on-premise on its own private models, with a human approving every action that matters. Point its 10-agent swarm at your own platforms, gateways and CI — black-box or gray-box — and it hunts the same reachable secrets the attackers hunt, from the input-reachable env var to the over-permissive Bedrock policy, and files each finding signed at write time so the audit trail is defensible. The engine's models are yours; no third party can throttle, refuse or switch off the test, and nothing leaves the box. For the testing-cadence side of staying ahead of agent-speed offense, see automated penetration testing.

The keys are the crown jewels now. Treat the places you store them like the crown vault.