Google GTIG on LLMjacking: Stolen Cloud AI Access Now Costs Victims Up to $1 Million

Google Threat Intelligence Group (GTIG) and Mandiant published a report on November 3, 2026 that puts hard numbers on a problem developers have worried about for two years: criminals who steal cloud AI access and sell it on. In several 2026 incidents, fraudulent charges passed $100,000 in a single day, and some organizations reached $1 million before anyone revoked access. The report calls the practice LLMjacking and says it is becoming more attractive to attackers than cryptojacking.

This is a security story with a direct billing consequence for anyone who holds a cloud AI key. Below is what Google says it found, how the attacks work step by step, what is confirmed and what is not, and a checklist you can run today. Earlier explainx.ai coverage of the same trend includes the Railway and OpenRouter key-theft claims and Symantec's Skynet Mode agent that hijacks exposed models.

Agents that act on your behalf need rules. See how explainx helps secure your agents →

TL;DR: what Google reported

What Google actually says happened

According to Google's report, Mandiant responded to several 2026 incidents in which threat actors took over an enterprise's access to large language models. The report describes a division of labor. Some operators specialize in initial access and steal credentials. Others, which Google calls LLM Mixers, specialize in turning that access into money.

The speed is the point. Google writes that, unlike the slow resource use of cryptojacking, LLMjacking "can generate large spikes in fraudulent cloud charges in a matter of hours." A compromised key attached to a premium model is a very efficient way to burn someone else's budget.

Google does not name any victim, cloud provider or specific model vendor. Treat the loss figures as Google's own aggregate observations from incident response work. They are not audited invoices, and the report gives no count of how many organizations were affected.

How the attackers get in

Google lists several entry routes. None of them involve breaking a model. They all abuse ordinary credentials.

• Stolen cloud identity tokens. IAM credentials, service account keys, GitHub personal access tokens and active session tokens are the dominant vector, per the report.
• Session hijacking. The group UNC6993 hosted a fake "application portal" page where users pasted a raw JSON payload containing a live access token. Because the token was already authenticated, this bypassed passwords and MFA.
• Federation tokens. Attackers used cloud federation tokens to mint fresh access keys and sidestep MFA.
• Exposed model servers. Public Ollama instances were probed with automated scripts that called the /api/create endpoint to register the attacker's own models.
• Keys scraped from public repositories. Stolen LLM API keys were harvested from public GitHub repos.

In many cases, the LLM services were not even switched on in the victim account. Attackers used the stolen keys to enable them. That detail matters for defenders, because "we do not use that service" is not a defense if a key can turn it on.

A quiet way to test stolen keys

One technique stands out. Google says validation sweeps used minimal requests, with max_tokens=1, to confirm that a stolen key worked. A one-token request produces almost no usage, so it slipped past volume-based alerts in endpoint detection and SIEM tools. The report says this let the actor "stealthily confirm the viability of the stolen keys" without tripping anomaly alarms.

If your only detection is a spike in token usage, you will see the attack only after the monetization phase begins. Watch for low-volume, repetitive probes from unfamiliar identities as well.

What attackers do once inside

The report goes beyond key theft. After access, actors did the following:

1. Mapped the environment across cloud regions to learn services and identity policies.
2. Hunted for more secrets by cloning codebases, scanning access logs, and querying data warehouse metadata tables for database credentials and admin passwords.
3. Escalated privileges by abusing token-creation rights to get temporary credentials for high-privilege service accounts, then pulling infrastructure credentials and third-party API keys from secret managers.
4. Planted persistence with unauthorized IAM users and service accounts, administrative policies on service roles, and SSH keys injected into VM metadata. One backdoor service account was disguised as an "internal billing optimization utility."
5. Scaled the abuse by enabling managed generative AI platforms, creating more API keys, subscribing victim accounts to pay-as-you-go agreements, provisioning GPU instances and requesting quota increases.
6. Dodged rate limits with a "burn and rotate" tactic: creating and deleting short-lived service accounts again and again while watching the billing.

The LiteLLM gateway shows how a supply-chain component becomes a target. Google says CVE-2026-40217, a user ID rebind bug in the /key/regenerate endpoint, let an attacker promote an ordinary virtual key to PROXY_ADMIN. If you run a model gateway, patch it first. Our earlier note on a compromised LiteLLM release covers a different incident, but the lesson is the same: the proxy that holds all your keys is a high-value target.

What are LLM Mixers?

The report's most useful new term is LLM Mixer. Google defines these as illicit routing gateways that "proxy, aggregate, and resell unauthorized LLM access to underground subscribers."

Think of a Mixer as a reseller front-end. Stolen keys from many victims go in. A clean, OpenAI-style endpoint comes out. A buyer pays a flat fee and never sees whose account is paying.

Pricing shows the margin. Google says Jet Night offered an unlimited plan for about $60 a month, against a typical consumer-tier market rate of $100 to $250 a month. The seller pays nothing for compute, so the discount is pure profit. The service also posted outage notices on its Telegram channel, which Google believes reflect key revocations by victims.

Google also describes a containerized backdoor built on the Manus agent framework, with SearXNG metasearch and a sandbox environment. That shows attackers are now using agent tooling for their own operations, not only stealing access to it.

What is confirmed and what is not

Indicators of compromise, including the two Mixer domains, are available to registered users in a Google Threat Intelligence collection on VirusTotal. The numbers above are the report's. We have not reproduced any of the attacks.

Is this new? The earlier record

LLMjacking is not new, but its scale is. Sysdig coined the term in 2024 and estimated that a single abused account could cost a victim more than $46,000 per day on Claude 2.x class inference. A June 2026 research note from the Cloud Security Alliance, LLMjacking Evolves, documented Operation Bizarre Bazaar with about 35,000 attack sessions between December 2025 and January 2026, and a marketplace selling access to more than 30 LLM providers. It also described attackers using a hijacked, unauthenticated Ollama server as the reasoning engine for multi-stage attacks.

Google's report adds three things: dollar totals from real response work, the Mixer resale model with named services, and the persistence and privilege-escalation detail that shows attackers treat a stolen AI key as a foothold into the wider cloud account.

For context on related campaigns, see our coverage of the Volta infostealer that ranks victims by value and the running October 2026 cyberattacks list. A smaller reminder that stolen compute gets used for mining is the Claude Code cryptominer case on a Mac.

What developers on Hacker News are saying

The Hacker News thread was small when we checked, with a single substantive comment. User pentae argued that cloud providers could prevent a lot of this by shipping default budget limits on their AI APIs, and suggested that unintended overspending is part of the cloud business model. That is one commenter's opinion, not a finding in Google's report. Google itself does list granular quotas and spending caps among its recommended mitigations.

How to protect yourself: a checklist

Budget cap lid on a coin jar, illustrating spend limits that stop LLMjacking bills

Google's mitigation list is long. These are the steps that most directly cut dollar exposure, in the order we would do them.

1. Set hard spending caps and per-model quotas. A cap turns a $1 million incident into a small one. Do this at the provider level, not only in a dashboard alert.
2. Alert on LLM service enablement. Google says unauthorized enablement of an LLM service should be a critical security event. On Google Cloud, that means watching the EnableService event for the AI platform APIs.
3. Turn on the right audit logs. Google notes that Data Access logs for model prediction calls on its platform are disabled by default. Without them you cannot see who ran inference.
4. Scope keys narrowly. Separate keys by model, environment and usage limit, so a basic dev key cannot reach a frontier model.
5. Alert on logging changes. Calls that disable model invocation logging by anything other than your infrastructure-as-code pipeline should be treated as high severity.
6. Use phishing-resistant MFA across identity providers, consoles and developer platforms, because pasted session tokens skip ordinary MFA.
7. Scan repositories for secrets and rotate through a central secrets manager.
8. Patch your gateway. If you run LiteLLM, prioritize CVE-2026-40217. Authenticate every self-hosted inference server, including Ollama.
9. Watch for tiny probes. Requests with max_tokens=1 or zero-temperature pings from unfamiliar identities are a sign of key validation.
10. Review service accounts regularly. Look for names that sound like helpful utilities but were created recently.

AI agents that call cloud APIs on your behalf widen this risk, because they hold keys and act fast. AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions. For the same threat from the key-theft side, see AgentBeam's write-up on stolen keys on AI developer platforms.

What this means for what you build or pay

If you ship anything on a cloud model, your bill is now an attack surface. Three practical consequences follow.

• Budget controls are security controls. Treat quotas and caps as part of your threat model, not a finance feature.
• Test your detection against low-volume abuse. Volume-only alerts miss the validation phase.
• Inventory your gateways and keys. Every proxy, notebook, CI variable and repo is a possible source. Our October 2026 incident tracker shows how often credentials are the weak point.

Google expects the trend to continue. Its assessment is that the specialization between access brokers and Mixers "will sustain a growing illicit resale marketplace," and that attackers will increasingly favor LLMjacking over cryptojacking because the money arrives faster.

Related reading

• Railway hack and the OpenRouter breach claim: stolen AI API keys
• Symantec's Skynet Mode LLMjacking agent
• LiteLLM 1.107.0 PyPI compromise: what to do
• Volta infostealer ranks victims by worth
• October 2026 cyberattacks list
• Claude Code found an XMRig cryptominer on a Mac
• Primary source: Google Cloud Threat Intelligence blog

Details are accurate as of November 3, 2026. Figures come from Google's report and may be revised as more incidents are disclosed.