LLMjacking: How Stolen AI Keys Run Up Your Bill, and How to Cap the Damage Today

In February 2026, a developer posted on Reddit that their three-person startup, which normally spent about $180 a month, faced $82,314.44 in charges over about 48 hours on a stolen Gemini key. The Register covered the post but hadn't yet heard back from them, so treat it as one unverified account. It's still a fair picture of LLMjacking: someone steals your access to AI models, sends traffic at volume, often resells it, and you get the bill.

The largest cases go much higher. Mandiant says charges in individual 2026 incidents passed $100,000 in a single day, and reached $1 million at some organisations before access was revoked. Those are what can happen, not what usually does.

Rotating keys matters, but LLMjacking is as much a spending-limit failure as a credential failure. You can't promise that no key will ever leak. You can decide today how much a leaked key is able to burn.

Here's the sum to run per key, the limits each provider offers, and a one-hour plan for a bill that has already spiked. It's part of our cybersecurity hardening work, but you can do all of it yourself.

Quick check. Open your provider's billing settings. Does each key sit under a limit that stops requests, not just an alert? Would anyone see a spike within an hour? If either answer is no, start with the sum below.

Updated 4 November 2026.

From one Laravel flaw to a resale market: how LLMjacking grew

Sysdig's threat team published the research that named LLMjacking in May 2024. Attackers broke into a system through an old Laravel flaw, CVE-2021-3129, stole cloud credentials and used them to reach cloud-hosted models. A script then tested those credentials against ten AI services without sending a real prompt, checking what each could do and whether logging was on.

Two years on, it's a market with a supply chain. Google's Threat Intelligence Group and Mandiant published their findings on 3 November 2026, describing incidents across several cloud and model providers, in financial services, retail, technology and transportation. The figures come from cases Mandiant investigated. Google, Wiz, Sysdig, Pillar, SentinelOne and CrowdStrike all sell security products, so treat the figures below as vendor numbers.

How attackers get AI access: leaked keys, stolen cloud credentials, exposed self-hosted models

Stolen cloud identities are the main door. Google says the dominant way in across its investigations was exposed or stolen cloud identity tokens, not model keys. That changes what you defend. An attacker holding a broad cloud credential can switch on AI services you never used. In multiple Mandiant cases, the model services weren't even enabled when the account was compromised.

Leaked model keys are the second door.

• Public code. One group harvested corporate keys from public GitHub repositories, then checked them with max_tokens=1 requests small enough to stay under volume alerts.
• Developer machines. Google saw controllers of the ACRSTEALER infostealer target the config files of the Cline and Continue coding assistants in May 2026. Those files can hold plaintext keys. Our note on the LiteLLM supply chain attack covers a related route.
• Your suppliers. Wiz reported on 30 October that a run of breaches at AI developer platforms exposed stored credentials. Two enterprise keys it tracked were validated within 30 minutes of being taken.
• Billing accounts. Wiz also described phishing through Google Search ads that ended with attacker projects linked to the victim's billing account and the victim's own billing admins demoted to read-only.

Exposed self-hosted models are the third door. Ollama binds to localhost by default, but one setting exposes it, and Sysdig notes it has no authentication of its own. SentinelLABS and Censys counted 175,108 reachable Ollama hosts across 130 countries, over 293 days of scanning. Pillar Security's honeypots logged 35,000 attack sessions against exposed AI endpoints between December 2025 and January 2026. Validation attempts typically followed public scanning within two to eight hours. The fix is in the provider table below: bind to localhost, and put an authenticating proxy in front.

Why the bill is the attack: resale, cost harvesting and stolen compute as attack tooling

Attackers aren't usually after your prompts. They're after the meter. This is cost harvesting: making someone else pay for usage.

Resale. Pillar found one marketplace selling access to more than 30 providers at 40 to 60% below retail. Google now describes "LLM Mixers", gateways that pool stolen credentials, meter use and resell it. One actor it tracked made more than 500,000 API calls in under eight hours for a routing service, passing nearly $1 million in token costs to the victim. Based on forums it tracks, Google said in September that average underground prices per AI account had more than doubled in 2026.

Volume at speed. CrowdStrike's press release for its 2026 threat report, a vendor source, cites a campaign sending nearly 200,000 model requests in two minutes. Wiz saw floods of about 800,000 and 1.7 million Bedrock calls on two keys, which it says likely ran up over $100,000 at list price between them. Wiz says it can't definitively link the resellers it found to the original breaches.

Free tooling. In June 2026, Sysdig watched an attacker use an exposed Ollama server as the reasoning engine for an offensive security tool, at hundreds of model calls per attack. No invoice arrives in that case, but your server is doing the work.

Small teams get hit as well, as the Gemini case at the top shows. The next section turns all of this into a number for your own keys.

Work out your exposure: a per-key worst-case calculation

Most articles quote Sysdig's $46,080 a day. That figure was real arithmetic for one setup in 2024: 500,000 tokens a minute at an averaged $0.016 per 1,000 tokens, across four regions, for 24 hours, on Claude 2.x prices. It isn't your number. Here's how to get yours.

Step 1: find the rate a key could reach. Look up its tokens-per-minute limit for the most expensive model it can call. On AWS, check Service Quotas, because your account's values can differ from the published defaults.

Step 2: price it.

Cost per hour = ((input limit in millions x input price) + (output limit in millions x output price)) x 60

Step 3: multiply by the hours before anyone acts. Be honest about this. If nobody looks at usage until an alert arrives, the alert's delay is your number.

Here's a worked example using Anthropic's published direct API limits and list prices, read on 4 November 2026. These are our calculations, and they assume an attacker saturates both limits. Cached reads mostly don't count toward input limits, so real burn could run higher. Use your own provider's price page: cloud marketplace prices and quotas can differ.

A cap is what makes the loss finite: on the lower tiers, it ends the event within about an hour. At Scale, detection does the real work. Twelve undetected hours on Sonnet 5.5 comes to $28,800.

Now write the answer down for every key: name, owner, provider, most expensive reachable model, cost per hour, cap, and who gets paged. If the "cap" column is empty, that's your first job.

LLMjacking prevention: a table of scope, limits, budgets and logging by provider type

Alerts and caps aren't the same thing, and the names don't always help. This is what each provider's documentation says as of 4 November 2026.

Then work through scope, which limits what a stolen credential can reach.

• One key per app and environment. Put each in its own project or workspace, with its own cap. Set the cap near a normal month plus a margin you could afford to lose.
• Accept the trade-off. OpenAI warns that hard limits can interrupt production traffic. Decide that on purpose, and alert well before you hit the cap.
• Restrict models. Google advises segmenting keys by model and environment, so a key for a cheap utility model can't call a costly one.
• Deny AI services where you don't use them. Wiz's JINX-2401 case on Bedrock is the proof: Service Control Policies blocked InvokeModel and the model agreement call, even after the attacker created new users.
• Prefer short-lived credentials on AWS. AWS recommends short-term Bedrock keys for production, which last at most 12 hours, and says long-term keys are for exploration only. You can also limit how long long-term keys live with iam:ServiceSpecificCredentialAgeDays. Our guide to GitHub Actions with AWS OIDC removes another stored credential.
• Scan code for secrets, and patch your gateway. Google lists a privilege escalation flaw in LiteLLM, CVE-2026-40217, among the paths it saw abused.

A cap has one clear limit: it protects you from a stolen key. It doesn't fully protect you from a stolen admin, who can raise the cap, create keys or link new projects. That's why cloud identity comes first, and why billing role changes need alerts.

How to detect it, and what to check first if your bill spikes

Turn on the logs before you need them. Several are off by default.

• AWS: Bedrock model invocation logging is disabled by default, and calls through the bedrock-mantle endpoint aren't captured by it. CloudTrail does record InvokeModel and Converse as management events, though not the keys themselves.
• Google Cloud: inference operations sit in Data Access logs, which are off by default.
• Azure: model invocations need Diagnostic Logs.

Then alert on the signals Google lists for AWS, with equivalents for other clouds:

• First use. PutUseCaseForModelAccess, CreateFoundationModelAgreement or any AI service being enabled where it wasn't before. Google says to treat unauthorised enablement as a critical event.
• Probing. ListFoundationModels, GetFoundationModelAvailability, single-token requests, and bursts of ValidationException or ThrottlingException.
• Hiding. GetModelInvocationLoggingConfiguration, plus any change to logging by a principal that isn't your infrastructure-as-code pipeline.

Our AWS cost guide covers the cost visibility underneath.

Is this attack or a bug? A runaway loop in your own code also spikes a bill. Check three things first:

1. Which identity or key made the calls? On Bedrock, group logs by identity.arn.
2. Do the source IPs and user agents match your app?
3. Does the model match what your code calls?

If any answer is no, treat it as an incident.

A one-hour response plan, including keys that leave access behind

Minutes 0 to 10: confirm and tell someone. Pull usage by key, model and region. Name one person as lead, and tell finance. Sysdig also suggests security and finance review spikes together.

Minutes 10 to 25: cut access.

• Disable first, delete later. Deactivating a key stops it and keeps the record you need for the investigation.
• Mind Bedrock's quirks. Deleting a long-term key doesn't delete the IAM user created with it. Deny both bedrock:CallWithBearerToken and bedrock-mantle:CallWithBearerToken, because denying only the first leaves the Mantle endpoint open.
• Short-term Bedrock keys can't be revoked one by one. Invalidate the session that generated them, or deny the identity.

Minutes 25 to 45: look for what they left behind. Attackers don't rely on the first key. Google saw backdoor service accounts disguised as billing optimisation tools, new IAM accounts and injected SSH keys. Wiz saw attacker projects linked to billing. Check for:

• new users, roles, access keys and service accounts
• quota increase requests
• changes to billing admins, organisation policies and logging settings
• projects linked to your billing account that you don't recognise

Minutes 45 to 60: close the door and open the claim. Rotate secrets from wherever the key was stored, including CI and developer machines. Find the way in. Open a support case with your provider and report it as unauthorised use, with timestamps and evidence. Then set the cap you should have had.

Frequently asked questions

List your keys this week, run the sum and fill the cap column. If you find gaps you can't close yourself, book a free consultation with one of our engineers. Bring the list, and we'll go through your cloud identity and AI setup and rank what to fix first.

Sources

• Google Threat Intelligence Group and Mandiant, The Rise of LLMJacking (3 November 2026)
• Google Threat Intelligence Group, From Prompting to Autonomy (September 2026)
• Wiz, "Black October" for AI developer platforms (30 October 2026, updated 3 November; vendor)
• Wiz, From phishing to LLMjacking (20 October 2026; vendor)
• Wiz, JINX-2401: LLM hijacking on AWS (December 2024; vendor)
• Sysdig, LLMjacking: stolen cloud credentials used in new AI attack (May 2024; vendor)
• Sysdig, LLMjacking: from emerging threat to black market reality (February 2026; vendor)
• Sysdig, stolen AI compute used to build offensive tools (June 2026; vendor)
• CrowdStrike, 2026 Threat Hunting Report press release (3 August 2026; vendor)
• Pillar Security, Operation Bizarre Bazaar (January 2026; vendor)
• SentinelLABS, Ollama hosts study with Censys (vendor)
• The Register, $82K Gemini bill after stolen key (3 March 2026)
• Ollama FAQ
• AWS, Handle compromised Bedrock API keys
• AWS, Bedrock API keys
• AWS, Bedrock quotas
• AWS, Bedrock model invocation logging
• AWS, Bedrock API calls in CloudTrail
• AWS, Managing costs with AWS Budgets
• AWS, Configuring budget actions
• AWS Customer Agreement
• OpenAI, API spend limits
• Anthropic, API rate and spend limits
• Anthropic, API pricing
• Anthropic, Workspaces in the Claude Console
• Google AI Studio, Gemini API billing
• Google Cloud, Manage spend cap budgets
• Microsoft, Create and manage Azure budgets