Look at the recovery guides Railway posted after its breach. Next to the ones for Redis and GitHub sits a telling title: “Check for Unexpected OpenAI Usage.”
On October 21, Railway detected anomalous activity in the systems that store customer environment variables. Its disclosure says an unauthorized party “may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents.” Railway believes it’s “part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers” (Railway blog).
Railway told all users to roll every environment variable, plus private registry credentials, even though early analysis points to a subset of accounts. It paused all deployments, including for Enterprise customers. It rotated every storage bucket credential, invalidated the GitHub tokens it held and, at 04:39 UTC on October 22, killed every Railway API token (Railway status page; Railway blog).
It isn’t alone. Earlier this week OpenCode said attackers took more than 1% of its customers’ API keys and other secrets in a similar attack, and blamed AI distillation (TechCrunch).
Why AI keys. Think like the attacker. A stolen database password gets you one company’s data and a lot of noise. A stolen inference key gets you something you can use right away: model access billed to someone else, at scale, through a legitimate API that doesn’t look like an intrusion. Developer platforms are where those keys pile up. Thousands of teams, each with an OpenAI or Anthropic key in an env var, all behind one platform’s decryption path.
That changes the threat model for every PaaS, CI system and agent host. They used to hold keys to customer data. Now they hold keys to compute that attackers want to resell or distill.
The part nobody plans for. Railway’s own guidance shows the trap. Containers read variables only at startup, so every service using a rotated credential has to be redeployed. Deployments were paused. Railway told customers that until builds came back, they couldn’t redeploy to pick up new bucket credentials (Railway status page).
So the platform holding your secrets got breached, and the same platform’s freeze stopped you from rolling them out. You could revoke at the provider. You couldn’t redeploy with the replacement. For a lot of teams that means choosing between leaving a possibly leaked key live and taking an outage.
And Railway’s GitHub note has a sting. The GitHub tokens stored as registry credentials were removed from Railway, but they “still work on GitHub until you revoke them” (Railway blog). Deleting a secret from the platform that leaked it isn’t revocation. Only the issuer can revoke.
What this says about where security is going. Static secrets in env vars are an old pattern running this year’s workloads. The fix the industry keeps circling is the same one: short-lived, workload-bound credentials issued at runtime and injected outside the workload’s reach, so a dump of the secrets store holds nothing worth stealing. Cloud workload identity does this for cloud APIs. Most AI provider keys are still long-lived bearer strings.
That’s the gap. Expect inference providers to come under pressure to support scoped, expiring, workload-bound keys. Expect platforms to be asked in security reviews whether their decryption path is separated from the control plane an intruder can reach.
What we’d do today. If you deploy on Railway, revoke at the issuer first. OpenAI, Anthropic, cloud, GitHub, registries. Don’t wait for builds to return. Pull usage logs on every AI key and look for spend that doesn’t match traffic. Then fix the pattern for everyone, not just Railway users. Inventory every long-lived AI key in any PaaS or CI env var. Set spend caps and per-key alerts at the provider. Write a runbook for rotating secrets when your deploy platform is the thing that’s down. Most teams don’t have one. This week showed why it matters.