Railway Says Stolen AI Keys Ran Up About $740,000 in Charges

Railway said on Tuesday, according to The Hacker News, that an intruder who entered its systems in October had decrypted customer secrets. The company places the maximum exposure at 1.85 percent of its workspaces, about 100,000. Railway describes that figure as an upper bound, not a count of secrets confirmed as stolen, because its logs identify environments rather than individual variables.

What happened

Railway lets customers deploy apps and store secrets such as API keys, database passwords and registry credentials as environment variables. According to the company's incident report as relayed by BleepingComputer, the attacker reached those stored values in the decrypted form for at most about 100,000 workspaces. Database queries were built to surface AI provider keys, although one query also matched cloud, database and payment service credentials.

The intrusion began with a flaw that let the attacker partly escape the isolation of Railway's build system, according to CybersecurityNews. From there, the attacker reached a misconfigured trust rule in the cloud setup and obtained a credential that could unlock the encryption chain. CybersecurityNews reports that the attacker decrypted variables in a window on 21 October. Railway first told customers to rotate their secrets on 21 October, according to TechCrunch.

Railway told customers in an October update that it could not refund them for spend made with compromised keys, and advised them to contact the AI providers directly. Railway later changed that position. It now says it will cover charges that providers refuse to refund. CloudComputing News reports that one provider, OpenRouter, has kept a no-refund policy, leaving Railway to cover those charges.

Railway believes the attackers wanted AI credentials for resale or for use in AI model distillation, according to BleepingComputer. The company links the case to a wider run of attacks on AI developer platforms that the security firm Wiz has called "Black October". The Hacker News notes that Wiz lists this breach among incidents disclosed in October by at least nine AI developer platforms. Wiz does not independently attribute the Railway breach, according to CybersecurityNews.

Why it matters for businesses that automate work

Most automation today runs on a handful of AI keys. A workflow that drafts invoices, sorts supplier emails or writes reports needs a key to call the AI model, and that key usually lives in a hosting platform, an automation tool or a script. If the key leaks, the cost lands on whoever pays the AI bill, not on the platform that lost it.

The Railway case also shows that the damage can reach past AI spending. The stolen data included linked-account tokens for 1,852 users, including GitHub OAuth tokens and AI agent keys, according to BleepingComputer. Railway reset them and notified each user. It says it found no logins to customer accounts using the stolen credentials, and no evidence that customer databases were accessed.

What changes in practice for a business that automates work

The first step is an inventory. List every place an AI key or cloud credential is stored: hosting platforms, automation tools, spreadsheets, shared drives and developer laptops. For this incident, Railway advised customers to treat anything stored before 21 October as potentially exposed, according to a summary published by Windows Forum. Rotate those keys, then check the usage logs at each AI provider for requests you do not recognise.

Second, set a spending limit and an alert on every AI account. A provider dashboard can stop a runaway bill before it reaches five or six figures. Use separate keys for each workflow, so that a leak in one tool does not expose every process. Where a provider allows it, limit a key to the models and actions it needs.

Third, decide who holds the keys. In a five-person firm, the owner or one operations lead may be the only person who should see the credentials. In a larger group, keys should sit in a secrets manager with access logs, not in personal notes. The point is the same at both sizes: fewer people and tools should be able to read a key.

Fourth, review connected accounts. If a workflow uses GitHub or another single sign-on link, check which apps have access and remove any you no longer use.

There are limits to what a business can do. Automation cannot stop a breach at a platform you do not control. It can shorten the time between a leak and a response. A person still has to read the alerts, decide which keys to rotate and check invoices from providers. Results depend on how many keys your business holds and where they are stored, which a review of your own setup measures.

What to watch next

Three things are worth tracking. First, whether AI providers change their refund rules for stolen-key charges. Railway's account shows that refund decisions sit with each provider. Second, whether Railway publishes further detail on the attack path, since its reports so far have been described as incident reports rather than independent audits. Third, whether other platforms named in the Black October wave issue similar disclosures.

Railway's exact figures are its own estimates. The $740,000 is described as an estimate, and a separate figure of more than $1.1 million reported by the Wall Street Journal includes cryptocurrency theft, according to Gadget Review. Use the platform's own notice and your provider invoices as the reference points for your own exposure.