Wiz Research has counted at least 11 AI developer platforms that disclosed security incidents since early October, and says it watched credentials stolen in one of those breaches turn into hundreds of thousands of paid model calls within days.
The post, by Wiz’s Benjamin Read and Rami McCarthy and published on 30 October, calls the month “Black October” and lists nine platforms that disclosed incidents during it: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode and Northflank. An edit adds two more publicly reported incidents, at Brev (NVIDIA) and Trigger.dev, neither of which has shared technical details or indicators yet. Wiz’s argument is that these are one pattern, even though most coverage has treated them separately: “Any other month, and this would be the top security story.”
What the incidents have in common
Wiz is careful about what is known. Most of the incidents are still being analysed and detailed technical information is not available. Zeabur has published a full write-up and, according to Wiz, will shut down as a result. Railway has released a preliminary report and timeline.
The root causes the companies have given differ. Wiz says Fireworks, Zeabur and Lightning attribute theirs to credential access, Railway believes initial access came through “privilege escalation in our build infrastructure,” Warp has pointed to a third-party vendor dependency, and OpenCode attributes its incident to a “legacy system.” Fireworks, OpenCode and Warp have reported signs of what they call an agent swarm attack, and OpenCode and CommandCode have attributed their incidents to an attempt at model distillation.
The common thread is the target. According to Wiz, “All public reports highlight targeted exploitation, explicitly hunting stored environment variables, with a focus on those granting AI access.” Wiz finds no single vulnerability or dependency linking the attacks and places them alongside two trends: agentic attack tooling that lets an actor work through victims faster, and LLMjacking, the theft and resale of access to paid AI models, which makes stolen keys easy to turn into money.
Two stolen keys, followed
The new material in the post is what happened after the theft. Wiz says it observed downstream abuse of enterprise credentials whose compromise it attributes to one of the vendor breaches, and it walks through two cases.
Both keys had been heavily used from a compromised vendor’s infrastructure. Both saw the same first unauthorised activity within 30 minutes of the reported credential access: a single model call from a residential IP address, part of a one-minute sweep testing stolen keys across several organisations. A low-volume job then checked for days that the keys still worked.
In the first case, Wiz says, the key’s policy allowed global cross-region inference routing. After a catalogue probe across model vendors and a quota enumeration, the actor made about 800,000 Bedrock calls over thirty hours, about 90% of them successful, before the key was remediated. Global routing spread the load so only about 6% of calls were throttled. In the second case the key was restricted to US inference profiles. A reseller pool’s first attempts failed against that restriction, a checker then found the permitted model IDs, and one address made about 1.7 million calls over thirteen hours, with over a million successful. Most of the rest hit the account’s regional quotas. Wiz estimates that at list price “these two cases alone likely ran up over $100k in usage.”
Wiz also links use of the keys to two overt resale operations that advertise discounted access to frontier models, while saying it cannot definitively tie them to the original compromise or to the high-volume abuse. It has published the IP addresses it saw testing the stolen keys.
What it means for the security leader
The incidents sit in a part of the supply chain many security programmes do not inventory: the build, hosting and coding-agent platforms where developers paste cloud and model credentials as environment variables so their apps and agents can run. Each platform breach exposes every customer secret stored there, and the customer often learns of it from the vendor’s status page.
In our reading, the two cases show where the customer’s own controls changed the outcome. The same actors, with the same kind of key, got very different results depending on the key’s policy: global routing let the first flood run with almost no throttling, while the region restriction in the second case caused hours of failed calls and pushed the rest into quota limits. Scoped keys, tight quotas and spend alerts did not prevent theft, but they shaped how much a stolen key could cost and how quickly the abuse became visible.
That matches the case in our opinion on treating cloud billing admin as a privileged role, and our coverage of hardcoded secrets in AI agent configs and of how LiteLLM coverage moved to an unrevoked key describes the same exposure from the developer side.
What to do now
- List every AI developer, hosting and agent platform your teams use, and which cloud and model credentials are stored on each. Start with the platforms named in Wiz’s list.
- Rotate any credential that was stored on a platform that has disclosed an incident, and treat the vendor’s own disclosure date as the start of possible abuse.
- Scope model-access keys to the regions, inference profiles and models the workload needs, set quotas, and alert on spend and call volume per key.
- Watch model-invocation logs for the early signs Wiz describes: a single test call from an unfamiliar residential address, followed by a steady trickle of validation calls and then quota enumeration.
- Check the indicators Wiz published against your cloud logs, keeping in mind Wiz’s own caveat that it has no evidence linking those addresses directly to the platform breaches.
