Your stolen API Key Only Has to Work for Ten Minutes

The sentence from Black October that stayed with me had nothing to do with PHP. It came from Railway, the hosting platform, which disclosed on 21 October that an intruder may have read its customers' encrypted environment variables and, for some of them, decrypted the contents. Railway described the incident as part of a series of attacks on platform companies aimed at compromising AI inference providers.

On the same morning, someone hijacked LiteLLM's release pipeline and pushed a build with a credential stealer inside to PyPI. LiteLLM is the gateway library that sits between applications and model providers, which means it holds the keys for all of them. A week earlier, Zeabur had lost 3.2 million environment-variable records and announced it would shut down.

So the attackers were after keys. But why? A leaked key gets revoked as soon as someone notices, so why build an operation around something that lasts a few hours?

Abuse starts in minutes, detection waits for the invoice

The objection assumes the clock starts when the key leaks. In practice, however,  it starts when someone notices, and the gap between those two moments is where the money is made.

Honeypot experiments put the first interval in minutes. Comparitech planted AWS credentials on GitHub and saw more than 1,000 API calls against them within one minute; the whole attack was over in under four. In another experiment the first abuse came after 11 minutes. Both tests used cloud credentials rather than LLM keys, but the scanners don't care which is which. They try whatever they find against every provider they know.

Revocation, on the other hand, waits for detection, and most teams detect a stolen key when the invoice arrives. Sysdig, which coined the term LLMjacking in 2024, calculated that a single hijacked account running a frontier model at full quota could cost its owner more than $46,000 a day (vendor research; the figure scales with model pricing). Revoking a key a few hours after you notice counts as fast in most organisations. At that rate it still costs thousands.

Resale only needs a few hours

The resale market has priced the short life in. A stolen key is worth something for as long as it can be checked, sorted and sold before its owner looks, and that takes far less time than most owners need to look.

The tooling for this is old. In the first documented case, Sysdig found a script that tested stolen credentials against ten AI services. It probed just enough to learn which models each credential could reach and how much quota it had, without running a single real prompt. The attackers also checked whether prompt logging was switched on, and the reverse proxy they used to resell access skips any key where it is.

By this year the business had a supply chain. Pillar Security's honeypots logged 35,000 attack sessions from one campaign between December 2025 and January 2026, which Pillar named Operation Bizarre Bazaar. Scanners find exposed AI endpoints, a validator tests them two to eight hours after they show up in public scan results, and a storefront resells access to more than 30 LLM providers at 40 to 60 per cent below list price (vendor research). Individual keys reportedly sell for as little as $30 (single source). With margins like that, a key that works for two hours has paid for itself many times over.

Stolen inference now runs the attacks

The newer development worries me more. On 12 June, Sysdig caught an attacker using an unauthenticated Ollama server as the reasoning engine of a multi-stage attack pipeline rather than as something to resell. The pipeline did reconnaissance, matched services to known vulnerabilities, wrote proof-of-concept exploits and tried to run them, with the model choosing each next step. During the observation window it only hit private addresses and penetration-testing labs, so the tool was still in development, but its design was complete.

Cairn gives a sense of what a finished version costs to run. A NorForge researcher watched one Chinese-speaking operator hand an intrusion campaign to AI agents running on Cairn, an open-source agent platform, and break into more than 100 company websites for roughly $50 of tokens per success. Nothing in the reporting says those tokens were stolen, and the argument doesn't need them to be. Once intrusion runs as an inference workload, inference becomes the main operating cost, and stolen keys bring that cost to zero.

Stolen keys also shift the consequences. When an attack runs on someone else's access, the provider sees the victim's account doing the work, so the bill and any suspension land with the key's owner.

A key opens more than tokens

The inference budget is the obvious asset, but a provider key also reaches whatever the account stores: uploaded files, fine-tuned models, batch outputs, conversation history. Pillar lists exfiltration from context windows and conversation history among the aims of the campaigns it tracked. Even the usage page shows which models a company runs and how heavily, which says a fair amount about what it is building.

Training data is another motive. Sysdig named extracting LLM training data as a possible reason in its first report, and this month researchers described a breach at OpenCode as credential theft for distillation. Distillation needs a synthetic corpus generated from frontier models, and that means enormous token volumes. Spreading the load over thousands of stolen keys is cheaper than paying for it and harder to spot than a fleet of fake accounts. It's a plausible motive, though nobody has documented it at scale yet.

Two more uses follow from how the accounts work, although I haven't found a case where either was the main motive. Sysdig noted that maxing out a stolen account's quota locks the owner out of the models, so key theft can work as a denial-of-service attack on any product built on that key. And since providers enforce their usage policies per organisation, pushing prohibited content through a victim's key could get that organisation suspended.

Agents raise the stakes. An agent with its own key is a target in its own right, and a stolen agent key can be used to impersonate the agent's actions with whatever permissions the agent holds.

Keys now leak through dependencies and platforms

The familiar story is a developer committing a key to a public repository. That still happens, but this year's incidents mostly came from somewhere else.

One route is the supply chain. LiteLLM was poisoned twice in seven months: in March a criminal group pushed two malicious releases that stayed live for about 40 minutes, and in October the project's own release pipeline shipped the stealer. A gateway library collects credentials by design, so one bad install hands over every provider key an organisation uses. Developer tooling is another route. At least 15 JetBrains Marketplace plugins did what they promised while quietly sending the AI keys users entered to an attacker.

Hosting platforms are the third. Railway and Zeabur kept customer secrets for convenience and lost them in bulk; Zeabur's attacker got in through a non-expiring admin token stored in plaintext. Running your own models doesn't get you out of this either. Around 175,000 Ollama instances answer on the open internet without authentication, and a vulnerability disclosed in May lets an unauthenticated attacker read API keys and conversation data out of an unpatched server's memory with three API calls.

Watch each key against its own history

If abuse starts minutes after a leak, prevention will sometimes fail, and what matters is how quickly you notice your key working for someone else. The providers already publish the data. Anthropic's Admin API returns token usage grouped by API key and model in hourly buckets, and OpenAI's organisation usage API breaks usage down per key, project and model. Most teams don't look at those numbers until the invoice makes them.

The warning signs are concrete. A key that has run at a steady rate for months suddenly triples. A key that has only ever called a small model starts calling the most expensive one, or a key behind an internal tool that people use during office hours sends traffic at three in the morning. One detail from Sysdig's first report works as advice too: the reverse proxy it found refuses AWS keys that have Bedrock prompt logging enabled. Turning logging on gives you forensics and makes the key less attractive to steal.

What I would put in place this week:

1. One key per application and environment, so every baseline belongs to exactly one workload.
2. A hard spending cap and rate limit on each key or project, set just above legitimate peak.
3. Key monitoring: volume against baseline, first-time models, traffic outside the usual hours.
4. Prompt logging switched on wherever the provider offers it.
5. A gateway that holds the real provider key, so applications carry short-lived tokens instead.
6. Canary keys in repositories, CI configuration and container images, where any call is an incident.
7. A rehearsed, timed rotation, so you know how long revocation takes before you need it.
8. Pinned versions for every dependency that touches keys, and an audit of IDE plugins.

Inference has no ceiling unless you build one

I expect this to get harder. A year ago an LLM key was mostly a billing credential. More and more it is the identity of an agent that decides, calls tools and acts on systems with whatever permissions it was given. Whoever steals that key gets the tokens plus a working colleague who now takes instructions from them.

A stolen database password is limited by what's in the database. A stolen inference key is limited only by its quota and whatever spending cap its owner set, and in most accounts nobody has set one. Attackers already run pipelines that turn ten minutes of access into profit, while most of us still find out from the invoice.