LLMJacking: a $100,000-a-day bill from stolen keys

You have built generative AI APIs into business apps and internal tools. You manage the keys as service accounts and API keys. If just one of those keys leaks, even model services you were not using can be enabled, and a large bill can arrive within hours.

On November 2, 2026, Google Threat Intelligence Group (GTIG) and Mandiant published a report on Google Cloud's official blog that describes this kind of damage as "LLMJacking." According to the report, in multiple incidents Mandiant handled in 2026, fraudulent charges exceeded $100,000 in a single day, and at some organizations the cumulative total reached $1 million before access was cut off. This article sorts out the attack flow described in the report and the monitoring and limits to set up in advance in Google Cloud.

How it differs from cryptocurrency mining

The report describes LLMJacking as "a technique for hijacking access to an enterprise's large language models (LLMs)." The incidents affected organizations in finance, retail, technology, and transportation across North America, South America, and Asia-Pacific, and spanned multiple clouds and LLM providers.

The technique of stealing cloud compute resources to mine cryptocurrency (cryptojacking) uses resources little by little. LLMJacking differs, the report says, in that it drives bills up sharply within hours. Beyond using the stolen quota themselves, a division of labor has also been observed in which attackers bundle it through a relay system called an "LLM Mixer" and resell it to underground users.

The entry points: "exposed endpoints" and "stolen keys"

The report lists two kinds of entry points.

The first is LLM endpoints left exposed without authentication. In a figure in the report, an attacker calls /api/create on an exposed Ollama endpoint and tries to register their own model.

The other, which the report calls the "main entry point," is the theft of cloud credentials. It lists IAM credentials, service account keys, GitHub personal access tokens (PATs), and valid session tokens. The following techniques are described as examples.

• Entering a cloud instance through a misconfigured service account key and adding permissions to the LLM API (UNC6993)
• Using a page posing as a portal for joining an LLM user group to lead victims to the legitimate LLM site and have them paste JSON containing a valid access token, bypassing passwords and multi-factor authentication (UNC6993)
• Entering private repositories with a stolen PAT, combined with exploitation of a vulnerability (described as "suspected" in the report) in a packaged web app running in a container environment
• Creating new access keys with a federation token, bypassing multi-factor authentication

LLM API keys themselves are also targeted. One reported technique harvests enterprise API keys from public GitHub repositories and checks whether they are valid with minimal max_tokens=1 requests. The report points out that because the request volume is low, this is unlikely to trip monitoring that looks for volume anomalies.

Spreading after getting in and running up the bill

After intrusion, attackers look for other keys and widen their permissions. According to the report, activity included cloning repositories to find hardcoded secrets, searching data warehouse metadata tables for passwords, and using token-creation permissions to create temporary credentials for higher-level service accounts and take external API keys out of secret vaults.

As a path specific to AI apps, vulnerabilities in LiteLLM, a gateway that consolidates multiple model APIs, have also been used. The report cites a case in which a vulnerability in the /key/regenerate endpoint was used to elevate an ordinary virtual key to PROXY_ADMIN administrator credentials.

However, the number the report assigns to this vulnerability, CVE-2026-40217, does not match public records. In NVD and the LiteLLM advisory (GHSA-wxxx-gvqv-xp7p), this number refers to a different issue that allows escaping the /guardrails/test_custom_code sandbox to execute code. As of November 6, 2026, we found no advisory describing the privilege escalation via /key/regenerate. Do not judge whether you are affected by the CVE number alone; compare the list of LiteLLM advisories against the version you use.

The following activity was reported in the monetization stage.

• Creating additional API keys in the victim's project and trying to enable related services. Through this activity, UNC6993 ran up more than $100,000 in charges in a short time
• Signing up for pay-as-you-go plans and running large volumes of inference on top-tier models. To avoid rate limits, repeatedly creating and deleting short-lived service accounts
• Running token relay services with stolen keys. One attacker made more than 500,000 API calls in under 8 hours, passing nearly $1 million in token costs on to the victim organization

The report says that in multiple incidents Mandiant investigated, LLM services were not enabled at the time of the compromise. Not using a service does not make you safe; a service you do not use suddenly being enabled must itself be treated as a serious sign.

Logs to watch in Google Cloud

The report lists operations to monitor on each of AWS, Azure, and Google Cloud. On Google Cloud, calls to Gemini Enterprise Agent Platform (formerly Vertex AI, aiplatform.googleapis.com) are monitored in Cloud Audit Logs. The catch is that inference operations fall under "Data Access" audit logs, which are disabled by default because of their volume and ingestion cost. You must enable them manually in the IAM audit policy. The Cloud Audit Logs documentation also says that Data Access audit logs are disabled by default, except for BigQuery.

The right column is what we confirmed in each service's audit log documentation on November 6, 2026. The report explicitly says "Data Access logs are required" only for running models, but operations that read the model list or log settings fall under the same type of log and are not kept by default.

Some operation names in the report do not match the notation in the documentation. The Agent Platform list shows forms such as endpoints.predict, endpoints.rawPredict, models.list, and endpoints.list, and we could not find GenerateContent, StreamGenerateContent, or ListPublisherModels. After enabling the logs, make one test call and confirm the methodName actually recorded before creating alert conditions.

The Gemini API (generativelanguage.googleapis.com) used from Google AI Studio and elsewhere is a separate service. We could not find it in the list of services supported by Cloud Audit Logs, so for projects that use this API, check separately what records are kept.

For AWS, the report says to watch execution such as Bedrock's InvokeModel, surveying such as ListFoundationModels, model unlocking such as CreateFoundationModelAgreement, and changes to or deletion of invocation logging settings. It asks that operations by principals other than IaC that stop log recording be treated as high severity. For Azure, it says to watch the creation of Microsoft.CognitiveServices deployments and changes to diagnostic settings.

Preventive measures to set up in advance

From the report's recommendations, here are the ones that are easy to turn into settings and operations for systems with built-in AI APIs.

• Centralized management and rotation of secrets: Automate key storage and rotation to shorten the period a leaked key can be used
• Least privilege: Deny permissions a role does not need. Include access to LLM services
• Scanning code for secrets: Automatically find and remove API keys in code on GitHub, GitLab, and similar platforms
• Budgets and limits: Set fine-grained API quotas per model, and prevent overuse with spending limits
• Phishing-resistant multi-factor authentication: Apply it to cloud management consoles and development platforms
• Splitting API key scope: Separate keys by model, environment (development/production), and usage so that keys for cheaper models cannot call top-tier models
• Monitoring verification calls: Watch gateway and API logs for small, unnatural requests such as max_tokens=1
• Updating gateways: Include relay software such as LiteLLM in vulnerability management

We covered setups that avoid distributing service account keys in the article on keyless Workload Identity integration, and the decision to place a gateway in the article on internal AI gateways. For checking for the tampered version of LiteLLM, see the article on LiteLLM 1.107.0.

The editorial team's proposal: three things to check first

Because the report lists many monitoring and prevention items, we present, as the editorial team's proposal, the order in which organizations using Google Cloud should start.

1. Alert on service enablement in projects that do not use generative AI. The report names EnableService as an alert target and describes incidents where services "were not enabled at the time of the compromise." According to the Service Usage documentation, this operation is recorded in Admin Activity audit logs, which are always written. The record is kept even if Data Access logs are not enabled. BatchEnableServices, which enables multiple services at once, falls under the same type of log, so include it as well (the editorial team has not tried the alert configuration itself)
2. In projects that use generative AI, decide the scope and cost of Data Access audit logs. They are disabled by default, so inference calls are not kept unless you enable them. Cloud Logging ingestion costs $0.50 per GiB, with the first 50 GiB per project free each month (pricing page as of November 6, 2026). Data Access logs go to the _Default bucket by default, and the default retention period is 30 days. Estimate the cost from your call volume and decide the retention period at the same time
3. Take inventory of your keys. For service account keys, LLM API keys, and GitHub PATs, list who created them, where they are kept, and which models and environments they can be used for, and delete the ones you do not need

Budget alerts and spending limits are means of containing the amount after damage has occurred. They do not replace detection, so set them up together with item 1.

Regular Google Cloud budgets only send notifications and do not stop usage. To stop usage, use a Cloud Billing budget with a spending limit (spend cap budget). It covers the Gemini API, Gemini Enterprise Agent Platform, Cloud Run, and Cloud Run functions, and is set monthly for one service in one project. If the limit is exceeded, new usage of that service stops until the end of the month unless you manually lift it. The documentation says it does not take effect immediately and that overages are billed. Because this can also stop production services, decide the limit amount in advance with the people responsible for the business. We covered what stops and the order of adoption in the article on spending limits.

Scope of verification

On November 3 and 6, 2026, we directly retrieved the GTIG and Mandiant report "The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources" on Google Cloud's official blog (the feed data gives a publication date of November 2, 2026, and the page shows November 3), and checked the figures, techniques, operations to monitor, and recommendations in the text against the original (document research). Damage amounts and case counts are values for the incidents described in the report, not industry-wide statistics. On November 6, we also checked the documentation on audit logs, pricing, and spending limits, as well as the NVD record for CVE-2026-40217 and the LiteLLM advisory. We have not been able to confirm the affected and fixed versions for the /key/regenerate vulnerability, or why the report's number differs from public records. We have not tested the monitoring configuration or spending limits.

For reviewing the permissions and monitoring of systems with built-in AI APIs, please contact us through Development, AI, and automation consultations.

References

• The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources（Google Cloud Blog、2026-11-02）
• Cloud Audit Logs overview（Google Cloud）
• Agent Platform audit logging information（Google Cloud）
• Service Usage audit logging（Google Cloud）
• Manage spend cap budgets（Google Cloud）
• Google Cloud Observability pricing
• CVE-2026-40217（NVD）
• GHSA-wxxx-gvqv-xp7p（GitHub Advisory Database）