LLMjacking is when attackers use stolen cloud or AI API credentials to run AI models at the victim's expense, often reselling the access to others. The victim gets the bill.

What is the earliest warning sign of a stolen AI key?

Tiny test requests. Attackers check that a stolen key works by asking the model for one token, which stays under most volume alerts. Alert on repeated requests that ask for one or two tokens.

How do I limit the damage if an AI key is stolen?

Give every key an expiry date, a list of the models it may use and a daily spending or token limit, keep the real provider keys on a server instead of on laptops and in code, and get an alert when a key nears its limit.

LLMjacking: how stolen AI keys run up huge bills, and how to stop it

Q: How do attackers find AI API keys?

Mostly from keys committed to public code repositories, stolen cloud credentials and service account keys, phished session tokens, and AI model servers left open to the internet.

Keystile · November 4, 2026 · 6 minute read

For years, the reason to steal a cloud login was to mine cryptocurrency on someone else's servers. That is changing. Attackers now steal AI access instead. They run models on the victim's account, or resell the access to other people at a discount, and the victim pays.

Google's threat intelligence team (Mandiant) has published a detailed report on this, which it calls LLMjacking, based on incidents it handled in 2026 at financial services, retail, technology and transport companies: The Rise of LLMJacking. It is worth reading in full. Here is what it means for a team using AI.

How big the bills get

Cryptomining drains an account slowly. LLMjacking does not. In the incidents Google describes, single days passed $100,000 in fraudulent charges, and some companies reached about $1 million before the access was shut off. One reseller made over half a million model requests in under eight hours on one victim's account. In several cases the victim had never switched AI services on at all: the attackers did it themselves with the stolen login.

How attackers get in

Keys left in code. AI API keys committed to public repositories are collected automatically.
Stolen cloud credentials. Service account keys, access keys, developer tokens and federation tokens, which also let attackers make fresh keys and skip multi-factor sign-in.
Phished sessions. A fake portal asks people to paste a block of text that contains a live session token.
AI servers open to the internet. Model servers set up for testing and never locked down.

Once inside, attackers look for more secrets in code, logs and secret stores, create their own admin users and keys so they can come back, and try to switch off the logs that would show what the models were asked.

The warning signs

Tiny test requests. Before using or selling a stolen key, attackers check that it works with a request for a single token. That stays under most volume alerts. Several of these in a day is a strong signal.
AI services switched on in an account or project that never used them, or new models enabled.
New access keys, users or service accounts nobody on the team made, especially short-lived ones created and deleted again.
Model logging changed or turned off.
A sudden jump in usage or cost, at hours when your team is not working.

A checklist to stop it

Keep real model keys off laptops and out of code. Agents and developers should hold a key to a gateway you control, not the provider's key.
Give every key an expiry date. A key that stops working in 90 days is worth far less to a thief.
Limit each key to the models it needs, so a stolen key for a small model cannot call the most expensive one.
Set a daily token or spending limit on every key, so a stolen key cannot run up more than a day's budget.
Alert on test requests and on keys nearing their limit, with a one-click way to revoke.
Scan your code for secrets before it is pushed, and rotate anything that leaks.
Use phishing-resistant multi-factor sign-in for cloud consoles and developer tools.
Treat "AI service switched on" as a security event in every cloud account, and keep model logging on.

Where Keystile fits

Keystile is built for teams whose AI agents work in real systems. Agents connect to their model through Keystile with a Keystile key. The model's own key stays on the Keystile server, so there is nothing valuable on a developer's laptop or in a repository to steal.

Checklist item	In Keystile
Model keys off laptops and out of code	Agents hold only a Keystile key
Expiry on every key	New keys work for 90 days by default (30 days, a year, or until revoked if you choose)
Each key limited to its models	Pick the models a key may use
Daily limit on every key	A daily model-token limit; the key stops until the next day when it is reached
Alerts with one-click revoke	An alert when a key is tested with tiny requests, passes 80% of its limit, or reaches it

Keys are stored only as fingerprints, so a copy of Keystile's database cannot be used to call anything. App connections such as GitHub, Google and Slack are held by Keystile too, so agents never see those tokens. And every action an agent tries to take is checked before it runs. Sending data out, changing access or paying can be stopped or held for a person.

Start free

Questions

What is LLMjacking?
Using stolen cloud or AI API credentials to run AI models at someone else's expense, often reselling the access. The victim gets the bill.

How do attackers find AI API keys?
Mostly from public code repositories, stolen cloud credentials, phished session tokens, and model servers left open to the internet.

What is the earliest warning sign?
Tiny test requests that ask the model for one or two tokens. Alert when a key makes several in a day.

How do I limit the damage if a key is stolen?
Expiry dates, a list of allowed models and a daily limit on every key, real provider keys kept on a server, and an alert when a key nears its limit.

Source: Google Threat Intelligence Group, The Rise of LLMJacking. Figures in this article are from that report.