Your company's API keys after Railway and LiteLLM: inventory, rotation, limits

Two incidents on 21 October targeted companies' API keys. What to do now (inventory, rotation without downtime) and what to change so a leak stops being costly.

Two incidents on 21 October 2026 carry the same lesson. Railway, a hosting platform used by many developers, announced that an attacker may have accessed customers' environment variables, and for some of them the decrypted contents. On the same day, version 1.107.0 of LiteLLM, a popular library for connecting applications to AI models, was published in a compromised form, carrying a program that stole credentials. In both cases the target was keys: the API keys for AI services, payments, databases and the cloud.

This article is for managers of companies that use AI services, Stripe or the cloud, and for the technical team beside them. You do not need to write code to ask the right questions.

An API key is a long password that an application uses to talk to another service, for example an AI model, the payment processor or the database. Unlike a person's password, it does not ask for confirmation on a phone and it never gets tired. Whoever holds the key can do, in your company's name, everything the key allows: send paid requests, read data or issue refunds.

That is why a leaked key is not tomorrow's problem. AI services are billed by usage, and a stolen key can be used automatically, without pause, until someone revokes it or a spending limit stops it. Railway said explicitly that the attack is part of a series targeting hosting platforms in order to reach AI inference providers, in other words their keys.

Railway detected the anomalous activity on the morning of 21 October, in the systems that store environment variables. Its advice to every customer was to change all environment variables immediately, including API keys, to change private image registry credentials and to review the logs of the services concerned. Railway also asked AI providers to revoke the exposed keys proactively and paused all deployments during the investigation.

LiteLLM 1.107.0 was available on PyPI, the Python package repository, for about two hours, according to Datadog's analysis. The official Docker images were affected too, including the latest tag. The malicious program started on any Python launch in that environment, even when LiteLLM was not used, and looked for cloud credentials, SSH keys, developer tokens, AI provider keys and passwords saved in browsers. Removing the package was not enough: the files it added stayed on disk.

You cannot protect what you do not know you have. Ask your team or supplier for a simple list: which keys exist, for which service, in which application and on which server they are used, who created them and when. The usual places are environment variables on hosting platforms, configuration files, CI/CD systems and, unfortunately, sometimes the code itself or chat messages.

If your application ran on Railway or installed LiteLLM 1.107.0, assume the keys it could reach are compromised. Rotation takes three steps, so that the service keeps running:

1. create a new key with the provider;
2. put the new key into the application and deploy;
3. revoke the old key only once you have confirmed the application works with the new one.

OpenAI recommends exactly this order in its best-practice guide: the replacement first, revocation last. For LiteLLM, Datadog advises doing the rotation from a clean machine, not from the one that may be infected.

Look in the providers' consoles at usage over the last few days: requests at unusual hours, models you do not use, sudden spikes. Check the database and cloud logs too for access from places you do not expect. If you find anything, keep the evidence before deleting anything.

Keys are better kept in one controlled place, a secrets manager, than copied across dozens of files and platforms. The OWASP guide on secrets management recommends centralisation, restricted access, logging every read and regular rotation. The practical benefit: when a key has to change, you know where it is and who uses it.

A single key used everywhere means a leak anywhere compromises everything. Separate keys by environment (testing, production) and by application. OpenAI suggests separate projects for testing and production, each with its own limits. When a key leaks, you know exactly what it affects and can revoke it without stopping everything else.

The major AI providers support cost limits. In the Anthropic console you can set your own monthly limit below the account's cap, and requests stop once it is reached. OpenAI offers spending alerts and hard limits that stop traffic at the threshold you choose. Set them on every project: a limit that stops a service is annoying, an uncapped bill after a leak is far worse.

A key should be able to do only what the application needs. A read key should not be able to write, and a payments key should not be able to issue refunds if the application never does. Stripe, the cloud providers and many AI services let you create restricted keys.

The LiteLLM case shows why "the latest version" is not a strategy for production. Applications that installed the newest version automatically, or used the latest tag of the Docker image, received the compromised code without anyone deciding so. What helps:

• versions pinned in dependency files and container images;
• updates made deliberately, after a short waiting and checking period;
• tools that scan packages at build time and flag withdrawn or suspicious versions;
• build servers that have no access to production keys.

1. List your keys: where they are, what they unlock, who uses them.
2. If you were on Railway or installed LiteLLM 1.107.0, rotate everything: new key, deploy, then revoke the old one.
3. Check usage and logs from the last few days.
4. Move keys into a secrets manager, one per application and per environment.
5. Set spending limits and alerts with every provider.
6. Pin dependency versions and do not use latest in production.

At ME Digital we work with AI integrations and API keys every day: we keep them in one place, separate them by application and environment, set cost limits and configure integrations so that data is not used for training. If you would like to go through the inventory and rotation together, see AI implementation and security and updates, or get in touch.

• Railway, security disclosure of 21 October 2026
• Datadog Security Labs, LiteLLM compromised on PyPI and Docker
• Wiz, LiteLLM compromised, steals credentials
• OWASP, Secrets Management Cheat Sheet
• OpenAI, Production best practices
• Anthropic, Rate limits and spend limits