Google: hackers ran up $100,000 a day on stolen cloud AI keys. What a small business should lock down

Google's Threat Intelligence Group (GTIG) and Mandiant published a report on Nov. 2 describing a fast-growing kind of cloud theft they call LLMjacking: attackers take over a company's cloud or AI-model credentials and use the victim's account to run large language models, then bill the victim. The report draws on Mandiant incident responses in 2026 across North America, South America and Asia Pacific, in financial services, retail, technology and transportation.

The headline numbers are large, and the report is clear about what they are. Fraudulent charges "exceeded $100,000 USD in a single day" in individual incidents, and at some organizations the total reached $1 million before access was revoked. Both are specific cases, not averages. SiliconANGLE reported the same figures. XenoSpectrum notes that Mandiant did not disclose how many incidents there were, how the amounts were calculated or over what periods, so no one can derive a typical loss from them.

How the theft works

Google says the dominant way in was "exposed or stolen cloud identity tokens": IAM credentials, service account keys, GitHub personal access tokens and live session tokens. Other attackers went after internet-exposed model servers, such as Ollama instances, or harvested API keys left in public code repositories. In one case a threat actor tracked as UNC6993 used a misconfigured service account key in mid-2026 to reach an LLM API, and also hosted a fake application portal that tricked users into pasting raw JSON containing active tokens.

The detail most relevant to a small firm is this: in several Mandiant cases, the victim had never turned on any AI service. The attacker used stolen keys to enable services such as Amazon Bedrock and the Gemini API, then generated large bills "in just minutes or hours." Not using AI did not protect those accounts.

To avoid tripping alarms, attackers ran validation sweeps of single-token requests (max_tokens=1) to test which stolen keys still worked. Others created and deleted short-lived service accounts to dodge rate limits, and some used cloud federation tokens to generate fresh keys that, in Google's words, circumvent MFA requirements.

Where the stolen access goes

The report describes a resale market. "LLM Mixers" pool stolen credentials, meter usage and hide where requests come from. One service, Jet Night, offered an unlimited plan for roughly $60 a month, against $100 to $250 a month for comparable consumer plans. GTIG believes it "relies on stolen keys to operate profitably." One actor made more than 500,000 API calls in under eight hours through it, and the report says the service passed nearly $1 million in token costs to a victim. Its Telegram channel advertised outages that GTIG thinks were caused by key revocations.

Google expects criminals to "increasingly prioritize LLMjacking over traditional resource theft like cryptojacking," because the money is immediate and the margin high. Cryptojacking drains resources slowly. LLMjacking can produce a spike in hours.

One caution on the technical detail: Google cites a LiteLLM flaw, CVE-2026-40217, that let attackers raise ordinary virtual keys to administrator level. XenoSpectrum reported on Nov. 3 that it could not match that number to a vulnerability registered under it. If you run LiteLLM or a similar model gateway, check the vendor's own advisories rather than relying on the CVE number alone.

What a small business should do this week

The report is aimed at security teams, but most of its mitigations translate directly to a company with one cloud account and no security staff. Everything below comes from Google's recommendation list, ordered by cost and effort.

1. Set a budget alert and a spending cap on every cloud account. Google recommends granular API quotas per model and spending caps. A billing alert is the one control that catches this kind of theft whatever the entry point, and it is free on the major clouds.
2. Turn on phishing-resistant MFA for every cloud console, identity provider and developer platform such as GitHub. Passkeys and hardware keys count; text-message codes are weaker.
3. Find and delete long-lived keys. List service account keys, IAM access keys and personal access tokens. Remove the ones nobody can explain, and rotate the rest. Google recommends a central secrets store with automated rotation.
4. Search your code for secrets. Turn on secret scanning in GitHub or GitLab. Keys pasted into code or public repositories are a named entry point.
5. Deny AI permissions by default. Google's advice is to deny everything not explicitly required, "including access to Cloud LLM services." If nobody in the business uses a cloud AI service, nothing should be allowed to enable one.
6. Treat any unexpected enablement as an incident. The report says to handle unauthorized service enablement as a critical security event. Alert on a new AI service being switched on, new service accounts or access keys, and changes to logging.
7. Scope your keys. If you do use AI APIs, use separate keys for each model and for development versus production, each with its own limit.
8. Patch and fence any AI gateway you run. Self-hosted model servers and proxies should not be reachable from the open internet without authentication, and belong in your normal update routine.

Logging matters too. Google notes that on its own cloud, model-inference calls are recorded only if Data Access audit logs are enabled, and they are off by default. Without them, the bill is the first sign. The report lists the specific log events to watch on AWS (Bedrock via CloudTrail), Azure (Cognitive Services) and Google Cloud (Vertex AI platform), including attempts to switch off model-invocation logging.

If the bill arrives first

The report's lesson for response is speed: charges build in minutes to hours, so revoke the suspect key first, then investigate. Disable or delete the exposed credential, check for new users, service accounts and SSH keys that the attacker may have left behind, and contact your cloud provider's billing and security teams. Google describes attackers who add backdoor accounts, including ones "disguised as internal billing optimization utilities." Whether a provider will credit fraudulent usage is a matter for your agreement and the provider; the report does not address it, and we did not find a published policy to cite.

For wider context on AI risk landing on company balance sheets, see our coverage of uninsurable AI risk and of CrowdStrike's new control for rogue AI agents.

Sources: Google Cloud Blog, Google Threat Intelligence Group and Mandiant, Nov. 2, 2026; SiliconANGLE, Nov. 2, 2026; XenoSpectrum, Nov. 2026. Figures are as reported by Google; the amounts are specific incidents, not averages. This is general security information, not professional or legal advice.