LLMjacking, How Stolen AI API Keys Turn Your Cloud Bill Into An Attack Budget

"Resource hijacking" is not a new idea in security. Cryptojackers spent years burning customer CPU for their own profit. LLMjacking is the same economics re-priced for the model era: an attacker takes a leaked cloud or provider credential and buys inference on your account. The difference is that the payout this time is an invoice and a quota, not coins.

Core assessment: LLMjacking is not an AI vulnerability. At its root sits a stolen or accidentally published credential. Nothing about the model, the prompt, or the weights is broken; what breaks is the billing and identity layer. That is why the fix belongs to the identity and cloud operations team, not only to the ML team.

Why This Became Urgent Now

Three shifts changed the attack's profit curve:

1. High unit cost. Long-context, reasoning-mode, multimodal calls burn thousands of tokens per request. Mining had hashes per second; this has tokens per second, and the cost per second is both higher and far more predictable.
2. No quota means no ceiling. Most accounts open in "consume now, settle at month end" mode. A card-backed or invoiced project has no natural cap; the cap is how fast reconciliation notices.
3. Keys are everywhere. Mobile apps, browser extensions, edge functions, automation scripts, CI/CD steps, an analyst's laptop notebook. Every new surface increases the chance a secret lands client-side.

The result: in classic credential stuffing the attacker steals your data and monetises it once. In LLMjacking, the stolen credential stays plugged into a generative spending machine that produces value at scale until it is detected.

Where Keys Leak

Ordered roughly by what we actually observe in assessments:

The last two rows are the most commonly missed. You may never have handed out the key — but the invoice can still land in your name.

Anatomy Of The Attack

A typical chain runs in five steps:

1. Credential acquisition. A key or OAuth token is obtained through one of the paths above.
2. Liveness check. One cheap request. The goal isn't the model; it's confirming the key is alive and discovering which limits apply.
3. Broker layer. The key is rarely used directly. Intermediary services pool stolen keys and resell access, which both distances the attacker's IP from you and replays traffic with plausible client fingerprints (user agents, SDK versions).
4. Volume. Long system prompts, repetitive generation, maximum output limits, sometimes synthetic-data loops. The objective is maximum tokens per request.
5. Credential refresh. When one key hits a quota or budget alarm, the attacker mints another from the same leak source. Twelve keys from one repository can burn invoices across twelve separate projects.

The critical consequence: the attack looks exactly like your normal traffic. Valid schema, authorised key, legitimate client. Unlike a classic authentication bypass, the boundary violation happens in the billing and identity layer rather than the application layer.

Cost Math

Decision-makers always ask "how big can this get", so show the arithmetic rather than the anecdote.

Take a single call at 100K input plus 2K output tokens. On a mid-tier frontier model that can cost tens of cents. Four parallel workers issuing it four times per second generate roughly 14,400 requests an hour. Run twenty hours a day and one worker moves from low-three-figure daily spend to five and six figures monthly. Add three workers, two regions and two service accounts and "hundreds of thousands" stops being a rhetorical flourish.

Three practical constraints fall out of that math:

• Limits must come from inside. A provider's default quota is a pricing tool, not a security control. Your own thresholds, caps, and kill switch have to exist.
• Detection latency equals damage. Most of a $500,000 incident happens on accounts that reconcile weekly. Daily reconciliation shrinks the blast radius to a day; hourly shrinks it to an hour.
• Detectability must be designed. If you don't know a key's normal usage profile, you cannot define abnormal usage.

Detection, Signals That Actually Work

Most alert lists are noise. The useful ones join spend data with identity data.

Workload-shape anomalies. Geographic and time-of-day signals are weak — proxies flatten them. Shape signals are strong:

• Unusually long average prompts with outputs pinned at max_tokens.
• Concurrent request count from a single client fingerprint.
• Sudden migration to a model family you never use (typically the most expensive reasoning tier).
• Token volume climbing linearly during normally quiet windows.

Key scope inventory. How many live keys exist, which environment each sits in, and which have seen no traffic in 90 days? An unused key is risk without cost — deleting it is free.

Secret exposure monitoring. Public code search, repository history, reverse-engineered mobile binaries, JavaScript bundles, config files. The important nuance: scanning only HEAD is insufficient. History must be scanned too; a revoked key often keeps living in an old commit.

Billing reconciliation. Diff the provider's billing API against your internal usage records. Even a one percent drift is the highest-confidence anomaly signal available, and no SIEM will surface it without credential correlation.

Defence, Ordered By Effort Over Effect

1. Get secrets out of the client. A browser or mobile app must never talk to the provider directly. Put a gateway in front: your application carries identity, only that layer sees the key. This single change closes most of the surface and gives you one central audit point.

2. Put a budget and quota on every key. Each use case gets its own credential, capped slightly above that use case's real cost. Include promo and trial credits — they aren't in cost-centre tracking, which makes them the most frequently forgotten line item.

3. Make rotation mandatory and boring. Short-lived, automatically issued credentials instead of long-lived static keys. Wherever rotation is manual, the LLMjacking window stays open until the next human mistake.

4. Consolidate the source of truth. Secret manager plus a broker plus workload identity. "Who can obtain which key, under which role" needs a written answer.

5. Measure and attribute. Push usage down to identity: tokens and cost per user, client, or workflow. Without that data you can neither define an anomaly nor answer "what was the blast radius" afterwards.

6. Write the incident runbook. For a suspected key: revoke → rotate → determine blast radius → freeze/dispute spend → reconcile with provider → root cause. Who owns each step and how long they have should be decided before the incident, not during it.

Decision Table

Questions That Actually Matter

What we ask in an AI security assessment to size this risk:

1. How many distinct credentials reach model providers, and who owns each?
2. Does any client (browser, mobile, edge) call the provider directly, or is there a broker layer?
3. Is there a spend cap and quota per key — and who is allowed to change it?
4. Who receives budget alerts, and what is the response SLA?
5. What is the rotation period, and is rotation automated?
6. Is public code and repository-history scanning running, and who closes the findings?
7. Can usage logs be attributed to identity (user, client, workflow)?
8. Is the provider billing API compared with internal usage data?
9. Is there a written procedure to revoke a suspicious key within minutes?
10. Are trial and promo accounts inside cost tracking?
11. Which third-party gateways, prompt tools, or analytics vendors hold a copy of your key?
12. How long does the provider retain access logs, and can you export them?

Checklist

• No provider key exists in any client.
• Every use case has its own credential and its own cap.
• Key inventory is complete; 90-day-unused keys are revoked.
• Rotation is automated; manual leftovers are on the risk register.
• Budget alerts exist, with a named owner and an SLA.
• Public code plus history scanning is automated with a closure workflow.
• Per-identity token and cost reporting is delivered regularly.
• Provider invoices are reconciled against internal usage records.
• A LLMjacking runbook exists and has been tabletop-tested.
• Trial and promo accounts are attached to a cost centre.

When Is This Worth Taking Seriously?

If your application calls a model provider with a billed credential, and that credential reaches a client or scattered scripts, the question is not whether it happens but when and how expensive it gets. This is a classic hidden-cost plus hidden-breach combination: finance sees one half, security sees the other, and if nobody joins them, neither side sees the attack.

Eresus Security does not produce bare finding lists in this area. We give you the leak path, the affected identities, the real spend curve, and a closure calendar. The related service tracks are AI security services and prompt injection testing; the continuous verification side is described on the Eresus Guard platform page.

FAQ

How is LLMjacking different from cryptojacking?

Both make your resources work for someone else. The difference is the resource: cryptojacking steals compute, and the damage usually appears as degraded performance. LLMjacking consumes a purchased service, so the damage appears on an invoice, the unit cost is far higher, and it scales quickly. Because it arrives as legitimate API traffic, it also slips past most network detection tooling.

Are only enterprise accounts at risk?

No. Severity scales with billed headroom; likelihood scales with how widely the key is distributed. Individual developer accounts, agencies and startups are usually more exposed despite lower limits, because cap, rotation and monitoring are often simply not configured. Trial credits are both uncapped and untracked.

Isn't the provider's own abuse protection enough?

Providers are good at spotting abnormal usage, but their objective is platform and payment risk, not your workload. They don't know which model family your team normally uses or what your spend baseline is. And when they do stop your billing or disable a key, you learn about it after the fact. You still need your own limits and telemetry.

Can a penetration test surface this risk?

Partly. A pentest reliably catches keys shipped to clients, secrets in repository history, and missing gateway layers. It cannot capture production spend behaviour over time. So the output should be two halves: a structural review (where identities live and who can obtain them) and an operational observation (usage profile and reconciliation drift). Continuous monitoring is what keeps the first half true after the test ends.

Next Step

Read this alongside AI supply chain attacks, AI agent identity attack paths and zero trust architecture for AI models. All three attack the same discipline from different angles: who holds this secret, and who is able to?