By Thorsten Meyer | October 22, 2026 | ThorstenMeyerAI.com
Get business pricing on tech for your team
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
On October 21, the cloud platform Railway disclosed that an attacker may have read customer environment variables, the place where most apps keep their API keys. Railway says the attack belongs to a series aimed at “compromising AI inference providers.” Here is what Railway has confirmed and what it has not, why a stolen AI key works like cash, who buys it, what the fight against model distillation has to do with it, and a short checklist for anyone whose agents and apps run on keys like these.
My first reaction to the Railway disclosure was: here we go again. It looks like another grab for Anthropic and OpenAI keys. Tokens are basically cash. You can sell them immediately on a black market where demand is high, and some of the buyers with the deepest pockets are distillers, the operations that copy frontier models by training on their answers. I am fine with AI companies making it hard to copy their product. But the second-order effects are getting pretty wild.
That is my assessment, not Railway’s. Railway has not said which keys were taken, who took them or what they wanted them for, beyond one sentence about AI inference providers. So this piece keeps two things apart: what the companies involved have published, and what I read into it.
I covered the incident briefly in my PHP2Shell and Node.js patch guide. The two events happened on the same day. Railway has not linked them, and neither do I. This article looks only at Railway and at the market for AI keys.
What Railway disclosed
Railway’s security disclosure, dated October 21, 2026, says the company “detected anomalous activity involving systems that store customer environment variables” that morning. According to its investigation so far, “an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents.” Environment variables, Railway notes, “may contain secrets such as API keys or database and registry credentials.”
The key sentence for this article is the next one: “We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers. We have notified these upstream providers to revoke all keys proactively.”
Railway says its initial analysis suggests the impact “may be limited to a subset of users.” It still asks every customer to “immediately roll all environment variables, including any API keys, stored in Railway,” to rotate private registry credentials and to review service logs for unusual activity. It will contact affected customers by email.
The status page shows how disruptive the response was. All times are UTC:
- October 21, 07:24: Railway starts investigating. By 09:28 the dashboard, API and CLI are unavailable and new builds are paused in all regions.
- 20:19: OAuth sessions are invalidated “due to impact from adjacent cache systems.” Users are signed out.
- 21:59: The security notice goes up. Deployments stay paused, including for Enterprise customers, so customers cannot yet deploy the new credentials they are asked to create.
- 22:10: Railway rotates all storage bucket credentials.
- October 22, 01:22: Railway publishes 13 step-by-step guides.
- 03:32: Builds return for Enterprise workspaces, then for Pro at 06:29. At 04:17, all Railway API tokens are invalidated.
- 11:47, latest update as of this writing: builds are available for Pro and Enterprise. Hobby, Free and Trial are still waiting. Railway says deployment wait times are coming down as it works through the queue.
Infographic 01 · Timeline
From “investigating” to “rotate everything” in about 15 hours.
Railway paused builds, signed users out and rotated platform credentials. The ask to customers: replace every secret stored on Railway.
- 21 Oct, 07:24Railway starts investigatingBy 09:28: dashboard, API and CLI unavailable; new builds paused in all regions. (status page)
- 21 Oct, morningAnomalous activity in the systems that store environment variablesEncrypted variables may have been accessed, some decrypted. (disclosure)
- 21 Oct, 20:19OAuth sessions invalidatedUsers signed out “due to impact from adjacent cache systems”. (status page)
- 21 Oct, 21:59Security notice: rotate every environment variableDeployments still paused, so new credentials can’t be deployed yet. (status page)
- 21 Oct, 22:10All storage bucket credentials rotatedNew credentials appear in the dashboard automatically. (status page)
- 22 Oct, 01:2213 step-by-step guides publishedAI usage checks, database rotation, AWS, GCP, GitHub, Stripe. (status page)
- 22 Oct, 03:32–06:29Builds back for Enterprise, then Pro04:17: all Railway API tokens invalidated. (status page)
- 22 Oct, 11:47Latest: Hobby, Free and Trial still waitingDeployment wait times are coming down as the queue is worked through. (status page)
“…part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers.”Railway, 21 Oct 2026. Railway asked those providers to revoke all keys proactively.
Sources: Railway security disclosure (21 Oct 2026); Railway status page (latest update used: 22 Oct, 11:47 UTC).
Powered by Thorsten Meyer AI
As an affiliate, we earn on qualifying purchases.
What Railway has not said
Several things are still open, and they matter for how far anyone should take the story:
- No root cause. Railway has not said how the attacker got in.
- No provider names in the disclosure. The guides published on October 22 show where Railway expects exposure: they cover checking for unexpected usage on Anthropic, OpenAI, OpenRouter and Grok, plus Stripe, GitHub, AWS, Google Cloud and four database types. That is a list of what customers commonly store, not a confirmed list of what was taken.
- No mention of distillation or resale. Railway does not say what the attackers wanted to do with AI keys. The connection to distillers below is my reading of the wider market, backed by what Anthropic, OpenAI and Google have published. It is not a Railway statement.
- No numbers. How many accounts were affected, and whether any stolen key was actually used, is not public.
As an affiliate, we earn on qualifying purchases.
A crazy 72 hours
Railway was not the only bad news this week. On October 21, TechCrunch summed up the mood with the headline “The internet is having a very bad cybersecurity day,” and noted that the incidents “were unrelated to each other.” Unrelated, yes. But several of them are about the same thing: secrets ending up where they should not be.
- TiDB Cloud (PingCAP), disclosed October 19. PingCAP says that between September 9 and October 7 “an unauthorized party used stolen service account credentials to access certain PingCAP internal systems, copy data, and obtain source code.” Exported records included user names, email addresses, project associations and “SQL editor text and errors,” and one exported table “contained encrypted TiDB Cloud API-key values.” PingCAP says there is no evidence that data stored in TiDB was affected. Its recommended customer actions say it has “not found evidence that any were decrypted or used,” and still advise replacing active management API keys. The attacker has made much larger claims, including about customer credentials in support material. PingCAP says those claims “have not been verified,” so I am not repeating them.
- eMudhra, made public October 20. The Indian certificate authority confirms that the keys of eight of its intermediate certificate authorities, created in April 2025, were “cryptographically weak.” According to eMudhra, a step in the key ceremony produced a second, weak set of keys, and those were the ones published. Weak CA keys matter because they could let someone issue trusted certificates for websites they do not control. eMudhra revoked all eight on October 18, says none of them had issued a certificate, and says it knows of no evidence that the weak keys were exploited. Mozilla blocked them in Firefox on October 17, and fixes followed in Go 1.27.3 and 1.26.10 (CVE-2026-111943), the Python certifi bundle, curl’s CA extract and the Node.js release of October 21. One detail for developers: Node.js ships its own CA store, which the documentation calls “a snapshot of Mozilla CA store that is fixed at release time.” Updating the operating system’s certificates does not change it unless you opt in to the system store.
- Plex2Shell, exploited this week. Plex says four flaws in Plex Media Server versions before 1.43.3.10861 “are being actively and widely exploited” (Plex forum notice), and CISA has told federal agencies to patch by October 23 (BleepingComputer). According to Plex, compromised servers have been used to run cryptocurrency miners and proxy software, and any internet-reachable server older than that version should be assumed compromised.
- PHP2Shell and Node.js, October 21. Critical PHP fixes and ten Node.js fixes on the same day, including one where single executable apps and startup snapshots made every process repeat the same random values. I cover both in my patch-and-restart guide.
The common lesson for anyone running AI agents and apps: secrets leak from the places where they pile up. Environment variables on someone else’s platform, service-account credentials, support tickets, code repositories and long-lived keys that nobody rotates are all collection points. Keep secrets out of tickets and repos, keep as few as possible on third-party platforms, and assume that anything stored there for long will eventually have to be rotated in a hurry.
Infographic 09 · A crazy 72 hours
Where secrets and keys leaked this week.
Railway was not alone. Several unrelated incidents had the same core: credentials stored somewhere they could be taken.
Railway
21 Oct · Confirmed by Railway
Environment variables on a platform
Encrypted variables accessed, some decrypted. Customers told to rotate every secret.
TiDB Cloud (PingCAP)
Disclosed 19 Oct · Confirmed by PingCAP
Stolen service-account credentials
Internal systems accessed 9 Sep–7 Oct; records incl. SQL editor text and encrypted API-key values copied. No evidence the keys were decrypted or used.
TiDB Cloud: attacker claims
Since 19 Oct · Not verified by PingCAP
Customer credentials in support material
Much larger figures published by the attacker. Not repeated here.
eMudhra
Public 20 Oct · Confirmed by eMudhra
Weak keys of 8 intermediate CAs
Revoked 18 Oct. No certificates issued from them; no known exploitation. Browsers, Go, certifi, curl, Node.js updated.
Plex Media Server
Exploited this week · Confirmed by Plex
Admin token leak in a 4-flaw chain
“Actively and widely exploited” on versions before 1.43.3.10861. Miners and proxy software on hijacked servers.
Where secrets should not live
- Long-lived keys in environment variables on someone else’s platform
- Credentials pasted into support tickets or chats
- Secrets committed to code repositories
- Service-account keys nobody rotates
Unrelated incidents, one pattern: secrets leak from wherever they pile up.Assessment. TechCrunch: the incidents “were unrelated to each other”.
Sources: Railway security disclosure (21 Oct 2026); PingCAP incident report; PingCAP customer actions; eMudhra statement; Plex security notice; TechCrunch (21 Oct 2026). PHP2Shell and Node.js: see the linked patch guide.
Powered by Thorsten Meyer AI
As an affiliate, we earn on qualifying purchases.
Why an AI key works like cash
An API key for a model provider is a bearer credential. Whoever holds it can spend against your account, and the bill and the logs carry your name. Railway’s own OpenRouter guide puts it in one line: if a key leaked, “it spends your prepaid credits directly,” and the thief “can also route requests to any model OpenRouter offers.”
One founder put it this way on social media: “An API key is basically a credit card for compute now.” Every company running agents is sitting on a pile of them.
The best evidence that a criminal market exists comes from the model providers themselves. Anthropic’s threat intelligence report for September 2026 describes it directly:
- “Access to AI in the form of compromised API keys, session tokens, and devices has increasingly become the sole objective of multiple criminal groups.”
- Those groups “often sell that access through brokers, which often feed into fraudulent AI reseller networks that rotate in new stolen API keys and session tokens until they exhaust their usage.”
- The most common source is ordinary customers who exposed keys in “GitHub, mobile application install files, Docker containers, websites, and chatbots.”
The same report names what an attacker gains from one stolen key: loot, because “stolen keys and accounts have resale value in established markets”; compute, because “attack workloads can run at someone else’s expense”; and cover, because “the activity is attributed to the credential’s legitimate owner.”
This is not new. In May 2024, Sysdig’s threat research team named the pattern LLMjacking: stolen cloud credentials used to run hosted models, with an open-source reverse proxy that could let attackers “sell access to the available LLM models” without exposing the keys behind it. Sysdig estimated the worst case for one victim at “over $46,000 of LLM consumption costs per day.” What has changed since then is the scale, and the buyers.
Infographic 02 · Why a key is cash
Loot, compute and cover in one string of characters.
Anthropic’s September 2026 threat report describes an established criminal market for AI keys. Railway has not said what happened to keys from its platform.
The chain
How a leaked key turns into someone else’s compute.
- Leak. A key sits in an environment variable, a repo, a container image, an app bundle or a chatbot.
- Harvest. Criminal groups make stolen keys and session tokens their “sole objective” (Anthropic).
- Broker. Access is sold through brokers into reseller networks that “rotate in new stolen API keys … until they exhaust their usage”.
- Spend. Buyers use the key for their own work, including distillation traffic and attack workloads.
- Bill. The usage, the cost and the attribution land with the legitimate key holder.
What it can cost
Documented examples
- Over $46,000 a day: Sysdig’s worst-case estimate for one victim of LLMjacking (May 2024).
- Prepaid credits: a leaked OpenRouter key “spends your prepaid credits directly” and can call any model (Railway guide).
- Your rate limits: a stolen key also burns the quota your own product depends on.
A key is a bearer credential: whoever holds it can use it until it is revoked.
Loot
“Stolen keys and accounts have resale value in established markets.”
Compute
“Attack workloads can run at someone else’s expense.”
Cover
“The activity is attributed to the credential’s legitimate owner.”
“An API key is basically a credit card for compute now.”A founder on social media
Sources: Anthropic Threat Intelligence Report (Sep 2026); Sysdig (6 May 2024); Railway OpenRouter guide.
Powered by Thorsten Meyer AI
encrypted environment variable storage
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Who buys: distillers with deep pockets
Distillation is a normal technique. A large “teacher” model answers many prompts, and a smaller “student” model is trained to imitate those answers. Labs do it with their own models all the time. It becomes a problem when someone does it to a competitor’s model at industrial scale, without permission, to copy capabilities that cost billions to build.
The three largest Western model providers have all published evidence of this:
- Anthropic, February 23, 2026: in Detecting and preventing distillation attacks, it attributes campaigns to DeepSeek, Moonshot and MiniMax that generated “over 16 million exchanges with Claude through approximately 24,000 fraudulent accounts.” Access ran through “commercial proxy services which resell access to Claude,” in what Anthropic calls “hydra cluster” networks. One proxy network “managed more than 20,000 fraudulent accounts simultaneously.”
- Google, February 12, 2026: its threat intelligence group reports a rise in “distillation attacks,” including one campaign of over 100,000 prompts aimed at Gemini’s reasoning. It attributes the attacks it saw to “private sector entities all over the world and researchers,” not to state hacking groups, and calls unauthorized distillation of Gemini a violation of its terms of service.
- OpenAI, February 12, 2026: in a memo to the U.S. House Select Committee on the Chinese Communist Party, reported by Bloomberg and Rest of World, OpenAI accused DeepSeek of distillation and said it had seen accounts tied to DeepSeek employees reach its models “through obfuscated third-party routers and other ways that mask their source.”
- OpenAI, September 30, 2026: OpenAI says it disrupted a coordinated model-distillation campaign that tried to extract protected reasoning, peaking at 16,000 requests from more than 4,000 users on July 24 and 25. It attributes a core cluster to individuals associated with Moonshot AI.
The link to stolen keys is spelled out in Anthropic’s September report. Labs that are not allowed to use Claude route their traffic through proxy services, sometimes called “transfer stations.” These services build accounts from “false identities, fake or stolen credit cards, and stolen API keys,” and “will often use stolen API credentials belonging to legitimate companies or individuals to give unauthorized entities access to US frontier models.”
That is the market I mean. A distiller needs millions of answers from the best models. A clean key from a paying customer with a good history is exactly the input that gets those answers past fraud checks, at least until someone notices the bill.
Infographic 03 · What distillation is
Copying a model by learning from its answers.
Labs distill their own models all the time. The fight is about doing it to someone else’s model, at scale, without permission.
How distillation works
A standard training method
- Ask. Send a strong “teacher” model millions of carefully designed prompts.
- Collect. Keep the answers, and above all the reasoning behind them.
- Train. Teach a smaller “student” model to imitate those answers.
- Ship. The student gets close to the teacher’s skills for a fraction of the cost.
When it becomes an attack
Unauthorized, at industrial scale
- Done to another company’s model, without permission, in violation of its terms.
- Run through networks of fraudulent accounts and reseller proxies to avoid detection.
- Targets the most valuable skills: agentic reasoning, tool use, coding.
- Copies capabilities, but not necessarily the safeguards (Anthropic).
Why stolen keys help
Distillers need volume that looks like normal use. Anthropic says proxy services “will often use stolen API credentials belonging to legitimate companies or individuals” to give unauthorized labs access. A real customer’s key carries a payment history and trusted traffic.
Railway has not linked its incident to distillation. This connection is the author’s reading of published provider reports.
Sources: Anthropic (23 Feb 2026); Anthropic Threat Intelligence Report (Sep 2026); Google Threat Intelligence Group (12 Feb 2026).
Powered by Thorsten Meyer AI
Infographic 04 · Documented cases
Three providers, one pattern: distillation at industrial scale.
What Anthropic, Google and OpenAI have published about distillation campaigns and the reseller networks behind them in 2026.
| Date | Who reports | What they say | Source |
|---|---|---|---|
| Feb 12, 2026 | OpenAI | Memo to a House committee accuses DeepSeek of distillation via “obfuscated third-party routers”. | Bloomberg (12 Feb 2026) |
| Feb 12, 2026 | Rise in distillation attacks on Gemini; one campaign over 100,000 prompts; mostly private firms and researchers. | Google Threat Intelligence Group (12 Feb 2026) | |
| Feb 23, 2026 | Anthropic | DeepSeek, Moonshot, MiniMax: 16M+ exchanges via ~24,000 fraudulent accounts; one proxy ran 20,000+ accounts. | Anthropic (23 Feb 2026) |
| Sep 2026 | Anthropic | Proxies (“transfer stations”) build access from false identities, stolen cards and stolen API keys. | Anthropic Threat Intelligence Report (Sep 2026) |
| Sep 30, 2026 | OpenAI | Campaign to extract protected reasoning; peak of 16,000 requests from 4,000+ users; core cluster linked to Moonshot AI. | OpenAI (30 Sep 2026) |
| Oct 12, 2026 | Anthropic | New defenses cut harvested data by about 90–99%; tens of thousands of accounts banned. | Anthropic (12 Oct 2026) |
All attributions are the reporting companies’ own. The accused labs have not confirmed them. OpenAI’s memo is cited from press reports.
Sources: Anthropic (23 Feb 2026); Anthropic Threat Intelligence Report (Sep 2026); Anthropic (12 Oct 2026); Google Threat Intelligence Group (12 Feb 2026); OpenAI (30 Sep 2026); Bloomberg (12 Feb 2026).
Powered by Thorsten Meyer AI
The second-order effects
Here is the part I find most interesting. The defenses work, and that is exactly what changes the incentives.
On October 12, Anthropic published an update, Strengthening our defenses against distillation attacks. It says its new methods “have reduced the amount of data harvested by distillers by around 90 to 99%,” and that it has banned “tens of thousands of accounts associated with distillation, often in less than two hours.” It is also honest about the cost:
- “We’ve turned away meaningful revenue and trillions of tokens’ worth of paying traffic from distillers.”
- “Some of our changes have also required legitimate users to make updates to their integrations.” New API accounts created on or after August 31, 2026 can no longer edit Claude’s prior context on the newest models.
- Its classifiers can block benign requests in “fewer than 0.1% of cases,” and since September 24 Anthropic charges for requests that are blocked before Claude responds in areas such as distillation.
- Its February post adds stricter verification for educational accounts, security research programs and startups, “the pathways most commonly exploited for setting up fraudulent accounts.”
Now follow the money, and this is my reading, not a published finding. If fake accounts get banned within hours and new accounts face more scrutiny, then an established customer’s key is worth more. It comes with history, a payment method that works and traffic the provider already trusts. Every defense that makes fraudulent signups harder raises the price of a real one. That turns any place where many real keys sit together into a target: deployment platforms, CI systems, agent frameworks and the wrapper services that call models on your behalf.
Anthropic’s September report already shows that shift. It describes attackers compromising “AI wrapper services’ implementation of LiteLLM” and using prompt injection “to exfiltrate the production API keys,” and one group that broke into an AI vendor’s evaluation sandbox and “took its production keys first.” Railway’s own words, “a series of attacks recently targeting platform companies,” fit that pattern.
The effects fall on people who did nothing wrong:
- Honest customers carry the friction. Integration changes, verification steps, rate limits for unusual patterns and the occasional blocked request are the price of keeping distillers out.
- The bill lands with the key holder. Until you notice, the stolen usage is yours. So is the attribution.
- Mass revocation causes outages. Railway asked providers to revoke all keys proactively, and told customers to rotate everything. Railway’s own status page says customers were “unable to update your applications with new credentials” while builds were paused. A security measure becomes downtime.
- Agents multiply the attack surface. Every new agent, integration and side project tends to get a key, often the same shared one, stored in another environment variable on another platform.
None of this means providers should stop defending their models. Making copying hard is legitimate. But the cost of that defense does not stay with the providers. It spreads to every company that stores keys, and to every platform that stores keys for them.
Infographic 05 · Second-order effects
The defenses work. That is what moves the target.
Anthropic says it turned away “trillions of tokens’ worth of paying traffic” from distillers. The cost of that fight spreads to everyone who stores keys.
Real keys gain value
Assessment
Fake accounts are banned within hours and new signups face more checks, so an established customer’s key becomes the better entry ticket.
Platforms become targets
Documented
Railway: attacks on “platform companies”. Anthropic: keys taken from LiteLLM wrapper services and an AI vendor’s evaluation sandbox.
Honest customers carry friction
Documented
Anthropic: integration changes for new accounts since 31 Aug, <0.1% false positives that are now charged, stricter checks for education and startup accounts.
The bill and the blame land with you
Documented
Stolen usage runs on your account and is “attributed to the credential’s legitimate owner” until you notice.
Mass revocation means downtime
Documented
Railway asked providers to revoke all keys and paused builds, so customers were “unable to update your applications with new credentials”.
Agents multiply the surface
Assessment
Every agent, integration and side project tends to get a key, often a shared one, in yet another environment variable.
“I’m OK with companies making it hard to copy their product. But the second-order effects are pretty wild.”Thorsten Meyer, assessment
Sources: Anthropic (12 Oct 2026); Anthropic Threat Intelligence Report (Sep 2026); Anthropic (23 Feb 2026); Railway security disclosure (21 Oct 2026); Railway status page. Cards marked “Assessment” are the author’s reading.
Powered by Thorsten Meyer AI
The 10-minute fix
The same founder who called a key a credit card for compute also offered the short version of what to do, and I agree with it: rotate every key tonight, set a hard monthly spend limit in each AI dashboard, give every agent its own key, and turn on usage alerts.
I checked what the major consoles actually offer as of October 2026. The controls exist, but they differ:
| Provider | Hard spend cap | Per-key or per-project scope | Short-lived options |
|---|---|---|---|
| Anthropic (Claude Console) | Yes: org limit; workspace spend limits with alerts (not on the Default Workspace) | Keys scoped to a workspace; usage filterable by key | Key expiration (3 hours to 30 days or custom); workload identity federation |
| OpenAI | Yes: hard spend limit per organization or project; spend alerts alone “do not enforce a cap” | Project keys, service accounts, per-project limits | Key expiration date; workload identity federation |
| Google Gemini API / Vertex AI | Spend cap budgets for one project and one service; Gemini project caps are experimental, with about 10 minutes of lag | Keys restricted to the Gemini API by default; origin restrictions | Workload Identity Federation instead of service account keys |
| AWS Bedrock | Not a cap by default; Budget actions can apply an IAM policy or SCP when a budget is hit | IAM roles and policies | Short-term Bedrock API keys up to 12 hours; long-term keys “only for exploration” |
| OpenRouter | Credit limit per key, recommended “on every key” | Per key | Optional expiration timestamp |
Three practical notes from the documentation. A spend limit protects your budget, not your secret: a capped key that leaks can still be used up to the cap. Alerts tell you after the fact, so set them low. And enforcement is not instant everywhere: OpenAI says recorded spend “can slightly exceed the configured amount,” and Google’s experimental Gemini caps allow overages during a short delay.
Infographic 06 · The 10-minute fix
Rotate, cap, separate, alert.
Four controls that limit what a stolen AI key can cost you. None of them needs new software.
Ten minutes, four steps
The short version, per key and per console.
- Rotate every key tonight
Create the new key, deploy it, then revoke the old one. Start with keys stored on any hosting platform. - Set a hard monthly spend limit
Anthropic and OpenAI enforce hard caps; Google offers spend-cap budgets; AWS needs a budget action. - Give every agent its own key
Per agent, per service, per environment. Name it so you know what broke. - Turn on usage alerts
Set thresholds low. An alert tells you after the fact; a cap limits the damage.
What the consoles offer
Checked against vendor docs, 22 Oct 2026
| Provider | Spend control | Details |
|---|---|---|
| Anthropic | Hard cap | Org limit + workspace spend limits with alerts |
| OpenAI | Hard cap | Org or project; alerts alone “do not enforce a cap” |
| Google Gemini / Vertex | Cap, newer | Spend-cap budgets per project and service; Gemini caps experimental, ~10 min lag |
| AWS Bedrock | Via action | Budget actions apply an IAM policy or SCP |
| OpenRouter | Per key | Credit limit on each key, recommended for every key |
A cap protects the budget, not the secret. Enforcement can lag: OpenAI says spend “can slightly exceed the configured amount”.
Sources: Anthropic workspaces; OpenAI spend limits; Google Cloud spend caps; Gemini API billing; AWS Budgets actions; OpenRouter. Checklist wording based on a founder’s social post.
Powered by Thorsten Meyer AI
One key per agent
The most underrated control on that list is the boring one: one key per agent, per service and per environment. A shared key means a leak anywhere is a leak everywhere, and the usage graph cannot tell you which component went rogue. Separate keys mean you can revoke one without taking down the rest, and an unexpected model in one key’s usage stands out. Railway’s Anthropic guide uses exactly that signal: “If a key you only use with one model suddenly shows another, that’s a strong signal.”
The pattern that follows from the provider documentation:
- Separate workspaces or projects for production, staging and experiments, each with its own spend limit.
- One key per agent or service, named after it, with an expiration date where the provider supports one.
- Short-lived credentials where possible. Anthropic and OpenAI now document workload identity federation, which Anthropic describes as “replacing static API keys with tokens that expire in minutes rather than never.” AWS recommends temporary credentials through IAM roles, and Google recommends Workload Identity Federation over service account keys.
- Keys in a secret manager, not scattered across platforms. If your deployment platform stores your variables, you are trusting its security as much as your own. Railway’s incident is a reminder of that, not proof that any one platform is worse than another.
- Secret scanning on. GitHub scans public repositories for free and blocks pushes of known secret types to public repositories by default; for private repositories, this needs GitHub Secret Protection. Anthropic says it automatically deactivates Claude keys that GitHub finds in public repositories, and Railway’s OpenAI guide says OpenAI disables keys it finds on the public internet.
Infographic 07 · One key per agent
Small keys, small blast radius.
The cheapest way to limit a leak is to make sure no single key can reach everything.
Shared key
Avoid
- One key in five services and three agents
- A leak anywhere is a leak everywhere
- Revoking it takes everything down
- Usage graph can’t tell you which part went rogue
- Often no expiry, no cap
One key per agent
Baseline
- Separate workspace or project per environment, each with a spend limit
- One named key per agent or service
- Expiration date where the provider supports it
- Revoke one key, the rest keep running
- Unexpected model or volume on one key stands out
Short-lived credentials
Where available
- Workload identity federation: Anthropic and OpenAI now document it; tokens “expire in minutes rather than never”
- AWS: IAM roles and temporary credentials; short-term Bedrock keys last up to 12 hours
- Google Cloud: Workload Identity Federation instead of service account keys
- Secret manager as the source of truth, not scattered platform variables
The signal to watch
“If a key you only use with one model suddenly shows another, that’s a strong signal.”
Railway’s guide to checking Anthropic usage. Secret scanning helps too: GitHub scans public repositories for free, and Anthropic deactivates Claude keys GitHub finds in public code.
Sources: Anthropic WIF; OpenAI production best practices; AWS Bedrock API keys; Google Cloud WIF; Railway Anthropic guide; GitHub secret scanning.
Powered by Thorsten Meyer AI
If you run anything on Railway
Railway’s guidance, and the provider-specific guides it published on October 22, come down to this:
- Rotate every secret stored in Railway, not just AI keys: model providers, payment providers, database passwords, cloud credentials, registry credentials and webhook secrets. Create the new key first, then revoke or disable the old one.
- Redeploy once builds are available for your plan. A new value in the dashboard does nothing until the service runs with it. As of the latest update, Pro and Enterprise can build. Hobby, Free and Trial are next.
- Replace Railway API tokens. Railway invalidated all of them on October 22. Integrations using the public API need new ones.
- Check usage per key for the exposure window. In each AI console, group usage by API key and compare token volume and model mix with your normal traffic. Look at cost, logs and members you did not invite. For OpenRouter, Railway recommends disabling rather than deleting the old key, so its history stays available.
- Check cloud accounts. For AWS and Google Cloud keys, Railway’s guides point to CloudTrail and Cloud Audit Logs and to billing reports. Google’s guide notes that “Compute, GPU, and Vertex AI usage are the common targets.”
- Keep evidence before you clean up, and contact the provider’s support if you find usage you did not generate.
Infographic 08 · What to do now
Rotate, redeploy, then look for usage you didn’t make.
Railway says the impact may be limited to a subset of users, but asks everyone to act. Rotation only takes effect after a redeploy.
Six steps
From Railway’s notice and its 22 Oct guides
- Rotate every secret stored in Railway: AI providers, payments, databases, cloud, registries, webhooks. New key first, then revoke the old one.
- Redeploy once builds are available for your plan. A new value does nothing until the service runs with it.
- Replace Railway API tokens. All were invalidated on 22 Oct.
- Check usage per key for the exposure window: token volume, model mix, cost, logs, unknown members.
- Check cloud accounts: CloudTrail and Cloud Audit Logs, billing reports. “Compute, GPU, and Vertex AI usage are the common targets.”
- Keep evidence, then contact the provider’s support if you find usage you didn’t generate.
Can I redeploy yet?
Builds return plan by plan
| Plan | Builds (22 Oct, 11:47 UTC) |
|---|---|
| Enterprise | Available since 03:32 |
| Pro | Available since 06:29 |
| Hobby | Next |
| Free · Trial | After Hobby |
Railway’s guides
- Anthropic usage · OpenAI usage · OpenRouter usage
- AWS access · Google Cloud access
- Grok, Stripe, GitHub and four database guides: linked from the status page
OpenRouter: disable rather than delete the old key, so its usage history stays available for review.
Sources: Railway security disclosure (21 Oct 2026); Railway status page; Railway guides of 22 Oct 2026 linked above.
Powered by Thorsten Meyer AI
A product idea that writes itself
The founder who called keys credit cards also sketched a business: a tool that finds every AI key in a company, rotates them weekly and alerts on unusual usage, for about $99 a month. I think the demand is real. Pieces of it already exist inside the platforms, such as OpenRouter’s key audit view, which “shows which API keys lack a spend limit or an expiration,” and the expiry and federation features above. What is missing is the layer across all providers that a small team can actually run. Whoever builds it should start with inventory, because most companies cannot say today how many AI keys they have or where they live.
My assessment
The Railway disclosure is still incomplete. We do not know how the attacker got in, how many customers were affected or whether any stolen key has been used. Railway’s statement about AI inference providers is the only motive it has given, and the link to distillers is my inference, not Railway’s.
But the market around it is well documented. Stolen AI keys are resold, rotated through reseller networks until they run dry, and used to get past the defenses that providers built against model copying. Those defenses are working, and that is what makes real customers’ keys more valuable and the platforms that hold them more attractive targets.
So treat AI keys like money, because the people stealing them already do. Rotate them, cap them, give every agent its own, and watch the usage. If you are on Railway, start today.
This article reflects the Railway disclosure, status page and guides, and the provider publications available on October 22, 2026, 11:47 UTC. The investigation is ongoing; check the linked sources for updates. The views on distillation and second-order effects are my own assessment.
Sources: Railway security disclosure, status page and guides for Anthropic, OpenAI, OpenRouter, AWS and Google Cloud; Anthropic, Detecting and preventing distillation attacks (Feb 23, 2026), Threat Intelligence Report, September 2026 and Strengthening our defenses against distillation attacks (Oct 12, 2026); Google Threat Intelligence Group (Feb 12, 2026); OpenAI, Disrupting a coordinated model-distillation campaign (Sep 30, 2026); Bloomberg and Rest of World on OpenAI’s memo; Sysdig (May 6, 2024); for the 72-hour context: TechCrunch, PingCAP incident report and customer actions, eMudhra, Go issue 82345, Node.js CLI documentation, Plex and BleepingComputer; provider documentation from Anthropic, OpenAI, Google Cloud, AWS, OpenRouter and GitHub.
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
