What is LLMjacking?
By Identra · Updated
LLMjacking is the unauthorized use of large language model services with stolen cloud or AI API credentials. The attacker runs workloads billed to the victim's account and can use up the capacity the victim's own applications rely on.
How does LLMjacking work?
It starts with a credential. An OpenAI key committed to a public GitHub repo. An Anthropic key in a .env file that got baked into a container image. AWS access keys on a compromised laptop with permission to call Amazon Bedrock. The provider accepts the credential because it is valid.
From there the attacker checks which models the credential can reach, then runs their own jobs or sells access through a proxy. Sysdig's LLMjacking research documents stolen cloud credentials used to probe model access, with evidence consistent with attempted resale. No model flaw is involved. Nobody bypasses a content safeguard.
So prevention is mostly AI API key security. Who can get the key, what it authorizes and how fast you can kill it.
What does LLMjacking look like in a company?
Say a support team's app summarizes tickets through a hosted model. A developer leaves the production key in a debug bundle that ends up publicly readable. Someone finds it and starts generating content that has nothing to do with support.
Those calls never touch the support app. Its rate limits and login don't apply because the attacker talks to the provider directly. The bill climbs. If quotas are shared, the real app starts getting throttled.
Investigators compare provider usage with application activity. Model calls with no matching support job are the lead. One credential per workload makes that comparison easy and lets responders kill the leaked key without breaking every other AI integration.
How is LLMjacking different from other AI attacks?
LLMjacking is theft of model access. Prompt injection hijacks what an AI system does. Both can happen at once, but they leave different evidence and need different fixes.
Data exposure is a separate question. Permission to call a model doesn't automatically include past conversations, company documents or training data. Check what the stolen identity could actually reach before calling it a breach.
LLMjacking
- What the attacker abuses
- Stolen access to model services
- Main concern
- Unauthorized usage, charges and quota exhaustion
Prompt injection
- What the attacker abuses
- Instructions the AI system processes
- Main concern
- Redirected behavior or unauthorized actions
Model extraction
- What the attacker abuses
- Access to model outputs or artifacts
- Main concern
- Copying model behavior or taking model assets
What are the warning signs of LLMjacking?
Usage that doesn't match the workload behind it. A spending jump alone proves little, since a release, an evaluation run or a scheduled job might explain it. Ask the owner.
Check before an incident that you can get credential identifiers, timestamps, models, source addresses and usage from your provider. Application logs can't see calls made directly with a stolen key.
- Requests from networks or regions the workload never uses.
- Models, concurrency or token volume nobody expected.
- Model activity while the real application is idle or switched off.
- Permission failures followed by unexplained successful requests.
- New credentials, permission changes or logging changes close to the suspicious usage.
- Quota exhaustion or throttling with no business workload behind it.
How do you prevent LLMjacking?
Give every AI workload an owner and its own credential. Store keys with secrets management and keep them out of browser code, mobile apps, prompts and logs.
Apply least privilege to model access and admin operations. Where the cloud provider supports it, workload identity federation swaps long-lived keys for temporary credentials. Those still need protecting while they are valid.
Find out which spending settings actually reject requests. A budget alert may only send an email.
- Scan repositories and build artifacts for secrets. Revoke anything exposed, even after deleting the visible copy.
- Keep production and development credentials, permissions and quotas apart.
- Restrict models, resources and source networks where the provider allows it.
- Put phishing-resistant MFA on admin accounts and limit who can create credentials.
- Test revocation. Unauthorized requests should fail while other workloads keep running.
How should teams respond to suspected LLMjacking?
Revoke the key and contain whatever leaked it. If the attacker still controls the laptop or CI runner that held it, the replacement key goes the same way.
Review model usage, newly issued credentials, permission changes and access to stored data. Check how your provider treats existing sessions and temporary credentials. Disabling a parent key may not end all access.
The AI incident response plan should cover contacting the provider about disputed usage, restoring workloads with fresh credentials and confirming the original leak is closed. Record unauthorized usage separately from any confirmed data access.
How Identra thinks about it
Identra helps shut one common source of stolen AI keys. API keys, tokens and other credentials are recognized in browser prompts and pastes and can be masked or blocked by policy before they reach an AI app. Prompts to Claude Code and Codex are checked on the device before they are sent, and security teams can see which AI clients, coding agents and MCP servers are running on endpoints.
Go deeper: AI security, built on identity
Frequently asked questions
Does LLMjacking need a model vulnerability?
No. A valid stolen credential authorizes ordinary model requests. The failure is in credential protection or access control.
Does MFA stop LLMjacking?
It protects the accounts that manage AI access. It does nothing against direct use of a stolen API key when the API accepts the key on its own.
Can an AI gateway prevent LLMjacking?
Only for traffic that passes through it. If the stolen provider key also works directly against the provider, gateway limits don't apply to that route.
Does LLMjacking always expose company data?
No. Unauthorized usage is the defining problem. Data exposure depends on what the compromised identity could reach.
Is deleting a leaked key from the repository enough?
No. Copies live on in history, forks and caches. Revoke the key, check how it was used and fix the leak before issuing a new one.