LLMjacking is the theft and abuse of access to large language models (LLMs). An attacker gets hold of a credential that can call an AI service, such as an API key for an AI provider or a cloud identity allowed to use a hosted model, and then uses it for free at the victim’s expense. The victim pays the bill. The attacker gets the compute, or resells the access to someone else.
The name was coined by the Sysdig Threat Research Team, who described the pattern in 2024 after finding attackers using stolen cloud credentials to reach hosted LLM services. It borrows from “cryptojacking”, where attackers hijack someone’s servers to mine cryptocurrency. The idea is the same. The resource being hijacked is different.
This guide explains LLMjacking from the ground up. It covers what an AI API key actually is, why it has become valuable enough to steal and resell, how the abuse works, what it costs, how to notice it, and what to do about it. You do not need any prior background in AI to follow it.
First, the basic terms
A few terms come up repeatedly, so it helps to be clear on them first.
- LLM (large language model). The AI model behind tools like chat assistants and coding assistants. You send it text (a “prompt”) and it sends text back (a “response”).
- Inference. The act of running a prompt through a model to get a response. This is the part that costs money each time it happens.
- AI provider. The company that runs the model and lets you call it over the internet, for example OpenAI, Anthropic, Google, or a cloud platform that hosts models for you.
- API key. A long secret string that proves to the provider who is calling. Whoever holds the key is treated as the account owner. There is no second check. If you can present the key, the provider serves you and bills the account.
- Token. The unit AI providers use to measure and bill usage. Roughly, a token is a small chunk of text. Providers charge per token processed, for both what you send and what comes back.
The one idea to hold onto: an AI API key is a bearer credential tied directly to a billing account. It is not like a password to a website, where a login has to survive extra checks. It works from anywhere, for anyone, until it is revoked or runs out of budget.
How LLMjacking works, step by step
Most LLMjacking incidents follow the same sequence.
- The attacker obtains a credential. This can be an API key found in public code, a key stolen from a platform that stored it, a cloud access key taken from a compromised machine, or a login that has permission to use a hosted AI service. The next section covers where these come from.
- The attacker checks that it works. They make a small, cheap call to test whether the key is valid and which models it can reach. Automated tools do this at scale. This is quiet. A single test call is hard to tell apart from normal use.
- They map what the key can do. Which models are available? What are the rate limits? Is there a spending cap? Keys with high limits and no cap are the most valuable.
- They put the key to work. There are two main uses. The first is running their own workloads on your account: generating content, running automated tools, or powering their own products. The second is reselling. Many attackers do not use the key themselves. They bundle stolen keys into a service, often through a “reverse proxy” that hides the real keys from the buyer, and sell cheap or free AI access to others.
- They keep going until something stops them. That is usually a spending cap, a provider that detects abuse and disables the key, or a person noticing the bill.
Step 4 is why stolen AI keys have a market. If a key lets someone run expensive models, the key has a resale price, and that price is paid for by whoever owns the account.
Why AI keys are so attractive to attackers
Attackers go where the value is easy to extract. AI credentials tick several boxes at once.
- They convert straight into money or compute. A stolen database password needs further work to monetize. A stolen AI key can be used or sold immediately.
- Demand is high. Capable models are expensive to run, and plenty of people want access without paying. That makes stolen access easy to sell.
- Usage is hard to question. Heavy AI use looks like normal AI use. A flood of requests does not look obviously malicious the way a login from a strange country does.
- Keys are everywhere. As teams adopt AI tools, keys end up in source code, config files, CI/CD pipelines, chat messages, notebooks, and third-party platforms. The more places a secret lives, the more places it can be lifted from. This is secrets sprawl, and AI has accelerated it.
- Controls are often missing by default. Many teams create a key, drop it in, and move on. No spending limit, no restriction to a single model, no alerting on cost.
Where AI keys leak from
Understanding the leak points tells you where to look. LLMjacking is rarely about breaking into the AI provider itself. It is about finding a key someone else left exposed.
- Public and private code. Keys committed to a repository, including old commits, forks, and test files. Automated scanners watch public code for newly published secrets and can pick one up within minutes. See how to stop secrets leaking in Git.
- Third-party platforms that store your keys for you. Hosting platforms, deployment tools, developer consoles and evaluation services often hold AI keys on behalf of many customers. If one of those platforms is breached, the attacker collects keys for every customer in one go. Your own hygiene does not protect you from a vendor’s compromise. See third-party risk management.
- CI/CD and automation. Pipeline variables, build logs, and automation tools often carry provider keys. Logs that echo environment variables leak them.
- Developer machines and AI coding agents. Keys stored in local config files, shell history, or
.envfiles can be taken by malware. AI coding agents that can read files may also read and transmit secrets. See what is a coding agent firewall. - Cloud identities with AI permissions. In cloud-hosted AI (for example, models offered inside a cloud platform), the “key” is often a cloud identity. If an attacker steals a cloud credential that is allowed to invoke models, the same abuse follows. This links LLMjacking directly to credential theft.
- Shadow AI. Teams sign up for AI services without telling security, so keys exist that nobody has inventoried. See what is shadow AI.
What LLMjacking actually costs
The harm is wider than the invoice, though the invoice is where most people notice it first.
Direct cost. Usage is billed per token, so a determined attacker running expensive models at high volume can create a very large bill quickly. Sysdig’s research on early cases estimated that abuse could cost a victim tens of thousands of dollars per day on the most expensive models. Even a modest key with no cap can be drained over a weekend when nobody is looking.
Quota exhaustion. If your own application shares the key, the attacker’s usage can consume your rate limit. Your product slows down or stops. Customers see an outage that has nothing to do with a bug.
Data exposure. If the key’s account keeps conversation history, stored files, or fine-tuned models, an attacker with the key may be able to read them. Prompts often contain sensitive material, such as customer data, internal documents, and source code.
Reputation and compliance. Your account may be used to generate content you would never approve, and the account suspension that follows can interrupt your service. For regulated teams, uncontrolled access to a system that touches sensitive data is itself an audit finding.
A foothold for more. Cloud credentials stolen for LLMjacking often have access beyond AI services. The AI abuse can be the first sign that a broader compromise is under way.
How to notice LLMjacking
Because a stolen key behaves like a legitimate one, detection relies on spotting usage that does not fit. Useful signals include:
- Cost spikes. Daily spend that jumps without a matching launch or traffic change. Cost alerts are often the first and best indicator.
- Unexpected models. Calls to the most expensive models your team never uses.
- Unusual locations or sources. API calls from IP addresses, regions, or cloud providers you do not operate in.
- Odd timing. Heavy usage at hours when nobody works, or a sudden constant high rate.
- New or unfamiliar callers. Calls from an identity, key, or application that has never made them before.
- Enablement events. In cloud platforms, someone turning on access to a new model or service, or changing logging settings, shortly before heavy use.
- Failed and probing calls. A burst of small test calls or permission errors, which is what attackers do while mapping a key.
For cloud-hosted AI, the audit trail of API calls and the provider’s billing and usage reports are the main sources. For direct provider keys, the provider’s usage dashboard and any gateway logs you keep are where the evidence lives.
How to defend against LLMjacking
There is no single fix. The goal is layered: make keys harder to steal, make stolen keys worth less, and make abuse obvious fast.
1. Know what keys exist
You cannot protect keys you do not know about. Build an inventory of every AI provider account and every key: who owns it, where it is stored, what it can do, and whether it has a spending limit. Include keys held by third-party platforms and by individual teams. This is the foundation. Without it, every other step has gaps.
2. Set hard spending limits and cost alerts
This is the single most effective way to cap the damage. Set a hard monthly budget in each provider account if the provider offers one. Add alerts at a fraction of that budget, not only at 100%. In cloud platforms, use cost anomaly detection, such as AWS Cost Anomaly Detection, to flag unusual spend automatically. A stolen key with a $200 ceiling is a nuisance. A stolen key with no ceiling is an incident.
3. Give each key the smallest possible job
Use separate keys per application, environment, and team, so one leak does not expose everything and so you can tell whose key was abused. Where the provider supports it, restrict a key to specific models, specific projects, or specific permissions. Never share one master key across production, testing, and personal experiments.
4. Prefer identities to long-lived keys where models run in your cloud
If you use cloud-hosted models, authenticate with a cloud identity that issues short-lived credentials, not a static key pasted into code. A short-lived credential that expires in hours is worth much less to a thief than a key that works forever. See service principals and secret rotation for how those identities and their credentials work.
5. Keep keys out of code, logs, and agents
Store keys in a secrets manager, not in repositories or config files. Scan code and history for exposed keys and block new ones before they are committed. Stop build logs from printing secrets. Keep AI coding agents from reading or sending secrets. Practical steps are covered in the secret scanning guide.
6. Put a gateway you control in front of the provider
A gateway is a service you run that sits between your applications and the AI provider. Applications call the gateway with their own scoped credentials, and only the gateway holds the real provider key. This gives you one place to enforce rate limits, per-team budgets, and logging, and one place to rotate the real key. See what is LLM gateway security.
7. Rotate and revoke fast
When a key is exposed, or a platform that stored it is breached, assume it is compromised. Revoke it, issue a new one, and check usage back to the earliest time it could have been seen. Deleting it from the place it leaked is not enough, because copies persist. See what is secret rotation.
8. Treat the platforms that hold your keys as vendors
Ask vendors how they encrypt stored keys, who can access them, whether they support per-key scoping, and how quickly they notify customers of a breach. Prefer vendors that do not need to hold your raw keys at all.
What does not work
- Relying on “nobody knows our key.” Automated scanners find exposed keys quickly. Obscurity is not a control.
- Relying on the provider to catch it. Some providers detect abuse and disable keys, but you should not depend on them noticing before you get the bill.
- Deleting the key from the repo and moving on. The key is still in history, forks and caches, and still works until revoked.
- One shared key for everything. It makes every leak a full compromise and makes tracing impossible.
How LLMjacking relates to other topics
LLMjacking is a specific outcome of broader problems. It is credential theft where the target is AI access. It is a symptom of secrets sprawl. AI keys are non-human identities and should be governed like any other. And it is part of the wider area of LLM security and agentic AI security. For a recent real-world example of the pattern, see our write-up of a dozen AI developer platforms breached in a month.
How Cloudanix helps
Cloudanix does not issue or cap your AI provider budgets. Spending limits are set inside each provider account, and you should set them there. What Cloudanix does is reduce how many keys leak, how powerful a leaked cloud credential is, and how long abuse goes unnoticed.
- Find exposed keys early. Code Security scans repositories and history with 2,000+ secret patterns, including AI provider key formats, and supports your own custom patterns. Findings arrive with fix guidance.
- Stop keys leaving developer machines. The Coding Agent Firewall acts as on-host data loss prevention for AI coding agents such as Claude Code, Cursor, Kiro, Copilot and Aider. It blocks secrets and PII before a token leaves the developer’s machine.
- Replace standing keys with short-lived access. Cloud JIT, Agentic JIT and Coding Agent JIT give people, pipelines and AI agents scoped, time-limited credentials instead of long-lived keys, so a stolen credential expires quickly.
- Limit the blast radius of cloud identities. CIEM shows which cloud identities can invoke AI services and which entitlements are unused, so permissions can be reduced. Attack path analysis shows how far a stolen identity could reach.
- Detect abuse in the cloud. Cloud detection and response and cloud UEBA flag identities behaving out of character, such as a credential suddenly invoking models it never touched.
What this does not do: it cannot see keys that live only inside a third-party platform you have not connected, and it does not replace provider-side budgets. Use both.
Frequently asked questions
What is LLMjacking in simple terms?
LLMjacking is when an attacker steals a credential that lets them use an AI service, then uses it for free or resells it, while the victim pays for the usage. It is the AI equivalent of cryptojacking.
Who coined the term LLMjacking?
The Sysdig Threat Research Team introduced the term in 2024 after observing attackers using stolen cloud credentials to access hosted large language models.
How do attackers get AI API keys?
Mostly by finding keys that were exposed rather than by hacking the AI provider. Common sources are code repositories, build logs, developer machines, compromised third-party platforms that stored keys, and stolen cloud credentials with AI permissions.
How much can LLMjacking cost?
It depends on the models and the volume. Because providers bill per token, a key with no spending limit can generate a very large bill quickly. Early research estimated tens of thousands of dollars per day for abuse of the most expensive models. A hard spending cap is the simplest way to limit this.
How is LLMjacking different from prompt injection?
Prompt injection manipulates what an AI model does by feeding it malicious instructions. LLMjacking steals access to the model itself. One attacks the model’s behaviour, the other attacks the account and its billing. See what is prompt injection.
What is the best first step to protect against it?
Inventory your AI keys, then set a hard spending limit and a cost alert on each account. That caps your worst case today, while you work on moving keys out of code and toward short-lived identities.
