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 #
| Question | Answer |
|---|---|
| Who published it? | Google Threat Intelligence Group and Mandiant, on the Google Cloud blog |
| What is new? | Named "LLM Mixers" that resell stolen access, plus concrete loss figures |
| Biggest numbers | More than $100,000 in one day; up to $1 million in total; 500,000+ API calls in under eight hours (Jet Night) |
| Who was hit? | Unnamed firms in North America, South America and Asia Pacific (finance, retail, tech, transport) |
| Main entry point | Stolen cloud identity tokens, service account keys, GitHub tokens and session tokens |
| Named actor | UNC6993, tracked by Google, with more than $100,000 in billing charges attributed to it |
| Named CVE | CVE-2026-40217, a LiteLLM /key/regenerate flaw that lets a standard key become a proxy admin |
| What to do | Hard spend caps, narrow key scopes, MFA that resists phishing, alerts on LLM service enablement |
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/createendpoint 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:
- Mapped the environment across cloud regions to learn services and identity policies.
- Hunted for more secrets by cloning codebases, scanning access logs, and querying data warehouse metadata tables for database credentials and admin passwords.
- 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.
- 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."
- 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.
- 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.
| Piece | Role in the ecosystem |
|---|---|
| jet-night.com | Token routing service built on stolen third-party keys; passed nearly $1 million in token costs to one victim |
| newapi.pro | Resale ecosystem that drained victim quotas to serve underground customers |
| new-api, gcli2api, LiteLLM | Open-source gateway and conversion tools that UNC6993 and others used to aggregate keys and expose them as standard endpoints |
| D1337-KAIROS | A persona that hosted public reverse proxies and custom Node.js proxy bundles exposing several frontier models |
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 #
| Claim | Status |
|---|---|
| Charges above $100,000 in one day in individual incidents | Stated by Google GTIG and Mandiant; victims unnamed, not independently audited |
| Up to $1 million in cumulative charges | Stated by Google; no invoice or victim statement published |
| 500,000+ calls in under eight hours by Jet Night | Stated by Google |
| Jet Night passed nearly $1 million in token costs to one victim | Stated by Google; the service's own records are not public |
| CVE-2026-40217 in LiteLLM | Named by Google; check the vendor's advisory for patched versions |
| Which cloud and model vendors were affected | Not disclosed |
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.
- 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.
- 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
EnableServiceevent for the AI platform APIs. - 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.
- Scope keys narrowly. Separate keys by model, environment and usage limit, so a basic dev key cannot reach a frontier model.
- 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.
- Use phishing-resistant MFA across identity providers, consoles and developer platforms, because pasted session tokens skip ordinary MFA.
- Scan repositories for secrets and rotate through a central secrets manager.
- Patch your gateway. If you run LiteLLM, prioritize CVE-2026-40217. Authenticate every self-hosted inference server, including Ollama.
- Watch for tiny probes. Requests with
max_tokens=1or zero-temperature pings from unfamiliar identities are a sign of key validation. - 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. OurOctober 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 #
Details are accurate as of November 3, 2026. Figures come from Google's report and may be revised as more incidents are disclosed.