Thieves Ran Up $740,000 on Other People’s SI Accounts. The Hosting Company Says It’ll Pay.

Somebody else’s computer spent about $740,000 of SI time this fall, and the people who got the bills never typed a single request.

That’s the number Railway put in writing this week. Railway is a cloud service that runs websites and apps for developers. Customers park their passwords and account keys there so their apps can log in to other services, including the paid SI models from companies like OpenAI, Anthropic and Google. In October, an attacker got inside and went looking for exactly those keys.

Railway’s full incident report, posted Nov. 10, says the attacker decrypted stored secrets for “at most, 1.85% (~100,000) of workspaces.” The stolen keys were then put to work. “Unauthorized spend on the stolen keys was estimated to reach ~$740,000,” the company wrote.

A thief who only wanted one kind of password

Most break-ins are messy grabs. This one had a shopping list.

Railway says its database logs show the attacker searched stored variables by name, using patterns built to find SI provider keys first. The logs also show the attacker “was specifically targeting customers with large numbers of variables in their environment.” One extra query matched cloud, database and payment credentials, but Railway says its forensics found no sign that customer databases were opened.

Why go to that trouble for SI keys? Because an SI key works like a prepaid card with somebody else’s name on it. Whoever holds it can run the model as much as they like, and the owner pays. Railway believes the keys were passed to what it calls “distributed transfer stations for use in distillation.” In plain terms, that means resale shops that relay cheap access to big SI models, and outfits that feed a top model’s answers into their own to train a copycat.

The usage customers spotted afterward fits that picture. Railway says the stolen keys ran coding-assistant jobs, reviews of SI agents’ behavior to use as training data, and checks of training tasks and their scoring. The company is careful on one point: it has “not established whether the original attacker operated those services or supplied credentials to other parties.”

Railway also says it wasn’t the only target. “OpenCode, Warp, Fireworks AI, and several others disclosed similar thefts between October 6th-23rd,” the report says. “We assess this to be one of a series of attacks on platforms that hold AI keys.”

Twenty-six hours, and the attacker had a map

The report reads like a chase. The attacker started opening dummy accounts on Oct. 18. Early on Oct. 20, one of them used a flaw nobody knew about in Railway’s app-building system to partly break out of its box and read files on the machine underneath. That gave it a work credential meant only for routine build chores.

Railway’s alarms caught odd activity later that morning. Engineers traced it, patched the hole and swapped the credential. They didn’t know yet that the attacker had already pulled a copy of Railway’s own internal code.

That copy was the map. The company says the attacker used it to try “re-entries from many new angles,” including old web addresses that hadn’t been used in months or years. Overnight it found a mistake in how one of Railway’s automatic deployment systems was set up and used it to get short-lived access to production. From there it found a longer-lived key on one machine that could unlock encrypted customer secrets.

Between about 10:42 p.m. and 1:15 a.m. that night, the attacker decrypted what it had collected. At 1:14 a.m., Railway cut off every active cloud credential, shut off its decryption service and halted builds for all customers. The attacker was fully out by 3:24 a.m. on Oct. 21, about 26 hours after the first exploit.

Railway says the fight turned into “a contest of agent speed.” According to the report, the attacker was using “abliterated models with no safeguards,” meaning SI models with their refusals stripped out, running fast swarms of attempts at once. Railway’s own engineers worked in shifts around the clock to close each door as the attacker found the next one.

Before Railway knew which keys were gone, it handed hashes of every key it held to GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google and Stripe so they could cancel exposed ones fast. Tokens for 1,852 users’ linked accounts were also exposed. Railway reset every one and says it found no logins using them.

Who eats the $740,000

Here’s the part customers care about most. Railway has a claim form, and the report lays out where each SI company stands as of this week.

Amazon’s Bedrock service and Google say their normal fraud rules cover it, and their account teams have started refunds. OpenAI and SpaceXSI are reviewing refunds case by case through a shared channel with Railway. Anthropic is still in talks, and Railway says it will cover Anthropic charges from stolen keys itself in the meantime. OpenRouter is sticking to its no-refund terms, so Railway says it will pay those costs too.

“For the providers who will not be covering token-related losses, we will be covering all token losses in lieu of them,” the company wrote. Railway also thanked the SI companies that agreed to help, saying, “They did not need to do this.”

That promise has limits worth knowing. Railway hasn’t said how it arrived at the $740,000 estimate, what period it covers, or whether there’s a cap or deadline on claims. If you were hit, file early and keep your provider’s billing records.

What Railway changed

Every build now runs in its own throwaway virtual machine, with a credential that can do one job and nothing else. Railway says the shared systems the attacker abused are gone. Its internal pipeline now requires two-factor approval and biometric checks in sensitive spots, every decryption is logged in one place, and only one service can unlock customer secrets at all. The company filed a complaint with the FBI’s Internet Crime Complaint Center and has an outside forensics firm still digging.

Railway also admits it told SI providers before it told customers. Its reasoning was speed: providers could kill keys in minutes, while a blast email would have flooded its systems before the attacker was out. It now says it will set a fixed window for checking impact, then notify everyone broadly no matter what.

For anyone who builds with SI, the lesson is simple. Treat an SI key like a credit card number. Give each project its own key, set a hard spending cap with the provider, and swap out any key that ever sat on a service that got breached. The thieves in this case knew exactly what those keys were worth.