LLMjacking: How Leaked Cloud Keys Let Attackers Burn Your AI Budget

LLMjacking is what happens when a leaked cloud credential becomes someone else's free AI budget. On September 3, 2026, Cybersecurity News reported an intrusion — documented by security researchers at FortiGuard Labs — in which a leaked AWS IAM access key with AdministratorAccess let an attacker run paid AI model inference through the victim's own account and bill it to the victim. Can someone steal your AI API access? Yes. The warning signs are quiet, and for many small businesses the first signal is an invoice.

This guide explains what LLMjacking is, how the reported September 2026 attack worked, how to spot theft, and a five-step checklist to protect your LLM API keys.

What is LLMjacking?

LLMjacking is a form of cloud abuse in which attackers hijack a business's paid access to large language models and other AI APIs. Instead of mining cryptocurrency or exfiltrating data with stolen credentials, they run model inference that the legitimate account holder pays for. Stolen access is often resold as bargain AI chatbot subscriptions on Telegram and Discord, researchers report; one tracked campaign, Operation Bizarre Bazaar, has been linked to more than 35,000 attack sessions across more than 30 LLM providers.

LLMjacking vs. cryptomining: attackers monetize your billing relationship

The shift changes how you defend. Cryptomining abuse is loud; LLMjacking is quiet because what is stolen is not compute but the victim's billing relationship with the cloud provider. The calls are legitimate-looking requests to legitimate endpoints; the meter runs against the wrong account.

Not just an API key: the case started with an AWS IAM key

Most “API key theft” talk pictures an application key pasted into a public repository. This case started one level up. The leaked credential was an AWS IAM access key — the identity credential for the entire cloud account — carrying AdministratorAccess, the highest level of privilege an AWS identity can hold. Whoever holds it can create users, change permissions, and sign up for paid AI services in your name.

The September 2026 attack: one leaked AWS administrator key

How it unfolded

Cybersecurity News reported on September 3, 2026, that FortiGuard Labs traced the intrusion to a long-lived AWS IAM access key carrying AdministratorAccess that had leaked. The attacker then:

1. Created a brand-new IAM user inside the victim's AWS account.
2. Subscribed to foundation models through AWS Marketplace, issuing CreateAgreementRequest and AcceptAgreementRequest calls.
3. Invoked the models directly, generating inference charges billed entirely to the compromised organization.

In several similar cases, attackers also generated Bedrock service-specific API keys for the new identity — a second, less conspicuous inference path.

Why it is so hard to detect

The calls originate from technically valid, permissioned credentials, so at the network and API level the traffic looks identical to legitimate usage. Signature-based defenses do not catch it, because nothing about the traffic itself is inherently malicious. That is why FortiGuard recommends enabling AWS CloudTrail in every account and turning on Bedrock invocation logging — disabled by default — which captures request-level detail that CloudTrail alone misses.

What the report does not say

The report names no victim organization, explains no leak vector, and attaches no dollar figure to the unauthorized usage. Treat the chain as documented and the cost as unknown: dollar figures attached to LLMjacking elsewhere name legacy Claude models and come from earlier research, not this incident.

Can someone steal your AI API access?

Signs of AI API key theft rarely look like a classic breach. FortiGuard's guidance: act on corroborating signals, not any single event. Investigate:

• IAM users or access keys you did not create — the strongest signal in this attack chain.
• AWS Marketplace agreements or Bedrock subscriptions you never approved.
• Spend anomalies: inference or API charges climbing without a new workload behind them.
• Unfamiliar IP addresses or regions calling your AI APIs or hitting your AWS account.
• Enumeration behavior or spikes in access-denied errors as the attacker probes what the stolen identity can reach.

One caution from FortiGuard: do not treat first-time Bedrock usage as automatically safe or automatically suspicious. It is actionable only when paired with a corroborating signal, such as a newly created identity or an unfamiliar IP.

How to protect LLM API keys: a 5-step checklist

If you run AI workloads in AWS, or call LLM APIs from code, agents, or vendor integrations, work through this list. AWS IAM AI agent security comes down to which identities can call paid model APIs and how long their credentials live.

1. Rotate long-lived IAM keys now

The entire September 2026 chain hinged on a single non-expiring administrator key. Delete unused IAM access keys, rotate any older than 90 days, and treat any broad-scope key that touched code, logs, or CI as exposed.

2. Apply least privilege — no standing AdministratorAccess

No human or machine identity should hold AdministratorAccess by default. Scope IAM policies to the services and actions a workload actually needs, and review elevated permissions on a schedule. A key that can call only the one model API it needs is worth far less to an attacker.

3. Use short-lived, role-assumed credentials for workloads and AI agents

Prefer IAM roles with temporary credentials over long-lived access keys for anything automated, including AI agents; short-lived credentials expire on their own, so a leak stops being a standing backdoor. Where agents or vendors need access, use an identity layer that issues and revokes credentials centrally.

4. Turn on AWS CloudTrail and Bedrock invocation logging

CloudTrail across every account reconstructs the sequence of identity creation, credential issuance, and marketplace subscription. Bedrock invocation logging, disabled by default, captures request-level detail that shows which models ran and when. You cannot investigate what you did not record.

5. Monitor LLM and API spend anomalies, new identities, and unfamiliar IPs

Alert on inference and API spend, new IAM users and keys, new Marketplace agreements, and calls from unexpected regions. Budget alerts alone are not enough — pair them with identity and access signals so you catch the attacker before the bill spikes.

What to do if you find unauthorized AI usage

1. Revoke the leaked credential immediately — rotate or delete the exposed IAM key.
2. Audit IAM and delete attacker-created identities. Rotating the leaked key does not remove a user the attacker created; delete it and any keys attached to it.
3. Cancel unauthorized subscriptions — Marketplace agreements and Bedrock model access you never approved.
4. Turn on CloudTrail and Bedrock invocation logging to reconstruct what happened.
5. Keep a record for your provider and insurer. Whether cyber insurance covers AI agents depends on what you can document.

Dormant and orphaned keys: the key that outlives the server

Everything above describes a theft and a spend that happen close together. In the GTG-50014 case in Anthropic's September 2026 report, one stolen key was reused for roughly three weeks of secondary attacks. This section exists for the other shape, and the time differential is the whole point of it: a key that was compromised, then sat unused for months while the infrastructure it belonged to had already been shut down, and was only spent long after everyone had stopped watching that environment. The exposure is not vendor-specific: a stolen OpenAI API key and a stolen cloud IAM key are the same problem with the same recovery path, because nothing about a key changes when the service behind it does.

A billing alert on an account that had already been retired

On 13 September 2026 at 17:59 UTC (13:59 ET), the developer known as @levelsio described that pattern in his own account. He wrote that he had killed his OpenClaw VPS servers months earlier, but that day received a billing alert on a separate Claude account, claudeforopenclaw@. He checked his own terminals and his VPS sessions and confirmed that none of them used the API. He then closed the account.

The chain that connects those two events is his own inference rather than a finding, and he is explicit about that: “I guess at some point it got hacked and the Claude key inside OpenClaw got exposed and then they waited for months before using it on Fable 5.1.” No vendor has disclosed an intrusion here and no forensic account of the path has been published, so read the months of dormancy as the operator's own stated guess, not as a documented attack path. What is not a guess is the control that contained it — “good I kept it on its own separate one.” That account was kept separate by design, and because it was separate, the alert landed somewhere he could close on the spot instead of in the account his business actually runs on. His post is here, and mirrored at twiscan if you cannot read X directly.

What Anthropic says about the direction of travel

Anthropic's September 2026 report, Countering misuse of AI, is direct about where this is heading: “Organizations should treat AI keys and agent integrations with the same level of seriousness as they do production credentials — because attackers treat them with the same level of seriousness, too.” It adds that “AI access should be purchased only through authorized channels,” and that providers will “share threat information and best practices” with their partners — see the report itself. Its supply-chain finding is the one that lands here: access to AI in the form of “compromised API keys, session tokens, and devices” has become an objective for criminal groups in its own right, and those groups resell it through brokers. A credential attached to something you have already retired is inventory, not history.

One caution on figures: no reliable number has been published for how many AI API keys are stolen, or for what share of them sit dormant before they are used, so nothing in this section carries a percentage.

Four controls for credentials you have already retired

The five steps earlier are about keys you still use. These four are about the keys attached to servers, accounts and projects you have already shut down, and if you have decommissioned anything in the last year they are worth running this week.

1. Inventory keys per environment, not per vendor. One list per cloud account, per project, and per environment that has been retired, with a named owner for each. Our breakdown of Anthropic's September 2026 report for a small business makes the same point as the first of its seven controls: inventory every AI key you own, and everyone who holds one.
2. Revoke keys as part of the decommission, not as follow-up work nobody owns. Retiring the server, the account or the project does not revoke the credentials that were issued to it; that is a separate action, and it needs an owner and a date. This control is about API keys. For the agent-identity version of the same problem, see our AI agent decommissioning checklist.
3. Alert on any spend from a retired environment. Expected spend there is zero, which turns any charge into a signal instead of a variance. The decommissioning checklist puts the principle better than we can: “If the identity authenticates again, you want an alert, not an invoice.”
4. Keep high-risk AI accounts financially isolated so a leak cannot auto-recharge. A separate account, a separate payment method, prepaid credit where the provider offers it, and auto-reload left off. The operator in the case above noted that his account “didn't have auto reload on” — a second brake on the same incident, independent of the account being a separate one.

And the honest answer to “how would I know?” is the signal that did the work in this case: the invoice. A billing alert on an environment you believed was empty is the detection signal, because nothing else is watching a deployment you have retired. That signal now sits in the FAQ answer at the end of this page, and the seven-item version of these controls, written as a standalone checklist you can work through this week, is on dormant AI API keys: revoke what your retired servers still hold.

The bigger picture: AI credentials are the new attack surface

LLMjacking is the second act of a story this site has tracked all month. Anthropic's September 2026 threat report named the pattern too: in its GTG-50014 case, one stolen AI API key was reused for roughly three weeks of secondary attacks against other organizations — our breakdown of what that report means for a 20-person business walks the case and the seven controls it hands you. On August 31 we covered AI crawler credential theft: scanners posing as ClaudeBot and GPTBot, with exact user-agent strings, hunting exposed .env files and cloud keys on sites that trust crawler names. LLMjacking is what stolen keys are for — running paid models on someone else's account — so a key harvested by a fake crawler and a key leaked into a repository end in the same place: billed to you.

The fix lives at the identity layer. Our guide to AI agent identity governance covers centrally managed, short-lived identities for AI agents — including the Okta Agent SSO approach that went GA in August — so credentials are issued, scoped, and revoked instead of living in files. The pattern repeats across providers, as our OpenAI Hugging Face AI agent hack analysis showed. For a full sweep, see the AI agent security risks primer and the AI agent risk checklist, which now include IAM and API-key audit items. The same asymmetry shows up when the compromise starts in someone else's code rather than yours: our explainer on the RubyGems agent attack and what to audit when a third-party dependency is the one that gets compromised works through that case.

Bottom line for small businesses

LLMjacking does not require exotic skills: one leaked administrator key, a few API calls, and the meter runs against your account. You do not need to run frontier AI to be a target. If you have not inventoried your cloud and API credentials this year, do it this week: a short audit plus the five steps above removes the chain the September 2026 case depended on.

Run the free AI audit tool

Frequently asked questions