LLMJacking turns stolen cloud credentials into six-figure bills

LLMJacking belongs in the same incident category as ransomware or a compromised production administrator account: it is a security breach with an immediate commercial blast radius. Google and Mandiant documented cases where fraudulent model and cloud use passed US$100,000 in a day and, in one case, neared US$1 million before access was stopped. The first job is to halt the burn rate. The next is to find out whether the stolen identity opened doors beyond expensive AI usage.

Google uses LLMJacking to describe attackers taking control of large language model (LLM) capacity, model application programming interface (API) keys or the cloud identities able to create and use them, then consuming or reselling that capacity. Cryptojacking usually steals compute quietly and gradually. LLMJacking can turn one exposed key, an over-privileged service account or a hijacked session into premium inference traffic, graphics processing unit (GPU) provisioning and a resale operation in a matter of hours. The unfamiliar part is not the intrusion technique. It is how quickly the invoice becomes evidence.

What is confirmed — and what is not

Google’s 2 November 2026 report describes multiple Mandiant responses across North America, South America and Asia-Pacific, affecting organisations in financial services, retail, technology and transport. The activity involved several cloud and LLM providers, not Google Cloud alone. The report identifies exposed or stolen identity and access management (IAM) credentials, service-account keys, GitHub personal access tokens, active session tokens and LLM API keys as initial-access routes. (cloud.google.com)

It does not point to one universal flaw in Gemini, Vertex AI or Google Cloud that customers can remedy by installing a particular version. No affected or fixed Google Cloud product versions have been published because LLMJacking is an abuse pattern, rather than a single Common Vulnerabilities and Exposures (CVE)-led defect. That is an important distinction. Updating a library may be necessary in an individual environment, but it will not revoke a leaked key, repair permissive IAM policy or eject an attacker holding a valid federated session.

There is one technical detail that deserves caution. Google’s report links a LiteLLM gateway privilege-escalation scenario to CVE-2026-40217. The public GitHub advisory for that CVE describes a different issue: a custom-code guardrail sandbox escape affecting LiteLLM versions from 1.81.8 up to, but not including, 1.83.10. The advisory also creates ambiguity by listing 1.83.10 as patched while stating that replacement of the sandbox is fixed in 1.83.11. The cautious operational choice is to use 1.83.11 or later and block the affected custom-code endpoint until then. (github.com)

That inconsistency does not undermine the wider evidence of compromise. It does mean that teams should not assume CVE-2026-40217 explains every LiteLLM-related route mentioned in Google’s report. Check the gateway version, configuration and exposure independently, and preserve evidence before making broad changes.

The attack path is familiar; the billing profile is not

The opening moves resemble a conventional cloud intrusion. An attacker finds a public endpoint, a key committed to a repository, a poorly protected workload identity or a stolen developer credential. Google says exposed cloud identity tokens were the dominant route in its investigations. In one case, access through a misconfigured service-account key was used to grant further access to an LLM API; in others, compromised identities created new access keys or service accounts. (cloud.google.com)

Once inside, the attacker looks for reach. Google describes reconnaissance of repositories, data stores, logs, regions and identity policy, followed by account creation, new keys and Secure Shell (SSH) persistence. That is why revoking a single API key can be necessary without being sufficient. If the key was merely the handle on the door, the investigation has to establish what changed after the attacker entered the project. (cloud.google.com)

The money-making stage is what changes the tempo. Google observed attackers enabling generative-AI services that had not previously been enabled, creating additional keys, choosing premium models, driving high-volume inference, provisioning GPU instances in multiple regions and requesting quota increases. It also describes “LLM Mixers”: illicit proxy services that pool stolen credentials and resell model access to subscribers while victims receive the token bill. One case involved more than 500,000 API calls in under eight hours and costs approaching US$1 million. (cloud.google.com)

For many organisations, the first visible harm will be financial loss and service disruption. The more consequential question is whether the same compromise exposed prompts, retrieved data, code repositories, secrets or connected tools. Google’s public account confirms credential harvesting and data-store reconnaissance in some intrusions, but does not show that every LLMJacking victim lost prompt or model data. That risk should be investigated, not assumed.

Detection: watch for enablement, probes and spend that makes no sense

Most cloud-security teams already monitor impossible travel, administrator creation and obvious traffic spikes. Keep those controls, but view them through an AI-service lens. The signal may arrive before the inference surge: a newly enabled service in an unexpected project, a model access agreement, a new API key, a quota change, an unfamiliar gateway deployment or someone inspecting or altering logging settings.

Google specifically recommends treating unauthorised LLM-service enablement as critical. It also warns that attackers may test stolen keys with minimal requests rather than creating an immediate traffic spike. A tiny, unusual inference request is therefore worth attention when it is followed by identity changes or sudden service enablement. (cloud.google.com)

On Google Cloud, verify that monitoring exists in practice rather than on a diagram. Gemini Enterprise Agent Platform inference activity is recorded in Data Access audit logs, and Google documents that those logs are disabled by default. They must be enabled explicitly, and investigators need appropriate private-log viewing rights. Retaining them has cost and data-governance implications, but an incident plan cannot depend on telemetry that was never collected. (docs.cloud.google.com)

Containment must be decisive, not destructive

Where there is evidence of unauthorised model use, revoke or rotate the exposed credentials, disable unauthorised keys and accounts, and restrict affected services or projects where that can be done without destroying evidence. Freeze non-essential quota changes. If a model gateway is involved, remove public exposure and stop unrecognised proxy routes. Preserve cloud audit, billing, gateway, identity-provider and repository logs before short retention periods erase the timeline you need.

Then follow the compromised principal outward. Review impersonation rights, token-creation permissions, service-account bindings, workload-identity federation, secret-manager reads, source-repository access, newly added SSH keys and infrastructure changes. Any service account able to create keys or impersonate a more privileged account merits immediate scrutiny. AI-agent identity is not an application-team footnote: the identity plane decides whether an AI spend incident remains contained or develops into a broader cloud compromise.

For LiteLLM users, patching belongs in recovery, not in place of recovery. Upgrade beyond the affected CVE-2026-40217 range where applicable, remove unnecessary administrative routes, segregate provider credentials, and confirm that gateway compromise could not expose a master key or every upstream model account. The conclusion is not “avoid gateways”. Properly run, they are useful control points. But they need the patch discipline and access review normally reserved for identity-critical infrastructure.

Prevention is mostly boring cloud security — which is good news

The controls with the greatest value are not exotic AI products. Use centrally managed secrets rather than hard-coded keys; scan repositories and build outputs for credentials; use short-lived workload identity where practical; require phishing-resistant multi-factor authentication (MFA) for human administration; and grant AI-service permissions only to principals that genuinely need them. Google’s mitigation guidance similarly centres on credential hygiene, least privilege, code monitoring, configuration audits, rate limiting, network restrictions and budgets. (cloud.google.com)

None of this is free of trade-offs. Tight egress allow lists, which restrict outbound network destinations, can complicate developer tooling and third-party model providers. Fine-grained key scopes and quotas bring administrative overhead. Comprehensive Data Access logging costs money and can retain sensitive metadata. Those are design choices to manage, not arguments for leaving a production account without meaningful limits. A strong model gateway can reduce credential sprawl if it applies per-tenant authentication, hard usage limits, useful audit trails and prompt revocation.

Organisations building more autonomous workflows should separate authority to call a model from authority to use business systems or create cloud resources. An agent does not need blanket project-owner privileges simply because it can reason about a task. A practical Zero Trust architecture for AI agents sets out that control pattern; LLMJacking supplies a particularly sharp financial reason to implement it.