What is LLMJacking?

Imagine waking up to a $10,000 cloud bill.

It isn't a ransomware attack. There is no ransom note and no encrypted files. Instead, you find a massive, inexplicable spike in your generative AI usage charges. This is LLMJacking. It is the silent theft of compute resources, and it is happening right now.

While most people are worried about their proprietary data being used to train the next model, the real immediate threat is much more primitive and far more expensive: someone is using your enterprise compute budget to run their own business.

Mandiant/Google recently reported that these attacks are hitting organizations across North America and Asia. In some cases, the cumulative damage reached $1 million before anyone even noticed the credentials had been compromised.

The Stealthy Probe

Most security teams are trained to look for volume. We watch for spikes in egress traffic or sudden bursts of failed login attempts. LLMJacking is designed to avoid those triggers entirely.

The attack begins with a reconnaissance phase that looks like nothing more than routine API calls. Attackers don't start by blasting millions of tokens at a model. Instead, they use what is called "Micro-Probing." They make single-token requests using the max_tokens=1 parameter.

This is a brilliant bit of minimalism. A request for one token is virtually indistinguishable from a legitimate application heartbeat or a simple connectivity test. It validates that the API key works and identifies which models are available without triggering any rate limits or anomaly detection systems.

Once they know the key is live, they move to financial scouting. They call APIs like GetCostAndUsage to see how much headroom they have in your budget. They aren't just looking for a way in; they are looking for the richest targets with the highest quotas and the most lenient billing oversight.

The Burn and Rotate Strategy

Once an attacker identifies a high-value target, they don't just sit on one credential. That is too risky. Instead, they employ a "Burn and Rotate" strategy.

They use their initial access to create additional service accounts or generate new API keys within your cloud project. They then launch high-volume inference streams through these secondary identities. If a specific key starts hitting rate limits or triggers a minor alert, they simply drop it and rotate to the next one.

This creates a distributed attack pattern that looks like legitimate, albeit highly variable, scaling of an AI service. To your monitoring tools, it doesn't look like a breach. It looks like your engineering team just launched a very successful new feature that requires massive compute power.

The Mixer Economy

The most infuriating part of this is the secondary market. If you go on Reddit or Telegram, you will find people selling "unlimited" access to the world's best models for sixty dollars a month.

This isn't some miracle of efficiency. It is a liquidation of stolen enterprise assets.

These sellers use "Inference Mixers" (and I am purposely not going to name/link to them). These are proxy services, often operating through specialized API gateways or custom-built middleman platforms, that pool thousands of stolen API keys from various enterprises into a single endpoint. When you buy access from them, your requests are routed through this mixer. The service uses the stolen keys to fulfill your request, effectively laundering the compute usage through a layer of anonymity.

This makes attribution nearly impossible. Unlike a stolen credit card, which leaves a trail of transaction IDs and merchant records, an LLM request is just a string of text sent to an endpoint. When that request is proxied through a mixer, the link between the end user and the victimized enterprise is severed. The attacker gets paid in crypto, the consumer gets cheap AI, and the enterprise gets a massive bill they cannot easily contest.

Because LLM APIs are sessionless, each API call is independent of prior calls. That makes stolen accounts easy to use: there is no setup or prior account state.

Protecting the Inference Surface

Our current approach to identity management is fundamentally broken for the generative AI era. We spend all our time worrying about who can log into our systems, but we are ignoring how those identities are being used once they are inside.

You cannot solve LLMJacking with better password policies or simple key rotation. If a key is leaked via a GitHub repository, which happens constantly, rotation only matters if you catch the leak before the first probe occurs.

You need to move toward inference-aware security.

1. Implement strict IAM roles that follow the principle of least privilege for your AI services. A service account used for a simple chatbot should not have the permissions required to call GetCostAndUsage or create new API keys.

2. Monitor for the reconnaissance patterns themselves. Watch for unusual calls to model availability endpoints and set aggressive, real-time alerts on token consumption spikes at the individual service account level.

3. Set hard spending limits on your foundation models. If a project suddenly attempts to spend five thousand dollars in an hour, the system should automatically kill that identity's access.

The era of "set and forget" API keys is over. If you treat your LLM credentials like traditional passwords, you are leaving the door wide open for someone else to pay your bills.

PS AI Disclosure statement, Google's Gemini assisted in recreating Alan being hijacked in Captain Philips (2023).