On October 30, at 11:43 UTC, a cloud security team sent a warning to Northflank. One minute later, Northflank engineers opened it. By 13:05 UTC they had pushed two more patches.
The platform's public message to customers that day was eleven words long, and it is one of the most honest sentences in modern incident response: "Assume all environment variables have been decrypted. Disable/rotate all keys."
Northflank is a hosting platform for developers. You push containers and databases and AI applications, and it runs them. Which means it also, by design, held a copy of nearly everything you would need to lose sleep over: database passwords, cloud credentials, payment provider keys, private keys, and the AI provider API keys that power every agent, chatbot and copilot you have shipped this year.
Customers started reporting unauthorized use of those AI keys almost immediately.
This is not a story about one company's bad week. It is the story of a whole category learning, at speed, that its most valuable asset is a string of characters sitting in an environment variable.
What Northflank actually said
The timeline is unusually detailed, and worth reading closely.
- Oct 30, 11:43 UTC — Wiz alerts Northflank to suspicious activity.
- 11:44 UTC — engineers review it.
- 12:50 and 13:05 UTC — additional network policy patches.
- Shortly after — customers told to assume environment variables were decrypted and to rotate everything.
In its incident updates, Northflank says the attack vector was contained within an hour of the first alert, that running workloads were unaffected, that no workload data was accessed, and that the activity was focused on secrets held in the control plane. Customers on forward-deployed or dedicated control planes were not affected. The company also patched CVE-2026-98432 across its fleet, rotated its own keys, and revoked access tokens, sessions, VCS integrations, and cross-account IAM roles where it could do so on customers' behalf.
What it has not said: how attackers got in, how many customers were affected, or whether anything beyond AI keys was abused. A root cause analysis is promised.
That gap is exactly where the rest of the story lives.
Nine platforms, one pattern
Wiz collected the month's disclosures under a deliberately grim title: "Black October for AI Developer Platforms." At least nine platforms reported incidents in October — Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode and Northflank. Days later the list grew again with Brev (NVIDIA), Trigger.dev and Chainstack.
The root causes differ: Railway points to privilege escalation in its build infrastructure, Warp to a third-party vendor dependency, OpenCode to a legacy system. Fireworks, Zeabur and Lightning attribute their incidents to credential access.
But one detail repeats across almost every report: the attackers were hunting stored environment variables, and specifically the ones that grant access to AI models.
Zeabur's write-up was detailed enough that it announced it is shutting the company down. Railway has published a preliminary report. For everyone else, the technical details are still pending, and a lot of commentary has treated each incident as an isolated bad day.
They are not isolated. They are a market.
The economics of a stolen AI key
Here is the part most incident reports skip, and it is the part that should worry you.
A stolen database password has to be used carefully, indoors, where the noise is low. A stolen AI API key can be spent from anywhere, in unlimited volume, and the meter runs in your name.
Wiz traced two enterprise keys that had been used from inside breached vendor infrastructure. Both were first tested within 30 minutes of the vendor's reported credential access: a single model invocation from a residential IP, sweeping several organizations' keys in one minute.
Then the tap opened.
- Case A: roughly 800,000 Amazon Bedrock calls over thirty hours, about 90% successful, mostly from a residential address and then overnight from a hosting provider.
- Case B: roughly 1.7 million Bedrock calls over thirteen hours from a single hosting address, over a million of them successful.
At list price, those two keys alone likely ran up more than $100,000 in usage. The token profile looked like resold coding-agent traffic: small uncached inputs, a few hundred output tokens, plus a long tail of huge prompts consistent with many different end users behind a reseller.
Which brings us to why this keeps happening. Wiz identified infrastructure tied to overt LLM resale operations, advertising discounted access to frontier models with USDT payments. A key that gets stolen on Monday can be a product line by Friday. There is demand, there is pricing, and there is a channel. The theft is monetizable, so the theft continues.
Why this is worse for AI builders than it looks
Three things make this category different from ordinary hosting risk.
1. The blast radius is not the server. It is the bill, the data and the reputation. A stolen key can burn six figures in a weekend, exfiltrate whatever your prompts can reach, and produce output in your name that your brand will be blamed for.
2. Keys are synthetic identities, and most inventories do not count them. We have spent twenty years building processes to review human accounts. An API key that can spend money and reach production data usually lives in a dashboard nobody audits, created by a developer who has since changed teams.
3. Rotation is not a click, it is a graph. "Rotate all secrets" is a one-line instruction that fans out into integration secrets, project secrets, global secrets, workloads, webhooks, CI runners, third-party connectors and every teammate's local .env. Most teams discover the true shape of their credential graph during an incident, at the worst possible moment.
What to do this week
Do not wait for a root cause analysis from a vendor you have never heard of. Do this now.
- Inventory every AI provider key you own. OpenAI, Anthropic, Bedrock, Google, Cohere, the smaller ones. Record who created it, what it can reach, who pays for it and when it was last rotated.
- Give each key a ceiling. Separate keys per environment, per application, per team. Set hard spend limits with your provider, and alarms at 50% of budget. An outlier bill is a detection signal, and right now most teams have it switched off.
- Make revocation boring. A rotation runbook that takes a day is a rotation runbook that will never be rehearsed. Automate the swap and test it on a Tuesday afternoon, not during an incident.
- Watch the shape of usage, not just the volume. Sudden cross-region model calls, model catalogs being probed for availability, or a burst of uncached prompts from an unfamiliar ASN all look like someone else using your account.
- Treat your hosting control plane as a trust boundary. Whatever your PaaS or hosting provider holds, they can lose. Ask them whether they hold plaintext secrets, whether they support external secret managers, and whether they can revoke your integrations for you.
The takeaway for our clients
At aratech, we build on managed infrastructure because it lets small teams move like large ones. That trade is still worth making. But the trade is not free, and October just sent us the invoice.
The lesson here is not "stop using platforms." It is that in an AI-native stack, your API keys are the perimeter. They are not configuration. They are the thing an attacker actually wants, they are cheap to steal, and there is already a market quoting prices for them.
The teams that come out of this well will be the ones who can answer one question without opening a spreadsheet: if our hosting provider called at noon and said "assume everything was decrypted," what exactly would we have to rotate, and how long would it take?
If the answer is "hours, and we practiced it," you are fine. If it is "I would need to ask three people," today is a good day to fix that.