What Is LLMjacking? How Attackers Hijack AI API Keys and How to Stop It in 2026

You check your AI provider dashboard and the number makes no sense. Last month you paid a few hundred dollars. This month the meter shows tens of thousands, and nobody on your team launched anything new. Someone else is using your account, and you are paying for every token they burn.

That is LLMjacking. Attackers grab access to a large language model that belongs to you, then run their own workloads on it. Some resell the access. Some use it to generate content that providers would block on their own accounts. All of them leave you holding the bill.

This guide explains how the attack works, where keys usually leak, how to spot abuse early, and what to do when it happens.

What Is LLMjacking and How Does It Work?

LLMjacking means using someone else's AI compute without permission. Security researchers at Sysdig gave the attack its name after they caught a group using stolen cloud credentials to call hosted models from Anthropic, OpenAI, AWS Bedrock and others.

Attackers reach your models in two ways:

• They steal a credential. An API key for OpenAI, Anthropic, Gemini or Mistral, or a cloud role that can call a managed service like Bedrock, Vertex AI or Azure OpenAI.
• They find an open door. A self-hosted inference server, an AI gateway or an MCP server that answers requests from the internet without asking for any login at all.

Either route hands the attacker free compute and a borrowed identity. When the provider notices abuse, it flags your account, not theirs.

LLMjacking vs Prompt Injection vs Cryptojacking

People often lump LLMjacking together with other AI threats. They work very differently:

LLMjacking sits closer to cryptojacking than to prompt injection. It is resource theft. The difference is stealth. Cryptojacking spikes your CPU and gets noticed. LLMjacking looks like normal API traffic, so it hides much longer.

Why Are Stolen AI API Keys So Valuable to Attackers?

A stolen database password forces an attacker to extract data, store it and find a buyer. A stolen AI key skips all of that. The compute itself is the product.

Several things make these keys especially attractive:

1. Instant cash value. A working key can be sold, plugged into a paid service, or used to churn out content at volume on day one.
2. A clean reputation. Providers ban accounts that break their usage rules. A banned attacker simply keeps working through your account until you catch on.
3. Lots of copies in lots of places. One company might hold keys for three providers spread across developers, CI jobs, gateways and agents. Every copy is a chance to leak.
4. Data nearby. If the attacker reaches a gateway or agent instead of a bare key, they may also see prompts, tool outputs and logs.

The money gap is huge. Researchers have seen stolen keys sell for as little as $30, while a single hijacked account can rack up costs above $46,000 in one day. Bills on newer, pricier models can climb even higher.

Real LLMjacking Cases and What They Cost

Microsoft took a group it calls Storm-2139 to court after finding it using stolen Azure OpenAI keys. The group built a tool that sent requests looking like normal API calls but let users change settings the service normally locks down, including content safety filters. It ran a reverse proxy to hide where traffic came from and sold access in different price tiers. Microsoft seized the proxy domain and named four people tied to the operation.

Smaller victims tell the same story at a different scale. One startup that normally paid about $400 a month to OpenAI received a $67,000 invoice after its key sat in a public GitHub repo for 11 days. Another saw a $180 monthly bill jump to $82,000 in two days.

What Damage Can LLMjacking Cause Beyond a Big Bill?

The invoice is only the part you see first. Once an attacker controls your model access, several other problems follow.

• Abuse under your name. Attackers use stolen access to draft phishing emails, tune malware and write social engineering scripts. The provider sees that activity on your account, so your account takes the flag or the ban.
• Data exposure. If the attacker reaches a gateway, an agent or a custom model trained on internal documents, they can read prompts, logs and company knowledge that was never meant to leave the building.
• Broken workflows. Automated pipelines and agents that depend on the model keep running on the attacker's traffic, which inflates costs further. A hard spend cap that trips can also knock your own product offline.
• Model tampering. Researchers warn that attackers with access to training data or fine-tuning pipelines could slowly bend a model's answers. Nobody has publicly confirmed this in the wild, but it remains a real risk for teams that keep refining models on company data.
• Legal duties. If customer data passed through the hijacked model, you may owe regulators and customers a breach notice under privacy laws like GDPR or CCPA.

Where Do AI API Keys Leak From?

Most leaks come from ordinary developer habits. AI projects add a few new spots on top of the classic ones.

Frontend Code and Mobile Apps

The quickest way to ship a chatbot is calling the model straight from the browser or app. That drops your key into JavaScript anyone can read or into an app binary anyone can unpack. Some build tools make this worse by inlining any environment variable with a public prefix into the client bundle.

Fix: route every call through your own backend. If a client truly must talk to the model, use a provider feature built for that, such as short-lived tokens issued only to verified app installs.

.env Files and Git History

A .env file is handy and risky. It slips into commits when .gitignore is wrong, into Docker build contexts, into support tickets and chat messages. Bots watch public commits around the clock, and a leaked key can get abused within minutes.

Deleting the commit does not save you. The key still lives in Git history and in every clone. Revoke it.

Docker Image Layers

Passing a key through ARG or ENV in a Dockerfile writes it into the image layers. Anyone who runs docker history on that image can pull it back out. Use BuildKit secret mounts instead:

RUN --mount=type=secret,id=openai_key \
    OPENAI_API_KEY=$(cat /run/secrets/openai_key) python setup.py

CI Logs

A debug flag, a failing test that dumps the environment, or a script that echoes a request can print your key straight into build logs. Those logs often stick around for months and anyone with repo access can read them. Builds from forked pull requests can expose secrets too.

Gateway and Observability Logs

Teams love logging full requests and responses to debug prompts and track cost. If those payloads carry auth headers or tokens, your log store has quietly become a key store. A compromised build of the popular LiteLLM gateway showed exactly this: tokens captured in request logs were harvested and used to tamper with the release pipeline.

MCP and Agent Config Files

Coding agents and MCP servers need credentials, and many setups park them in plain JSON files in your home or project folder. Those files get synced to dotfile repos, pasted into onboarding docs, and read by any process running as you. Infostealer malware now hunts for them specifically.

Hosting Platform Environment Variables

Platforms that inject environment variables at build and run time hold a copy of every secret you give them. If the platform gets breached, so do your keys. One hosting provider recently told customers to rotate every stored secret after an intruder may have reached decrypted environment values.

Notebooks, Demos and Sandboxes

Keys pasted into a notebook cell for a quick test, hackathon repos and evaluation sandboxes leak all the time. The project dies in a week. The key often lives forever.

How Do Attackers Find Exposed Keys and AI Servers?

Attackers do not guess. They run automated hunts at internet scale.

Scanning for leaked strings. Most providers use recognizable key prefixes, such as sk-ant-api for Anthropic or sk- for OpenAI. Bots crawl GitHub, npm, PyPI, Docker Hub, paste sites and public build logs for these patterns, then test every hit within moments.

Fingerprinting exposed services. Ollama, LM Studio, OpenAI-compatible endpoints, gateway admin panels and remote MCP servers answer on predictable paths. Scanners probe paths like /api/tags, /v1/models and /.well-known/mcp.json to see which models and tools sit behind a server.

Quiet probing before the heist. With cloud credentials, attackers often check what they can reach before spending anything. On Bedrock, they may list available models or send a deliberately broken request. A validation error tells them the key works. An access denied error tells them it does not. They also check whether model invocation logging is turned on.

Autonomous agents. Security researchers recently caught an AI-driven attack agent in a honeypot built to look like an unprotected AI service. It carried dozens of tools for reconnaissance, exploitation and credential theft, and could run huge numbers of actions with no human in the loop. Nothing it did was new. Bundling it all into one self-driving agent just made it cheaper to run.

A separate honeypot experiment showed how fast this happens. A Raspberry Pi posing as a private AI server got indexed by Shodan within three hours. Recon requests started an hour after that. Over a month it logged more than 113,000 requests, and almost a quarter targeted AI services directly. Visitors tried to use it for document parsing, erotic fiction, vulnerability research and as a proxy for Anthropic models. Others kept hunting for .env files in every folder.

The lesson is simple. If an AI endpoint you run answers the internet without strong authentication, assume someone will find it this week.

What Are the Warning Signs of LLMjacking?

Most victims learn about LLMjacking from the invoice. You can catch it far earlier if you watch usage per key, per model and per hour.

Watch for:

• A sudden jump in tokens or spend on one key with no matching release, campaign or traffic change.
• Unfamiliar models. Attackers love the biggest, newest model your key can reach, often one your product never calls, or a different mode like image generation.
• A flat 24/7 pattern. Real users follow a daily rhythm. Resold access often runs nonstop.
• Strange sources. Calls from unusual countries, Tor exit nodes, residential proxies or unknown cloud regions.
• Rate limit errors you did not cause. Your traffic is now fighting the attacker's traffic.
• Dead keys waking up. Keys from old demos, ended projects or former staff are prime targets.
• Probing errors. A burst of validation or access denied errors from one identity usually means someone is mapping your permissions.
• Logging changes. Any attempt to read or switch off model invocation logging deserves an alert.
• Provider warning emails. Send these to a shared inbox someone actually reads.

Most providers give you the data to watch these signals. Anthropic's Usage and Cost API breaks usage down by key and model in short time buckets. On AWS, Bedrock model invocation logging records each call's model, token count and caller identity, but it ships switched off, so turn it on today. OpenAI's production best practices cover usage dashboards and spend notifications.

How Do You Prevent LLMjacking? 7 Fixes That Work

No single setting fixes this. Stack several layers so a leak becomes a small problem instead of a crisis.

1. Build a Key Inventory

You cannot protect keys you do not know exist. Make a list with one row per key: provider, project or workspace, owner, where it runs, what it can access, expiry date and last use.

Pull the list from each provider first. Anthropic's Admin API, OpenAI's organization Admin API, AWS IAM and Google Cloud all let admins list keys programmatically. Flag anything with no expiry, no owner or org-wide scope.

Then search your own code and config for the standard variable names that SDKs read automatically:

git grep -nE 'ANTHROPIC_API_KEY|OPENAI_API_KEY|GEMINI_API_KEY|GOOGLE_API_KEY|AWS_BEARER_TOKEN_BEDROCK'

Run the same check against built frontend folders, CI variables, your hosting platform's settings and your gateway config. Give every key an owner. Disable anything nobody claims, wait a few days to see if something breaks, then delete it.

2. Keep Keys Out of Code and Clients

• Store secrets in a secrets manager such as HashiCorp Vault or AWS Secrets Manager, and fetch them at runtime.
• Never ship a key in browser JavaScript or a mobile app.
• Add secret scanning as a pre-commit hook and in CI. Tools like gitleaks, TruffleHog and detect-secrets recognize AI key formats.
• Confirm GitHub push protection is still switched on for your repos.

A basic gitleaks pre-commit hook takes two minutes:

gitleaks protect --staged --verbose || { echo "Secret found. Commit blocked."; exit 1; }

3. Scope Every Key Tightly

• Use one key per service and per environment. Never share a key between staging and production.
• Bind keys to the smallest container the provider offers, such as an Anthropic workspace or an OpenAI project.
• Restrict a Google key to the Gemini API only, and add an IP allowlist where you can.
• On cloud platforms, give each IAM role permission to invoke only the exact models and regions it needs.

A narrowly scoped key that leaks can only do narrow damage.

4. Make Keys Expire

Long-lived static keys are the worst case. They work from anywhere for as long as nobody notices.

• Anthropic lets you set an expiry when you create a key, and admins can enforce a maximum lifetime that removes the "never expires" option.
• OpenAI lets admins cap key lifetimes at the organization or project level.
• AWS lets you block long-term Bedrock keys beyond a set number of days with an IAM condition.

5. Swap Static Keys for Identity

This is the strongest fix. Instead of a secret string, the workload proves who it is through an identity provider you already trust and receives a credential that lasts minutes or hours.

• Anthropic supports Workload Identity Federation, which exchanges a token from AWS, Google Cloud, GitHub Actions, Kubernetes, Entra ID or Okta for a short-lived Claude access token. No API key to leak at all.
• AWS Bedrock offers short-term API keys that expire within hours, and AWS recommends them over long-term keys for production. Calling Bedrock with an IAM role and no bearer token is better still.
• Google now binds new AI Studio keys to a service account by default.
• GitHub Actions OIDC lets a workflow grab short-lived cloud credentials for a single job, so you store no cloud key as a repo secret.

Keep in mind that this setup is only as strong as the identity provider behind it. Lock down its trust rules too.

6. Lock Down Self-Hosted Models and Gateways

If you run your own models:

• Bind Ollama, LM Studio and similar servers to localhost unless remote access is truly needed.
• Put remote endpoints behind real authentication, ideally OAuth2 or OIDC with short-lived tokens, not just a static key.
• Keep AI servers on private networks with IP allowlists and current TLS.
• Never expose a gateway admin panel to the internet, and change any default master key.
• Give each team its own virtual key and budget inside the gateway.
• Strip auth headers and tool outputs from logs before storage.
• Pin gateway versions and review upgrades like any critical dependency.

7. Protect Agents and MCP Servers

• Keep real keys out of the agent's environment. A small proxy can hold the key and attach it to outbound requests while the agent only sees a local endpoint.
• Prefer remote MCP servers that use OAuth with narrow scopes over local servers configured with static tokens. The MCP security best practices also advise sandboxing local servers and limiting their file and network access.
• Give MCP and LLM components separate tokens so one leak does not unlock everything.

Do Spend Caps Stop LLMjacking?

Spend caps limit how much damage a stolen key can do. That makes them a genuine security control, much like a daily withdrawal limit on a bank card. OWASP even lists runaway usage as a top LLM risk under "Unbounded Consumption."

Caps still fall short in three ways:

• They do not stop the theft itself or protect data behind a gateway.
• A careful attacker spreads usage across many stolen keys and stays under every limit.
• A hard cap that trips also shuts down your own product. Decide in advance whether you accept that trade.

Set caps per project or workspace rather than only at the organization level. Put alerts well below the cap, for example at 20%, 50% and 100% of normal daily spend, so you catch abuse in hours instead of at month end.

What Should You Do If Your AI API Key Is Stolen?

Order matters. Deleting too early can break production and wipe evidence. Investigating too long lets the bill keep growing.

1. Disable the key now. Most providers offer a reversible disable or deactivate option. Use it before you investigate.
2. Ship a replacement. Issue a new key with expiry, tight scope and network limits, or move that workload to identity federation right away.
3. Cap the bleeding. Lower the project spend limit temporarily.
4. Pull usage for the exposure window. Break it down by key, model and hour. Save it as evidence.
5. Contact the provider. Report the fraud to billing or trust and safety. Some providers credit charges from documented theft, especially when you report fast. There is no guarantee, but always ask.
6. Find the leak. Search Git history, CI logs, frontend bundles, gateway logs, MCP configs and container images. If the key came from a laptop, treat that machine as compromised and rotate everything on it.
7. Check the blast radius. If the key lived in a gateway or agent, review prompts and outputs from that window for exposed data, and rotate every other secret stored beside it. If customer data flowed through, you may have privacy reporting duties under rules like GDPR or CCPA.
8. Delete the old key once the replacement works and the evidence is saved.
9. Close the route. Move to a proxy, add log redaction, switch CI to OIDC, and update your inventory with the new owner and expiry.

Rotating without revoking is the classic mistake. A new key does nothing if the old one still works.

LLMjacking Prevention Checklist: A One-Week Plan

Short on time? Work through this list in order. It gives the most protection per hour.

LLMjacking is not a clever new exploit. It is old-fashioned credential theft aimed at a credential that suddenly became very valuable. Treat your AI keys like your most sensitive cloud secrets: know where every one lives, scope it tightly, make it expire, and watch its usage by the hour. Do that, and a leaked key becomes a short annoyance instead of a five-figure invoice.

Frequently Asked Questions

Related Guides

• How to Fix Claude AI API Error 401 Unauthorized (14 Fixes)
• How to Fix ChatGPT Error 401 Unauthorized (App and API Guide)
• PHP2Shell Exploit Attempts Hit Millions as Attackers Try to Deploy Mirai Malware: What PHP Site Owners Must Patch Now
• How to Block AI Crawlers and Protect Your Website
• Attackers Are Using Microsoft Defender Against You: Fix CVE-2026-41091 and CVE-2026-45498 Now