The short version: On October 30, 2026, Wiz Research published "Black October," a report tying together nine AI developer platform breaches disclosed over the same 24-day stretch: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode, and Northflank. Every incident shares the same target — environment variables holding live AI provider keys — and Wiz traced two stolen enterprise Amazon Bedrock credentials from theft to abuse, finding roughly 800,000 and 1.7 million calls, over a million of them successful, routed through what looks like a coding-agent-style resale operation. The report doesn't prove a single attacker ran all nine breaches, but it does show a functioning supply chain: steal a key, quietly verify it still works, then sell access until someone notices the bill. The structural fix isn't a better environment variable — it's not storing a usable credential where a compromised process can read it at all.
What Wiz actually found
Wiz's report lists the incidents in sequence, and the dates alone make the pattern hard to miss: Fireworks AI on October 6, Andromeda on October 9, Zeabur on October 14, Lightning AI on October 15, OpenCode on October 16-17, Railway on October 20, Warp on October 23, CommandCode on October 28 and Northflank on October 30. Nine disclosures, nine different companies, one month.
Wiz is careful about what it can and can't prove. The investigation does not link nine platform incidents to a single attacker, and root-cause detail is thin for most of the list — only Zeabur has a full write-up and Railway a preliminary report, according to Wiz. What the public disclosures agree on is the target: as Wiz put it, "all public reports highlight targeted exploitation, explicitly hunting stored environment variables, with a focus on those granting AI access." Several companies named the cause directly — Fireworks, Zeabur, and Lightning all attribute their incident root causes to credential access.
Railway's preliminary report describes a different entry point into the same outcome. The company first saw an attempted privilege escalation in its build infrastructure on 20 October, with further access routes identified the next day, and put the maximum blast radius at at most 1.85% of all workspaces, about 100,000, had environment variables potentially compromised. That's a build-pipeline compromise, not credential stuffing — but the end state is the same as the others: an attacker standing in front of a store of live environment variables, with AI keys as the prize worth taking.
From stolen key to 1.7 million calls
The part of the report that turns "breach" into "ongoing financial exposure" is Wiz's reconstruction of what happened after two enterprise Amazon Bedrock keys left one of the breached platforms. Wiz didn't say which platform the keys came from, but it tracked their use start to finish.
1 · Quiet validation
Per reporting on the Wiz findings, within 30 minutes of the theft, one test call checked that each key worked, and for several days, a small script checked the keys a few times a day to make sure they were still valid.
2 · Days of dormancy
Four and seven days later, the keys were used at scale — long enough that a rotation done only at the moment of disclosure, rather than for every key a breached platform ever held, could still miss them.
3 · Burst usage
One key, under a policy permitting global inference profiles, generated about 800,000 calls to Bedrock within thirty hours, 90% of them successful, three quarters on Opus models. The second, restricted to US-only inference profiles, still produced about 1.7 million calls in thirteen hours, over a million of them successful.
4 · Resale, not just hoarding
Wiz traced key-checking infrastructure to two apparent resale operations — one promising discounted access to frontier models payable in USDT, and another carrying an internal label reading "distillation detection," a sign that resellers try not to be associated with those copying models, because accounts like that get suspended.
That dollar figure is an estimate, not a confirmed bill. Reporting on the report quotes Wiz's own framing directly: "At list price, these two cases alone likely ran up over $100k in usage." The actual invoice depends on discounts, committed-use pricing, and whether the victim org successfully disputes the charges. The scale, not the exact dollar amount, is the point: two keys, days of dormancy, and a few hours of sustained abuse were enough to put six figures of consumption on someone else's account.
Why AI keys specifically are worth stealing right now
A stolen database credential is worth something to an attacker who wants your data. A stolen Bedrock or Anthropic key is worth something to a much larger, more liquid market: anyone who wants frontier-model access without paying for it, and anyone running model distillation — training a cheaper model by querying an expensive one at scale. Distillation, the technique that Anthropic denounced in mid-October by naming Zhipu and Kimi, feeds the demand, and Railway's own preliminary report describes an attacker hunting AI provider keys for that purpose. Several of the nine platforms reported signs of automated tooling rather than manual effort: Fireworks, OpenCode and Warp report signs of an "agent swarm," an attack carried out by several AI agents in parallel.
The resale layer is what converts a one-off breach into recurring loss. A key that's resold doesn't get used once; it gets checked periodically, kept warm, and burned through whenever a buyer needs capacity. That's consistent with the quiet-validation-then-burst pattern Wiz documented, and it's why disclosure timing matters more for AI keys than for most other secrets: every day between compromise and rotation is a day the key might already be live in someone else's billing relationship.
The structural problem: a usable credential sitting where attackers already know to look
Every platform on Wiz's list fits the same architecture. A developer platform runs customer workloads — builds, deploys, background jobs — and those workloads need to call Anthropic, OpenAI, or Bedrock. The simplest way to wire that up is an environment variable: the provider key sits in plaintext in the process environment, available to anything that can read it, including a compromised build pipeline or a breached secrets store. That's not a careless choice unique to any one of these nine companies; it's the default pattern for calling a third-party API from a deployed process, and it's been the default for two decades.
It's also exactly the pattern that turns one key-theft technique into nine incidents. The attacker doesn't need a different approach for Railway's build infrastructure versus Zeabur's hosting stack versus Fireworks' credential-access path — they need the same thing each time: a process environment holding a real, usable, long-lived key. Zeabur's incident, notably, was severe enough on its own that the company is shutting down due to this incident, after attackers reportedly gained root access to Zeabur's own hosting infrastructure. For more on this recurring failure mode independent of any single vendor's mistakes, see our related coverage of credential exposure through stored secrets.
What detection actually looks like for Bedrock keys
One wrinkle makes this class of abuse harder to spot than a leaked database password: Bedrock API keys are passed as authorization headers and are not logged in the request body, so string-searching your logs for the key itself doesn't work. CloudTrail is the layer that does: Bedrock calls made with a bearer-token key show up with a CloudTrail event where any Bedrock action has additionalEventData.callWithBearerToken = true, and that flag lets a security team spot usage even without the key value. Teams reviewing exposure from any of the nine platforms should run that CloudTrail query across every account with Bedrock enabled, for the full window since the relevant platform's disclosure date — not just the disclosure day itself.
Restricting what a key can do before it leaks is the other half of the equation. Narrower IAM policies — specific models, specific regions, no cross-region inference profiles unless the workload genuinely needs them — don't stop a key from being stolen, but they cap what a stolen key is worth. The 800,000-call case ran under a permissive global-inference policy; the 1.7-million-call case was restricted to US-only profiles and still produced over a million successful calls. Scoping reduces blast radius. It doesn't substitute for keeping the key out of a readable environment variable in the first place.
Where an egress-proxy model actually changes the picture
None of this means a different architecture would have stopped Railway's build-pipeline privilege escalation or Zeabur's infrastructure compromise — those are breaches of the host itself, and an attacker with root on a machine that terminates your traffic can still intercept calls in flight. What an egress-proxy model does change is what's sitting in the environment variable to begin with. If the application process, the CI runner, and the AI agent never hold the literal Bedrock key — if the real credential is injected at the egress wire by a gateway the app process can't read — then a dumped environment variable or a compromised build step yields a reference, not a usable secret. That's the model behind KnoxCall's AI gateway: the provider key lives at the proxy, not in anyone's process memory or .env file, so a breach that reads environment variables comes back empty on the one line item attackers in Black October were specifically hunting for.
It's a narrower claim than "this stops breaches," and it should be. It addresses one specific, recurring failure mode: a usable key sitting somewhere an attacker who gets code execution can simply read. That failure mode happens to be the common thread across all nine Black October incidents, which is exactly why it's worth being precise about rather than overselling.
What to do this week
- Inventory every AI key — OpenAI, Anthropic, Bedrock/IAM, Google, Mistral, OpenRouter — and note which platform and environment holds each one.
- Rotate at the provider, not just the platform, for anything stored on Railway, Fireworks AI, Zeabur, Lightning AI, OpenCode, Warp, CommandCode, Northflank, or Andromeda. Deleting the secret from the breached dashboard doesn't invalidate a key an attacker already copied.
- Run the CloudTrail query for
callWithBearerToken: trueevents across the full window since your platform's disclosure date, not just the disclosure day. - Scope new keys narrowly — specific models, specific regions, short expiry — so the next leak is worth less.
- Treat "rotate" as "this key is burned," and plan for the days-long dormancy Wiz observed: a key that looks unused today may already be checked and queued for resale.
For teams deciding how far to take the architecture question, our gateway comparison and pricing pages lay out what moving key custody off the application process actually involves.