LLMjacking: stolen AI keys are expensive

Two recent publications describe the same trend from two angles. On November 2, the Google Threat Intelligence Group and Mandiant published a report on LLMjacking, the theft of access to AI models at the victim's expense. On November 10, the hosting platform Railway published its report on an October incident, with unauthorized use of customers' AI keys estimated at about US$740,000. AI API keys have become secrets worth hard cash.

What happened

Google's report. According to the Google Threat Intelligence Group, incidents generated fraudulent charges above US$100,000 in a single day, and cumulative charges reaching US$1 million at some organizations before access was revoked. The key points:

• Initial access. The dominant vector is stolen cloud identity tokens: IAM credentials, service account keys, GitHub personal access tokens and session tokens. Some actors also harvest AI API keys from public GitHub repositories.
• Resale. Google describes "LLM Mixers" that pool and resell stolen access. One of them, Jet Night, offered an unlimited plan for about US$60 a month, and one actor made more than 500,000 calls in under eight hours, passing nearly US$1 million in charges to a victim.
• Stealth. Attackers validate keys with tiny requests, such as max_tokens=1, to stay under alert thresholds.
• The blind spot. In several incidents, AI services were not enabled before the compromise: the attackers turned them on with the stolen keys.

The Railway incident. Railway's report describes an attack chain on October 20 and 21: a partial escape from build isolation, theft of a build credential, reading the history of 353 builds, then a misconfigured OIDC binding that yielded cloud credentials, and finally the decryption of customer variables whose names matched AI provider keys. Railway puts at most 1.85% of workspaces, about 100,000, in the group whose variables may have been decrypted. Linked-account tokens for 1,852 users were reset. Railway states it does not know whether the original attacker also ran the services that later used the stolen keys.

Keys left in code. On November 7, The Hacker News reported an Apiiro study on a local Claude Code settings file that stores approved commands in plain text. According to that article, 1,122 public copies of the file on GitHub contained at least one secret, including database passwords and AWS keys.

Why it matters

An AI key is a credential, not a setting. Many teams store an AI provider key with the application's configuration, not with its secrets. Both publications show that it is stolen, resold and monetized like an administrator password.

The cost arrives before the alert. With covert mining, the bill rises slowly. With LLMjacking, Google talks about spikes within hours. An organization that discovers the incident on its monthly invoice finds out too late.

The risk flows through suppliers. At Railway, the keys were stolen from the host, not from the customers. According to The Hacker News, Railway first said it could not refund spending made with the compromised keys, then committed to cover charges when an AI provider declines to. Refund policies vary from one provider to the next. For a customer, the question of financial liability belongs in the contract, not in the middle of the incident.

Non-human identities keep multiplying. Service accounts, pipeline tokens, coding agent keys: it is the same problem we described in non-human identities, the blind spot and in GitHub Actions workflows that steal secrets.

What we think at Sentrix

1. Cap spending today. Google recommends per-model API quotas and spending caps. Add a budget alert that reaches security, not only finance.
2. Inventory AI keys. Who created them, where they are stored, which model and which environment they open. Google recommends segmenting them by model, by environment and by usage limit.
3. Centralize and rotate secrets. A secrets manager with automatic rotation shortens the life of a leaked key. Add secret scanning to code and Git history, including coding agent folders.
4. Watch for AI service enablement. Any unplanned enablement of an AI service in a cloud account should raise an alert. Our cloud security service covers these logs and rules.
5. Ask your suppliers. How does the host protect your variables, who can decrypt them, who pays if they are stolen? These questions belong in the third-party risk assessment.
6. Govern AI use. AI keys and agents are part of AI governance, as our article on ISO 42001 and the NIST AI RMF describes.

The next step

Open the billing console of every AI and cloud provider you use, and check that a cap and an alert exist. Where there are none, the limit of your exposure is your credit card's. To go through it with us, contact us.