Stolen AI keys at Railway: $740,000 in usage charges

What happened at Railway and why it matters to your SMB

Railway, a platform that lets its customers build and run applications, has acknowledged that during an incident in October, AI provider keys that its customers had stored in the service were stolen. Those keys were later used to generate unauthorized usage that the company estimates at $740,000. The platform has announced that it will absorb those charges when the AI provider does not reimburse them.

The detail is not minor: Railway does not only host applications, it also stores its customers' secrets, such as API keys and database credentials. In other words, the incident does not affect an isolated system, but rather the layer where many companies place their trust that their credentials are safe.

The new loot: AI keys, not just passwords

For years, attackers have sought email credentials, access to admin panels, or cloud service tokens. The rise of generative AI has added a new target: the API keys of model providers. A leaked key does not allow reading emails or deleting databases, but it does allow running queries and generating costs billed in the victim's name. In some cases, the damage is purely economic; in others, it can also expose data if the key grants access to models with sensitive information.

The Railway case fits a trend we have already seen on the blog: the security of AI agents and services has become a front of its own. We discussed it when analyzing CrowdStrike's acquisition of Fiddler and Dreadnode (security for AI agents) and also when talking about how pentesting AI can turn against the cloud in the AntiFox case (AntiFox). The lesson is the same: if a credential grants access to a resource that costs money per use, it must be treated as a critical asset.

What it means for an SMB or an IT team

For an SMB starting to integrate AI into its processes, this incident should serve as a warning. You do not need to be a large tech company to have API keys from OpenAI, Anthropic, Azure OpenAI, or any other provider stored in a repository, in an environment variable of a PaaS, or on a developer's laptop. The problem appears when those keys are shared without control, uploaded to a public repository by mistake, or stored in a third-party service without reviewing how it protects them.

The economic impact can be immediate. Uncontrolled consumption of an AI API translates into a bill that, in Railway's case, approaches $740,000. For an SMB, such a figure can be lethal. And even though the platform has promised to absorb the cost when the provider does not reimburse it, that will not always happen: each provider's response depends on its terms and on how the key was managed.

Practical recommendations for day-to-day operations

1. AI key inventory. First of all, know which keys exist, who uses them, where they are stored, and what permissions they have. If there is no inventory, there is no control.
2. Principle of least privilege. Each key should be able to do only what it needs. If an integration only queries a model, it should not have admin permissions or access to other services.
3. Spending limits and alerts. Configure usage thresholds and alerts at the AI provider. An anomalous spike should trigger a review, not a surprise at the end of the month.
4. Fast rotation and revocation. Have a clear procedure to revoke a key in minutes, not days. If you do not know how to do it, the incident drags on.
5. Do not store secrets in code. Use secret managers or the service's own environment variables, and check that repositories do not expose keys.
6. Review your providers. If you delegate the storage of secrets to a third party, it is worth knowing how it protects them, what encryption it uses, and what guarantees it offers in the event of an incident.

ForgeNEX's analysis

The Railway case leaves one clear idea: the security of AI credentials is no longer an exclusive concern of large companies. Any SMB that uses an AI API is exposed to a stolen key generating uncontrolled usage. The difference between a scare and a crisis lies in preparation: inventory, tight permissions, spending limits, and the ability to revoke quickly.

It is also worth looking beyond cost. A compromised AI key can allow queries that expose internal data or that are used for unintended purposes. That is why the recommendation is to treat these keys as you would an administrator password: with care, with control, and with a plan for when something goes wrong.

At ForgeNEX we work with SMBs that need to integrate AI without losing sight of security. If your team stores API keys in third-party services or repositories, now is a good time to review how they are protected and what would happen if one of them fell into the wrong hands.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.