After Railway’s AI-Key Breach, How Should You Store OpenAI and Anthropic Credentials?

AI apps live and die by their keys. An OpenAI or Anthropic key is not just a password to an API. It is a line of credit. Anyone who holds it can run models in your name, read whatever those requests contain, and leave you with the bill.

On 10 November 2026, the hosting platform Railway published a detailed report on a security attack that began in October. The company said the attacker’s main target was AI provider credentials, which could be sold on for unofficial use, including distillation — the practice of using one model’s outputs to train another. Railway estimated unauthorised spend on the stolen keys at about 740,000 US dollars. It also said the decrypted data could have included more than AI keys, but its forensics did not show that customer databases were accessed.

You do not have to be a Railway customer for this to matter. Many teams store the same kind of keys in environment variables on a hosting platform, in a CI dashboard, or in a single .env file that too many people can read. Here is what Railway reported, and a practical way to store and rotate AI keys so a similar incident hurts less.

What happened, in simple terms

Railway is a platform where you can build, host and deploy applications. When you deploy, the platform often runs a build for you, and it stores the environment variables your app needs — database URLs, API keys, and similar secrets.

According to the 10 November report, an attacker started probing Railway’s build system on 20 October 2026 at 06:50 UTC, which is 12:20 p.m. IST that day. At 07:28 UTC (12:58 p.m. IST), the attacker used a previously unknown flaw to partly escape the isolation around a build. Work that should have been trapped in its own box was able to read some files on the shared machine, and that gave the attacker a credential the build servers used to talk to internal systems.

A Railway engineer was paged at 13:58 UTC (7:28 p.m. IST) after unusual calls to a registry service. The team started an incident response, stopped builds, and began shutting down the path the attacker had used. The attacker had already used the stolen build credential to read a limited set of past build records, and to fetch a copy of Railway’s own internal code. Railway said it has no indication that the attacker downloaded snapshots or repositories of Railway customers at that stage. The attacker did read the stored histories of 353 builds, including sealed variables in those histories, between 13:50 and 15:30 UTC on 20 October.

Later that evening, Railway revoked the build credential and limited what build servers could reach. Builds were turned back on after a first fix. The attacker then found a second way in, early on 21 October, through a misconfigured cloud login (an OIDC binding — a rule that says which automated job is allowed to request a short-lived cloud credential). From there, the attacker reached credentials that could read and decrypt a subset of customer environment variables.

Environment variables on Railway use envelope encryption. That means each environment has its own data key, and that key is itself encrypted by a root key held in a cloud key-management service. One stolen password should not unlock the whole platform. Even so, for a window on 21 October, the attacker was able to decrypt some of those variables. Database logs showed they searched for names that looked like AI keys, and favoured customers with a large number of variables.

Railway disabled the relevant cloud credentials at 07:14 UTC on 21 October (12:44 p.m. IST), halted builds again, and says the attacker had no access to any customer data after 09:25 UTC (2:55 p.m. IST) that day. It later invalidated every user session and token, and rebuilt systems it did not fully trust.

A compact timeline

Apps that were already running did not go down just because builds were paused. The pain for many customers was different: they could not deploy a new version, and if they had already revoked a credential, they could not easily push the replacement until builds returned.

What was at risk, and what was not

Railway can show that at most 1.85 percent of workspaces, about 100,000, could have had any environment variables decrypted. The logs identified a subset of environments, not each individual variable, so the figure is an upper bound. Railway emailed customers it judged to be at high risk. Any further data the attacker took but could not decrypt before the credential was disabled should remain unreadable, because that credential was turned off.

Separately, 1,852 users had linked-account tokens reset. Those included “bring your own key” agent keys and GitHub OAuth tokens. Railway said it notified each of those users and found no logins to Railway accounts using credentials taken in the incident.

Starting at 09:25 UTC on 21 October, Railway asked GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google and Stripe to revoke potentially compromised keys. It could not yet say exactly which keys were exposed, so it sent hashes of every key it held. Some vendors revoked additional keys as a precaution.

Railway’s investigation suggests AI keys were the main prize. A further query also matched cloud, database and payment-service credentials. The company said forensics did not indicate that customer databases were accessed. That is not the same as “no other secrets existed in the decrypted set.” If you were a customer, or you reused the same keys in another host, you should still rotate anything that could have been in those environment variables.

Railway also said other platforms that hold AI keys disclosed similar thefts between 6 and 23 October 2026. AI keys have become one of the most valuable secrets a host stores, because they are easy to spend and easy to resell.

Money, refunds, and what to check on your bill

Unauthorised usage observed after the theft ranged from coding agents to training pipelines. The estimated extra spend was about 740,000 US dollars. Railway said it is working with providers on refunds, and that it will cover token losses itself where a provider will not.

If you had keys in Railway, or you share keys across hosts, do this now:

1. Open every AI provider bill from mid-October 2026 onward and look for spikes, new models, or usage in regions and projects you do not recognise.
2. Rotate the key first, then investigate. A key that is still live can keep costing money while you read a dashboard.
3. Ask the provider to revoke the old key and, if you saw unauthorised spend, open a refund request. Railway published vendor-by-vendor guidance in its report and asked customers to file a form so it could help.
4. Check GitHub, GitLab, cloud and payment tokens if those were stored in the same environment. Do not assume only the OpenAI key was interesting.

Refund rules differ by vendor and can change. Use the provider’s current policy and your own invoices. This article is not a guarantee that a charge will be reversed.

How to store AI API keys from now on

The safest mental model is this: an AI key is a production credential, as sensitive as a payment secret or a cloud root key. It should not live in a git repository, in a chat log, or as the only copy in a hosting UI.

Here is a practical standard you can apply to a Laravel or Node.js app, whether you host on Railway, another platform, or your own virtual machine.

1. Use a separate key per environment and per product. Local development, staging and production should not share a key. If staging leaks, production should keep working, and the blast radius should stay small.
2. Put a spending limit and usage alert on every key. Most providers let you cap monthly spend or set a budget alarm. A theft that is noticed in an hour is a bad day. A theft that runs for a week is a finance incident.
3. Prefer a secret manager for production keys. Store the official copy in a service designed for secrets, with audit logs and short-lived access. Let your app read it at startup or through a tightly scoped role. The hosting dashboard should not be the only copy, and it should not be visible to every teammate.
4. Never commit keys, and never put them on the command line in plain text. Load them from the environment. This also protects you if an AI coding assistant saves a command into a project file.
5. Restrict the key’s powers. If the provider allows project-level keys, IP rules, or disabled features you do not need, turn those on. A key that can only call one model from one project is less useful to a thief than a key that can do everything in the account.
6. Split “the key that talks to OpenAI” from “the keys that open your database.” Different systems, different secret paths, different people with access. The Railway attacker looked for AI keys first, but a mixed bag of variables in one blob is a gift if decryption succeeds.
7. Rotate on a schedule, and rotate immediately after a vendor incident. A rotation drill twice a year teaches you whether your app can survive a key change. After a report like this, do not wait for a personal email. If you used the platform during the window, rotate.
8. Watch the bill automatically. A daily check of token usage, sent to engineering and finance, is more useful than a dashboard nobody opens.

If you were a Railway customer during 20–21 October 2026, read any email the company sent you. The 100,000-workspace figure is an upper bound, and Railway contacted accounts it judged to be at high risk. Not getting an email is not a complete all-clear if your keys were stored there and have not been rotated.

What this means for teams building AI products

AI features have moved from experiments to production faster than secret handling has. A prototype key that still sits in a shared chat or a company-wide environment file is now a production risk.

A good design treats model access as one small internal module. That module reads the secret, calls the model, enforces a budget, and logs usage without logging a sensitive prompt. When a host reports an incident, you change the secret in one place. You should already know where keys live, who can see them, and how quickly you can rotate them. That work is cheaper than an unexplained bill, or a customer prompt that travelled with a stolen key.

How we approach this at DayDecoder

DayDecoder is a custom software company in Ahmedabad. We build AI agents, chatbots and standard web applications on Laravel and Node.js. When we add a model provider to a product, we treat the API key as a production secret: one key per environment, alerts on spend, and a rotation path that does not require a full rewrite.

If you want help reviewing how your app stores OpenAI, Anthropic or other AI credentials, or you need to rotate keys after a vendor incident, use the contact form. We reply within one business day.

FAQ

Do I need to worry if I do not use Railway?

You should still look at how your own keys are stored. Railway’s report is one detailed example of a wider pattern: platforms that hold AI keys have been targeted. The storage habits below apply on any host.

Railway said at most 1.85 percent of workspaces were in range. Does that mean most customers were safe?

It means most workspaces were outside the decrypted set, according to the 10 November 2026 report. The figure is an upper bound. If you stored keys on the platform during the incident window, rotating them is still the conservative step.

Were customer databases stolen?

Railway said forensics did not indicate that customer databases were accessed. Some decrypted variables could still have included cloud, database or payment credentials, so those should be rotated if they were stored in the same environment.

When was the official report published?

The full incident report is dated 10 November 2026 and was last updated at 18:02 UTC that day, which is 11:32 p.m. IST. The attack itself ran from 20 October into 21 October 2026.

Will unauthorised OpenAI or Anthropic charges be refunded?

Railway said it is working with providers and will cover costs where a provider will not. Each vendor has its own policy. Open your bill, rotate the key, and follow the current refund process. This article cannot promise a refund.