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 victim1.
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 prompts2.
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 CloudTrail1 |
| Enable | Turns on models the account has not used, where permissions allow | Bedrock: PutFoundationModelEntitlement and PutUseCaseForModelAccess2 |
| 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 content1.
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 operation3.
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 content4. 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 systems5.
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 keys6. 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 overnight7. OpenCode has not published a root cause. What OpenCode has said so far is covered separately, and how distillation campaigns use stolen keys 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 key8. Add the detections Sysdig recommends: alerts on model-access changes, on invocation-logging changes and on ValidationException bursts, with model invocation logging switched on1.
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 done9.
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 restrictions10. Where possible, call Vertex AI with a service account and IAM instead of a key. How Google API keys reach Gemini 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 key11.
- 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.
- 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 and a leaked Anthropic key. For storage and rotation in general, see how to secure LLM API keys.
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, expire, and rotate with an overlap window. Budgets per organization, project, member and key are checked before the provider is called, and spend 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.
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 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.