Stolen AI keys: Railway reports $740,000 in unauthorized usage

An AI API key can look like an unremarkable line in a configuration file. Until someone else finds it. Then it can become a way to consume paid models, run intensive workloads and generate a bill nobody approved.

That is the risk at the heart of a detailed incident report published by cloud development platform Railway on 10 November. The company investigated an intrusion that took place on 20–21 October 2026 and estimates that compromised AI credentials led to roughly $740,000 in unauthorized usage.

For a small company building AI-powered services, this is not just a story about a sophisticated cloud provider. It is a reminder that a leaked key can create a financial problem even when the company's own website appears to be working normally.

The secret behind a working app

Railway helps developers build and host applications. Those applications often rely on API keys: secret credentials that let code access AI models, databases, payment services or other external systems.

Developers normally keep such secrets in *environment variables* rather than writing them directly into a public code repository. That is generally the right approach. It does not, however, remove the need to protect whichever system stores and delivers those variables.

If somebody obtains a valid AI provider key, they may be able to submit requests as the legitimate customer. They do not necessarily need the account holder's personal password to start spending the account's usage allowance.

That makes a set of application secrets more than a technical asset. It can also function as a collection of spending permissions.

How the Railway attack unfolded

According to Railway's forensic report, the first successful entry point was its shared application-build infrastructure. The attacker partially escaped the isolation surrounding a build job and obtained an internal credential.

That credential was trusted by another internal system more broadly than intended. The attacker used it to access some build histories and a copy of Railway's own codebase. After examining that code, they identified a misconfigured cloud trust relationship that opened another route into internal systems.

The attacker ultimately reached infrastructure involved in storing and decrypting customer environment variables. Railway says database logs show searches for variable names associated with AI provider credentials.

The distinction between exposure and confirmed theft matters here. Railway estimates that at most 1.85% of its workspaces, approximately 100,000, could have had some variables decrypted. This is an upper bound on potentially affected workspaces, not a confirmed count of customers whose every key was stolen.

The company also reset linked-account tokens for 1,852 users. It says it found no evidence of attackers using those credentials to log in to individual Railway accounts.

AI access has become something attackers can sell

Traditionally, stolen business credentials often lead people to think about email compromise or data theft. AI credentials introduce another immediate incentive: access to expensive computing services.

Many model providers charge according to the amount of text, images or other processing consumed. A valid key may permit automated requests around the clock until it is revoked, rate-limited or otherwise blocked.

Security company Wiz has documented a wider run of incidents involving AI developer platforms. Its research describes what is often called *LLMjacking*: stealing access to AI services and using or reselling that capacity through intermediary services.

Railway's investigators believe its attacker specifically sought AI keys, possibly to supply services that relay or resell access to models. The company has not established who ran those services, or that every subsequent use came from the original intruder.

The financial impact is more tangible. Railway estimates around $740,000 in unauthorized AI usage linked to the compromised keys. It says it is coordinating with providers on refunds and will cover affected costs itself when an upstream provider will not. That is a commitment associated with this incident, not a universal refund policy for stolen API keys.

What this means for a smaller business

Consider a small software agency that builds an AI assistant to summarize customer documents. The app runs with a single provider key, and the agency pays for all model requests made through that key.

If the secret is copied, an attacker might send model requests directly to the AI provider. The customer's app could look completely normal while usage charges climb elsewhere.

That example is hypothetical. The underlying mechanism is not: possession of an API key may be enough to authorize billable usage.

The concern becomes even sharper with AI agents. Agents can initiate chains of model calls and tool actions without a person approving each individual step. Legitimate automation can therefore resemble high-volume misuse unless teams have separate monitoring, budgets and logs.

This is why managing AI credentials should not be a narrow developer-only task. Whoever owns the budget needs visibility into which providers are in use, what abnormal spending looks like and how access can be stopped promptly.

Five protections worth putting in place

1. Use separate keys for separate purposes. Keep production, testing and client projects isolated where the provider supports it. That reduces the reach of one compromised key.
2. Set permissions, limits and alerts. Apply scoped credentials, quotas, hard spending caps where available and alerts for unexpected spikes. An alert does not itself stop spending.
3. Audit where secrets are stored. Review hosting settings, CI/CD pipelines, deployment logs, agent frameworks, third-party integrations and source repositories.
4. Monitor usage at the provider. Compare billing and request logs from the AI provider with the activity your own application reports. The two should broadly agree.
5. Practice key rotation. Know who can revoke a credential, which services must be updated afterwards and how to retain relevant evidence if abuse is suspected.

If your company uses Railway and stored secrets there before the October incident, follow Railway's published response instructions and check for suspicious charges. That is a product-specific action; it should not be read as evidence that unrelated hosting providers were affected.

The bigger lesson

Railway says it closed the routes used in the intrusion and strengthened isolation between builds, including dedicated temporary virtual machines instead of relying on shared build infrastructure. An external forensic investigation was still ongoing when the detailed report was published.

The most striking part of this story is the link between a complex cloud intrusion and an ordinary business outcome: a bill. A company does not need to understand every cloud exploit to ask a useful question about its own exposure.

If one of your AI keys were stolen tomorrow, how much could somebody spend before your team noticed?

Sources: Railway-rapport · Railway-melding · Wiz · BleepingComputer · The Hacker News