Railway Says Stolen Keys Ran Up About $740,000 in AI Charges. Here Is the Spend Cap I'd Put on Every Key I Store on a Platform.
Railway published its full incident report on November 10, and one line in it should change how you store AI keys on any platform: unauthorized spend on the stolen keys "was estimated to reach ~$740,000." The attacker got into Railway's build infrastructure on October 20, decrypted a subset of customer environment variables the next morning, and, in Railway's words, went "specifically prioritizing AI provider keys." If you keep an OpenAI or Anthropic key in a host's env vars, and almost every solo builder does, this is your threat model now.
What Railway says happened
The timeline in the report is precise, which I appreciate. The initial exploit of build infrastructure was at 07:28 UTC on October 20. Engineers were paged at 13:58 UTC, builds were halted at 17:03, and the build credential was swapped at 17:28. That did not end it. At 03:26 UTC on October 21 the attacker obtained a short-lived cloud credential through an OIDC misconfiguration, and between roughly 04:42 and 07:15 decrypted some environment variables. Railway disabled the cloud credentials at 07:14 and asked AI and other providers to revoke keys at about 09:25.
The blast radius is stated as an upper bound: "at most, 1.85% (~100,000) of workspaces" had variables decrypted. Railway says that is a ceiling because its logs identify environments, not individual variables. The attacker also read the stored histories of 353 builds, sealed variables included, and Railway reset linked-account tokens (bring-your-own agent keys and GitHub OAuth tokens) for 1,852 users. The report says forensics did not show customer databases were accessed.
Two details stand out. First, the attacker chose AI keys over everything else, because an AI key converts to money the fastest: you can resell access or burn tokens with no shipping address. Second, the $740,000 is an estimate across all affected keys. It is not a confirmed total, and it does not tell you what any single customer lost.
Who pays depends on which vendor issued the key
This is the part I would screenshot. Railway's November 10 report lists refund handling by provider. AWS Bedrock and Google Gemini said their existing fraud refund policies apply, and their account teams started refunds. OpenAI reviews refunds case by case. For Anthropic keys, Railway says "we will be covering Anthropic breached key costs ourselves." OpenRouter enforces its no-refund terms, and Railway says it will cover those costs too.
That position moved. Railway's October 26 update said it was "unable to refund customers for spend performed with compromised API keys" and told customers to go to the AI providers first. By November 10 the wording became working with providers on refunds and backstopping from Railway's own balances for providers unwilling to do so. In the public Central Station thread, several customers say support declined credits in the weeks between those two statements. Those are customer posts, not Railway statements, but they show what the gap felt like from the inside.
So the same breach, on the same host, produced different outcomes depending on whether your key came from Google, OpenAI or an aggregator. I don't think most of us pick an AI vendor based on its fraud refund policy. After this, I would at least know mine.
The fix is a cap, not a new host
The tempting response is to move off Railway. I don't think that is the lesson. Every platform that stores secrets for you has some version of this risk, and Railway's report is more detailed than most companies ever publish. The lesson is that a key sitting in a host's env vars should be worth very little to whoever steals it.
Here is what I'd set up, in order of how much damage each one prevents:
- A hard monthly spend limit at the provider. Most AI providers let you set a limit at the organization, workspace or project level. Set it to about twice your normal monthly spend, not to the default. A stolen key that hits a $200 ceiling is an annoyance. One with no ceiling is a $740,000 headline.
- One key per deployment, inside its own project or workspace. If production, staging and your side project share a key, one leak exposes all three budgets and you can't tell which environment the spend came from.
- Usage alerts that go to your phone. A daily spend email you read on Friday is too late. You want a push when spend crosses a threshold within the day.
- A rotation drill you have actually run. Railway told customers to "revoke and reapply sensitive environment variables." If you have never rotated your keys, you don't know how long it takes. Time it once on a quiet afternoon.
- Payment, database and cloud credentials on the same list. Railway says one of the attacker's queries also matched cloud, database and payment service credentials. AI keys were first in line, not the only thing taken.
None of this is exotic. It is the same discipline you'd apply to a Stripe key, applied to a key that can now spend real money faster than most payment fraud.
Where I could be wrong
The strongest argument against my take is that spend caps break production. If your app has a good month and hits the ceiling, your users see errors. That is a real cost, and for a product with spiky traffic a hard cap may be the wrong tool. The answer there is a higher cap plus alerts at 50% and 80%, not no cap at all.
The other open question is whether this was a Railway-specific failure or a sign of a wider campaign. Railway's report says other providers, including OpenCode, Warp and Fireworks AI, saw similar thefts, and it cites a Wiz report as context without claiming attribution. If AI keys are now a primary target across hosts, the cap matters even more. I can't tell from the public record how coordinated this was.
What I'd actually do this week
Open the billing page of every AI provider you use and check whether a hard limit exists and what it is set to. If any of them show "no limit," fix that before you close the tab. Then list every place a key lives: host env vars, CI secrets, your local .env, and any agent tool you've wired up. Anything on that list that has not been rotated since October 21 and sat on a platform that stores secrets for you gets rotated today. It takes about an hour, and it is cheaper than any refund process you would otherwise be waiting on.
Author
Lukas
@lukcombinator