# What is LLMjacking? Stolen credentials, your AI bill

URL: https://infro.io/blog/what-is-llmjacking
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Guide

> LLMjacking is the use of stolen cloud or AI API credentials to call hosted language models at the victim's expense, either for the attacker's own use or to sell the access on. Sysdig's threat research team coined the term in 2024 after watching attackers use stolen AWS credentials against Bedrock; Microsoft later sued a group that used scraped customer credentials against Azure OpenAI Service. Defend with short-lived or narrowly scoped credentials, provider-side spend limits, per-key usage monitoring and fast revocation at the provider.

Key takeaways:
- LLMjacking is model access paid for with someone else's stolen credentials; Sysdig's threat research team named it in May 2024.
- Attackers validate a stolen key cheaply, enable models if they can, try to switch off logging, then use the access or sell it through a proxy that hides the key.
- Anthropic's September 2026 threat report says distillation proxies often use stolen API credentials of legitimate companies, which gives stolen keys a steady buyer.
- At the cloud level, prefer short-lived credentials and identity over static keys: Bedrock short-term keys, Azure with key access disabled, restricted Google keys.
- At the key level, scope every key, set provider-side spend limits, watch usage per key and rehearse revocation.
- A gateway's controls govern traffic that goes through it; a stolen provider key used directly is stopped only by the provider.

**What is LLMjacking?** LLMjacking is the use of stolen cloud or AI API credentials to run hosted language models at the victim's expense. The attacker either uses the access directly or sells it on, usually through a proxy that hides the stolen key from the people paying for it. The victim's account takes the bill, the quota exhaustion and, sometimes, the terms-of-service consequences of what was generated.

It is credential abuse with a model attached. What makes it worth its own name is the economics: a valid key for a frontier model is directly convertible into money, needs no further exploitation, and can be validated in one cheap request. This guide covers where the term came from, how the attack runs, what changed in 2026, and the defenses that work at the cloud and the API-key level.

## Where the term comes from

Sysdig's Threat Research Team described the attack in May 2024. Attackers had taken cloud credentials from a system running a vulnerable version of Laravel (CVE-2021-3129), then used them against hosted models, including Anthropic's Claude on Amazon Bedrock. A credential-checking script tested stolen credentials against ten AI services, among them AWS Bedrock, Azure, Google Cloud Vertex AI, OpenAI, Anthropic and Mistral. Sysdig found signs of an OAI Reverse Proxy, which lets an operator sell access to several LLM accounts without exposing the underlying credentials, and estimated a worst case of over $46,000 a day in consumption for the victim[1].

The September 2024 follow-up states that "LLMjacking is a term coined by the Sysdig Threat Research Team". It raised the worst-case estimate to over $100,000 a day for the most capable models of the time, and listed the motives it observed: free personal use, selling access to people banned by the provider, access from sanctioned countries, and a large share of roleplay prompts[2].

## How an LLMjacking operation works

The steps Sysdig documented on AWS generalise to any provider. What changes is which logs record them.

| Stage | What the attacker does | Where it shows up |
| --- | --- | --- |
| Obtain | Takes keys from a vulnerable server, a public repository, a client bundle, a compromised tool or a breached third party | Usually nowhere you watch; often the first sign is the bill |
| Validate | Sends a deliberately invalid request; a validation error instead of access denied proves the key works | Bedrock: `InvokeModel` calls returning `ValidationException` in CloudTrail[1] |
| Enable | Turns on models the account has not used, where permissions allow | Bedrock: `PutFoundationModelEntitlement` and `PutUseCaseForModelAccess`[2] |
| Hide | Checks or removes invocation logging so prompts are not recorded | Bedrock: `GetModelInvocationLoggingConfiguration`, `DeleteModelInvocationLoggingConfiguration` |
| Use or sell | Runs prompts directly, or puts the key behind a proxy and sells access | Usage on the key: models, volume and hours unlike your own |

Two details matter for defenders. First, validation is cheap and quiet: a single failed request is enough. Second, the hide step means you cannot rely on prompt logs to tell you what happened; CloudTrail records the API call but not the prompt or response content[1].

## Storm-2139: the Azure OpenAI case

In January 2025 Microsoft's Digital Crimes Unit said a foreign-based group had developed software using "exposed customer credentials scraped from public websites" to access accounts for generative AI services, alter what those services could do, and sell access to others with instructions for generating harmful content. Microsoft revoked the access, added countermeasures and, under a court order, seized a website central to the operation[3].

In February 2025 it named the network Storm-2139, identified Microsoft's Azure OpenAI Service among the affected services, and named four defendants in an amended complaint. It described three tiers: creators who built the tools, providers who modified and supplied them, and users who generated the content[4]. The case shows the full supply chain: credentials leaked by customers, tooling that turns them into access, and a sales layer in front.

## What changed in 2026: distillation became a buyer

Through 2024 and 2025, stolen keys were mostly sold for personal use and content the providers' policies refuse. In 2026, demand from model distillation added a buyer with a much larger appetite.

Anthropic's September 2026 threat report says the labs it identified generally reach its models through proxy services, also called "transfer stations", which create thousands of accounts using false identities, stolen payment cards and stolen API keys, and "will often use stolen API credentials belonging to legitimate companies or individuals". The same report describes criminal groups whose sole objective is compromised AI keys, session tokens and devices, selling that access through brokers, and says that for one group it tracked, the keys "were stolen from Anthropic customers' environments", not from Anthropic's systems[5].

The joint CISA, NSA and FBI advisory AA26-251A describes the same "transfer stations" as a gray market of proxies and lists indicators such as shared accounts used from many IPs and user agents, and round-the-clock usage with no idle periods. It is written about fraudulent and unregistered accounts; it does not discuss stolen customer keys[6]. Reading its indicators as signs that your own key has been taken is our inference, not the advisory's guidance, but they are a reasonable checklist for usage on a key you own.

On 2026-10-17 OpenCode disclosed a breach of its Console that it described as related to "a large-scale distillation attack" and in which third-party provider keys saved in workspaces may have been exposed; BleepingComputer reported users describing unauthorized charges overnight[7]. OpenCode has not published a root cause. [What OpenCode has said so far](https://infro.io/blog/opencode-console-breach-what-happened) is covered separately, and [how distillation campaigns use stolen keys](https://infro.io/blog/stolen-api-keys-distillation-campaigns) goes deeper into that market.

## Defenses at the cloud level

On a cloud provider the strongest move is to replace static secrets with identity, so that a copied string is worth little.

**Amazon Bedrock.** Bedrock offers short-term API keys, valid up to 12 hours and inheriting the permissions of the IAM principal that generated them, which AWS recommends for production; long-term keys are "for exploration only". You can deny `bedrock:CallWithBearerToken` to identities that should never use an API key, cap long-term key lifetimes with the `iam:ServiceSpecificCredentialAgeDays` condition, and deactivate, reset or delete a compromised long-term key[8]. Add the detections Sysdig recommends: alerts on model-access changes, on invocation-logging changes and on `ValidationException` bursts, with model invocation logging switched on[1].

**Azure OpenAI and Foundry Tools.** Set `disableLocalAuth` to `true`, or apply the Azure Policy that requires key access disabled, so that only Microsoft Entra identities can call the resource. Microsoft warns that the change is not instant: the gateway can keep accepting previously valid keys until its cache refreshes, which can take up to several hours, so verify with the old key before you consider it done[9].

**Google Cloud.** A standard Google API key does not identify a principal, so IAM cannot check who is calling. Google's documentation says "Unrestricted API keys are insecure" and recommends both API restrictions and application restrictions[10]. Where possible, call Vertex AI with a service account and IAM instead of a key. [How Google API keys reach Gemini](https://infro.io/blog/google-api-keys-gemini-exposure) covers the specific Gemini exposure.

## Defenses at the API-key level

Direct provider keys (OpenAI, Anthropic, Gemini API, and every other provider with a static key) cannot be replaced by identity everywhere yet, so reduce what each key is worth:

- [ ] **One key per workload and environment.** A key shared by three services cannot be revoked without breaking all three, so nobody revokes it.
- [ ] **Scope each key.** Project or workspace keys, restricted permissions, and an expiry date where the provider supports one.
- [ ] **Network restrictions where offered.** OpenAI supports IP allowlists at organization or project level; a request from an address not on the list is refused even with a valid key[11].
- [ ] **A spend limit at the provider.** It is the only ceiling that applies to a key used directly against the provider.
- [ ] **Usage per key, watched daily.** Abuse hides in an account total and stands out on the one key that should be quiet; see [signs your key is being abused](https://infro.io/blog/signs-ai-api-key-abused).
- [ ] **Secret scanning and push protection** on every repository, so the commonest leak path is closed.
- [ ] **A rehearsed revocation.** Know who can revoke each key, where, and what breaks when they do.

The per-provider steps are in the runbooks for a [leaked OpenAI key](https://infro.io/blog/leaked-openai-api-key) and a [leaked Anthropic key](https://infro.io/blog/leaked-anthropic-api-key). For storage and rotation in general, see [how to secure LLM API keys](https://infro.io/blog/secure-llm-api-keys).

> **Example: A quiet key wakes up**
> A team keeps one OpenAI project key per service. The key used by a nightly batch job normally shows traffic between 02:00 and 03:00 UTC on one model. One morning its usage shows steady traffic all night on a reasoning model the job never calls. Because the key belongs to one job, the on-call engineer revokes it at the provider, issues a new key for the job, and the rest of the company's traffic is untouched.

## How INFRO handles LLMjacking risk

INFRO is a gateway that runs on provider accounts you connect; it holds no provider accounts of its own. Its controls reduce what a leaked application credential is worth. Applications use INFRO gateway keys (`sk_infro_`), stored only as a SHA-256 digest, which can be limited to chosen providers and IP ranges (a request from elsewhere gets `403 ip_not_allowed` before any provider call), belong to one [environment](https://infro.io/docs/authentication), expire, and rotate with an overlap window. Budgets per organization, project, member and key are checked before the provider is called, and [spend alerts](https://infro.io/docs/observability/alerts) flag a day that departs from a scope's usual day. Provider credentials you connect are encrypted with AES-256-GCM and never shown again; see [Connect a provider](https://infro.io/docs/providers).

The limit is plain: INFRO's controls govern traffic that goes through INFRO. A provider key stolen from anywhere, including from a platform like INFRO that holds customers' provider keys, can be used directly against the provider, and no INFRO budget or allowlist sees that request. The backstops are at the provider: scoped keys, provider spend limits, usage monitoring and revocation. On the Business plan, with usage access on, [reconciliation](https://infro.io/docs/cost/reconciliation) compares OpenAI's and Anthropic's own usage data with what passed through INFRO, which can show traffic on your keys that did not go through the gateway.

## Summary

LLMjacking is model access paid for with a stolen credential. Attackers validate cheaply, enable what they can, hide what they can, and use or sell the access; in 2026 distillation proxies became a steady buyer for stolen keys. Replace static secrets with identity on the clouds, scope and cap every remaining key at the provider, watch usage per key, and make revocation something you have already practised.

## Questions

### What is LLMjacking?

The use of stolen cloud or AI API credentials to call hosted language models at the credential owner's expense. Attackers use the access themselves or sell it to others, often through a proxy that hides the stolen key from the buyer.

### Who coined the term LLMjacking?

Sysdig's Threat Research Team. It described the attack in May 2024 after observing stolen AWS credentials used against hosted models, and its September 2024 follow-up states the term was coined by the team.

### How do I know if I am a victim of LLMjacking?

Look at usage per credential: a key that should be idle but has traffic, models your code never calls, round-the-clock usage, or model-access and logging configuration changes you did not make. On AWS, CloudTrail records Bedrock API calls such as InvokeModel and changes to model invocation logging.

### Can a gateway or proxy stop LLMjacking?

Only for traffic sent through it. If a provider or cloud credential is stolen, the attacker calls the provider directly and no gateway sees the request. Provider-side spend limits, scoped and short-lived credentials, and revocation at the provider are the controls that still apply.

## Sources

1. LLMjacking: Stolen Cloud Credentials Used in New AI Attack — Sysdig. https://sysdig.com/blog/llmjacking-stolen-cloud-credentials-used-in-new-ai-attack/ (accessed 2026-10-21)
2. The Growing Dangers of LLMjacking: Evolving Tactics and Evading Sanctions — Sysdig. https://sysdig.com/blog/growing-dangers-of-llmjacking/ (accessed 2026-10-21)
3. Taking legal action to protect the public from abusive AI-generated content — Microsoft. https://blogs.microsoft.com/on-the-issues/2025/01/10/taking-legal-action-to-protect-the-public-from-abusive-ai-generated-content/ (accessed 2026-10-21)
4. Disrupting a global cybercrime network abusing generative AI — Microsoft. https://blogs.microsoft.com/on-the-issues/2025/02/27/disrupting-cybercrime-abusing-gen-ai/ (accessed 2026-10-21)
5. Detecting and countering misuse of AI: September 2026 — Anthropic. https://www.anthropic.com/threat-intelligence-report-september-2026 (accessed 2026-10-21)
6. China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies (AA26-251A) — CISA, NSA and FBI. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-251a (accessed 2026-10-21)
7. OpenCode hack exposes API keys amid AI distillation attacks — BleepingComputer. https://www.bleepingcomputer.com/news/security/opencode-hack-exposes-api-keys-amid-ai-distillation-attacks/ (accessed 2026-10-21)
8. API keys (Amazon Bedrock User Guide) — Amazon Web Services. https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html (accessed 2026-10-21)
9. Disable local authentication in Foundry Tools — Microsoft Learn. https://learn.microsoft.com/en-us/azure/ai-services/disable-local-auth (accessed 2026-10-21)
10. Manage API keys — Google Cloud. https://docs.cloud.google.com/docs/authentication/api-keys (accessed 2026-10-21)
11. IP allowlisting for OpenAI API — OpenAI Help Center. https://help.openai.com/en/articles/20001201-ip-allowlisting-for-openai-api (accessed 2026-10-21)