A leaked API key used to mean someone ran a crypto miner on your account. Now it can mean someone resells your access to the most expensive models on the market and you receive the invoice. Google Threat Intelligence Group and Mandiant report that they responded to multiple incidents in 2026 in which threat actors hijacked enterprise access to large language models, a tactic known as LLMjacking. Victims were in North America, South America and Asia-Pacific, in financial services, retail, technology and transportation.
We have covered the leaks that feed this market, from a poisoned LiteLLM release to a platform's environment-variable store. This is what happens to the keys afterwards.
What Mandiant and Google report
The report is first-party incident-response work, published on 3 November. We have not seen it independently reproduced, and it does not say how many victims or incidents there were in total.
- Where the credentials came from. Mostly exposed or stolen cloud identity tokens, which the report calls the dominant vector, along with cloud IAM credentials and service-account keys, misconfigured cloud instances, GitHub personal access tokens, active session tokens captured through fake portals, federation tokens used to mint access keys, LLM API keys harvested from public repositories, and publicly exposed model endpoints.
- What attackers did first. They validated stolen keys quietly with requests that ask for a single output token, then enumerated models, regions, identity policies and secrets.
- How they dug in. Privilege escalation through token-creation abuse and admin policy attachment; persistence through rogue IAM users, SSH keys in virtual-machine metadata and fake “billing” service accounts; and enabling AI services and creating new API keys inside the victim's account.
- How they spent it. Pay-as-you-go subscriptions and premium models, and “burn and rotate” service accounts to dodge rate limits. The report also describes exploitation of a flaw in the LiteLLM gateway, tracked as CVE-2026-40217, to gain administrator rights on the proxy. That is a separate matter from the compromised release we covered.
- How they sell it. So-called LLM mixers resell stolen access through gateways and custom relays, at prices far below market, which the report takes to imply stolen keys. It describes a division of labour between access brokers and downstream resellers.
- What it cost. Spikes of more than $100,000 in a single day, up to about $1 million in cumulative charges before revocation, one actor making over 500,000 API calls in under eight hours, and one reseller passing roughly $1 million in token costs to a victim.
What is not known
- The totals. How many victims and incidents there were, and how large the resale market is.
- How every key was obtained. The report does not say, and its section on supply-chain malware's role is thin.
- Attribution. Beyond named clusters, there is none.
- Which of the recommended controls work best in practice. The report does not measure that.
Why this is a secrets problem first
Almost every path above begins with a credential that was too powerful, too long-lived or in the wrong place. A key that can call any model in any region, with no spending limit, is a blank cheque. The attacker's first move, a one-token test request, is deliberately cheap and quiet, so you will not see it in a bill. By the time cost alerts fire, the abuse has usually been running for hours.
It also changes the value of a stolen secret. A cloud key used to be worth what its owner's infrastructure was worth. An AI-model key has a direct resale price.
What to do
- Inventory every AI key and token. Provider API keys, cloud identities with model access, gateway admin keys, and the CI variables and environment variables that hold them. If you cannot list them, you cannot rotate them quickly.
- Prefer short-lived credentials. Use federated or role-based access that expires, centralised secrets management and automated rotation in place of long-lived keys in files and variables.
- Deny model services by default. Use least privilege so most identities cannot call, or enable, AI services at all, and treat the enabling of an AI service in your account as a critical alert.
- Scope keys tightly. Restrict each key by model, environment and use, set per-model quotas and spending caps, and configure budget alerts that wake someone up.
- Scan for leaked keys. Search your repositories, public and private, including history, for provider keys and tokens, and remove and revoke any you find. Deleting is not revoking.
- Turn on the logs that show model use. Data-access logs on Google Cloud, model-invocation logs on AWS and diagnostic logs on Azure. Look for low-volume validation sweeps, which are the early signal.
- Patch AI gateways and ML dependencies like any internet-facing service, and do not expose model endpoints publicly. Restrict outbound traffic where you can.
- Use phishing-resistant multi-factor authentication for the accounts that can create keys, since session tokens captured on fake portals are one of the routes.
- If you find abuse, revoke the key, remove rogue identities and keys the attacker created, check for added service accounts and SSH keys, and rotate whatever else the compromised identity could reach.
The handover after a rotation
Replacing a dozen AI and cloud keys means new values reaching the engineers who configure the services. Do not put them in the same chat, ticket or repository the old ones leaked from. Send each value once, to the one person who needs it, over a channel that does not keep it.
Where Secretus fits, and where it does not
Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.
It is not a cloud security or secrets-management product. It cannot cap your model spending, scan repositories, disable an AI service or revoke a provider key. Use your cloud provider and scanner for that, and a one-time link for the moment one person gives another a credential.