Short version: on 20-21 October 2026, the deployment platform Railway was hit by a sustained, targeted attack. The detail every team building with AI should pay attention to is not that a platform got breached - it is what the attackers were after: AI provider API keys. Those keys have quietly become one of the most valuable things in your stack, and the people trying to steal them are now using AI to do it. Here is what happened, why AI keys are the new prime target, and a practical checklist to protect yours.
What happened at Railway (the short version)
On 20 October, Railway's monitoring flagged unusual latency. Within hours the team had traced it to a privilege-escalation attempt in their build infrastructure, paused all builds, and declared an incident. Over the next two days the picture filled in: the attacker had escalated access, pulled encrypted secrets, obtained CI credentials, and used them to decrypt a slice of customer environment variables. Railway's own analysis put the exposure at at most 1.85% of workspaces (around 100,000), said user accounts were not accessed, and kept customer apps online while deployments were paused.
Railway's response was fast and unusually transparent: they rotated every key, then rotated them again after confirming the attacker was gone, rebuilt tooling from validated source, notified upstream vendors to revoke affected keys, and published both an early disclosure and a detailed preliminary report. Credit where it is due - that is how you want a platform to behave under fire. This post is not about blaming Railway. It is about the pattern the incident reveals.
The real story: your AI API keys are now the prize
Railway said the campaign was aimed at harvesting AI provider API keys - the OpenAI, Anthropic and similar keys that sit in almost every modern app's environment. Why hunt those specifically? Because a working AI key is liquid money. An attacker can resell access, run their own models on your account, or perform "distillation" to pull capability out of frontier models - all billed to you, and hard to trace back.
For most of the internet's history, the prizes were passwords, card numbers and personal data. In 2026, a single AI key can be worth more than a database dump, because it is instantly usable. Think of it as a credit card with no spending limit stapled to the inside of your app.
Why the AI era cuts both ways
This incident is a clean illustration of how AI changes security in two directions at once.
Attackers now use AI to attack. Railway described "highly sophisticated exploits" from an adversary that had their own uncensored models and serious compute. The cost of probing systems at scale has collapsed. The security bar is rising for everyone, whether you build with AI or not.
And what they steal has changed. Every product shipped in the last two years tends to carry AI keys in its environment. That is a brand-new, high-value class of secret sitting in almost every stack - and most teams added it in a hurry, without treating it like the money it has become.
Why fast-shipped and vibe-coded apps are the softest targets
When AI got added to everything, the same handful of mistakes repeated across thousands of apps: keys hardcoded in the frontend or committed to the repo, a single "god key" with full permissions used everywhere, no monthly spend limit, no rotation, and no monitoring. We see this constantly when we review AI-built products - it is one of the most common security holes in AI-built apps.
None of this means "stop shipping fast." Speed is an advantage. It means the five minutes of hygiene you skip today is the incident you manage later.
How to protect yourself: the checklist
You do not need a security team to get most of the way there. If you build with AI, work through this list.
- Put a hard spend limit on every AI key. Set a monthly budget cap in your OpenAI/Anthropic dashboard. A leaked key with a $50 cap is an annoyance; one with no cap is a five-figure bill overnight.
- One key per app, least privilege, rotate on a schedule. No shared god-keys. Scope each key to what it actually needs, and rotate every few months - and the moment anyone with access leaves.
- Never put a key in the browser. Proxy every AI call through your own backend. If your key ships in frontend code or a mobile app, assume it is already public.
- Keep secrets out of the repo. Use a secrets manager, inject at runtime, and scan your git history - a key committed two years ago still works today.
- Watch usage for anomalies. A sudden spike in spend or requests is often the first and only warning. Railway caught its breach through monitoring. Set alerts on cost and request volume.
- Have a rotation playbook. Know how to roll every key in minutes, not days. Railway contained the damage because it could rotate fast. Practice it before you need it.
- Shrink the blast radius. No public database access, review your GitHub and registry audit logs, invalidate sessions, and turn on two-factor authentication on every platform account.
- Assume breach by design. Build so that one stolen credential cannot unlock everything: separate environments, limited permissions, encrypted secrets, and as few things as possible able to decrypt them.
Our take
Speed and security are not opposites. The teams that win in the AI era are not the ones who ship slowest and most cautiously, nor the ones who ship fastest and ignore the basics. They are the ones who ship fast and bake in the handful of practices above from day one.
This is exactly where human expertise and AI efficiency meet. AI lets a small team move astonishingly fast; experienced engineers make sure that speed does not quietly turn into a liability. It is how we build by default - keys proxied and scoped, spend-capped, secrets managed, usage monitored, and a rotation plan ready before anything goes wrong.
Incidents like Railway's will get more common, not less. That is not a reason to panic - it is a reason to get the fundamentals right now, while it is still a checklist and not an incident. If you are building with AI and want a second pair of eyes on how your keys and secrets are handled, we are happy to take a look.
FAQ
Why are attackers targeting AI API keys?
A working AI provider key is instantly usable money. Attackers can resell access, run their own models on your account, or perform distillation to extract capability from frontier models - all billed to you. Keys are liquid and hard to trace, which is why a single AI key can now be worth more than a stolen database.
What should I do if my AI API key leaks?
Revoke and rotate it immediately, then check your provider billing and usage for abuse. Rotate every other secret the key could reach, review your logs, invalidate active sessions, and set a hard monthly spend cap so the next leak is a minor annoyance rather than a five-figure bill.
How do I protect API keys in production?
Proxy every AI call through your own backend so the key never reaches the browser, use one narrowly-scoped key per app, set hard spend limits, keep secrets in a secrets manager (never in the repo), rotate on a schedule, and set alerts on cost and request volume so an anomaly is caught early.
Should I store secrets in environment variables?
Environment variables are fine for injecting secrets at runtime, but they are not a vault. Keep them out of your git history, encrypt them at rest, limit which systems can read them, and never expose them to the frontend. The Railway incident showed that encrypted environment variables can still be decrypted if the credentials that unlock them are compromised.
Does using a cloud platform make me more or less secure?
Usually more secure, especially if you pick a platform that detects and discloses incidents quickly. But shared responsibility means your key hygiene, spend limits, scoping and rotation are still your job on any platform. Assume breach and design so that one stolen credential cannot unlock everything.
