LLMjacking at Scale: Google and Mandiant on Stolen LLM Access, LLM Mixers and Gateway Abuse

Stolen access to paid language models is now a resale business, and the bill lands on the victim. On November 3, 2026, Google Threat Intelligence Group (GTIG) and Mandiant published LLMJacking: Monetizing Compromised Cloud Models, based on multiple 2026 incident responses. They report fraudulent charges above $100,000 in a single day and cumulative charges up to $1 million at some organisations before access was cut off. If your coding agents run on cloud accounts or API keys, the keys are the asset being hunted.

What did GTIG and Mandiant find?

The report's core claim is that LLMjacking, the hijacking of enterprise LLM access for resale or personal use, is displacing cryptojacking as a quick-profit play. Unlike a miner that drains a server slowly, premium model inference can burn through a budget in hours. GTIG notes that in several incidents the victim had not enabled LLM services at all before the compromise: the attacker turned them on with abused access keys.

The ecosystem has a division of labour. One group gains initial access. Another runs what GTIG calls LLM Mixers, routing gateways that proxy, aggregate and resell unauthorised model access to underground subscribers. Named examples in the report:

• UNC6993 compromised a cloud instance through a misconfigured service-account key, ran a session-hijacking phishing page, and used open-source tools (new-api, gcli2api) to pool stolen keys and sell access.
• Jet Night (jet-night.com), a token-routing service whose unlimited plan cost about $60 a month against a market range GTIG puts at $100–$250. GTIG believes it relies on stolen keys; its outages on Telegram likely reflect key revocations. One victim had nearly $1 million in token costs passed on by this service.
• Custom relay infrastructure ("ai-relay") on lookalike domains, draining corporate quotas into the newapi[.]pro resale ecosystem.
• D1337-KAIROS, a persona that rebranded frontier models behind reverse proxies and deployed a containerised backdoor built with the Manus agent framework.

The only indicators published openly are jet-night.com and newapi.pro; more are in a GTI collection for registered users.

How does the attack chain run?

1. Initial access

GTIG describes stolen cloud identity material as the dominant vector: IAM credentials, service-account keys, GitHub personal access tokens, federation tokens and session tokens. Other routes include exposed LLM endpoints, such as Ollama's /api/create, which attackers used to register their own models, and a fake application portal that tricked users into pasting raw JSON containing active access tokens. Reused session tokens bypass fresh password and MFA checks. API keys were also harvested from public GitHub repositories. (For how large that exposure is, see 26,400 live cloud AI credentials found in public repos.)

2. Quiet key validation

One group tested keys with requests using max_tokens=1. That is a near-free call that proves the key works while staying under the volume thresholds that EDR and SIEM rules usually watch. A spend alert would not see it.

3. Lateral movement and persistence

After landing, actors cloned repositories to hunt for hard-coded secrets, queried data-warehouse metadata for admin passwords, and used token-creation privileges to mint temporary credentials for high-privilege service accounts before pulling secrets from secret managers. For persistence they created IAM accounts with full admin rights, attached admin policies to service roles, disguised backdoor service accounts as "billing optimization utilities" and injected SSH keys into VM host configuration or instance metadata.

4. Gateway privilege escalation

A follow-on cluster used virtual keys obtained from the initial-access actor and, according to GTIG, exploited a user-ID rebind flaw in the /key/regenerate endpoint of LiteLLM, tracked as CVE-2026-40217, to elevate ordinary virtual keys to PROXY_ADMIN master credentials.

One caution: Beam's CVE database lists CVE-2026-40217 as a different LiteLLM flaw, a sandbox escape in the /guardrails/test_custom_code endpoint fixed in 1.83.10 or later (Beam CVE page, LiteLLM tool page). That record says nothing about /key/regenerate. We cannot reconcile the two from the sources we read, so treat the ID as unresolved. Either way, run a current LiteLLM release; our earlier posts on a LiteLLM salt-key reuse path to proxy admin and the compromised litellm 1.107.0 release show why a gateway holding every provider key is a high-value target.

5. Monetisation and "burn and rotate"

With access, actors generate more API keys, enable managed generative-AI services in victim projects, subscribe accounts to pay-as-you-go agreements and run high-volume inference on premium models. They repeatedly create and delete short-lived service accounts to dodge rate limits, watch billing to gauge impact, provision GPU instances across regions and request quota increases through APIs. Some hosted LiteLLM gateways on external servers to route traffic.

What this means if you run AI coding agents

Coding agents are heavy API-key consumers, and the keys sit in environment variables, .env files and shell history that the agent can read. Concretely:

1. One key per agent and environment, with a budget. GTIG recommends segmenting keys by model, environment and usage limits so a leaked utility key cannot invoke frontier models. Set per-model quotas and spend caps.
2. Alert on enablement, not just spend. Treat unexpected activation of an AI service as a critical event. GTIG names these signals: on AWS, bedrock.amazonaws.com events such as InvokeModel, Converse, ListFoundationModels, PutUseCaseForModelAccess, CreateFoundationModelAgreement and changes to logging configuration; on Azure, Microsoft.CognitiveServices operations such as accounts/deployments/write and Microsoft.Insights/diagnosticSettings changes; on GCP, ServiceUsage.EnableService for AI Platform services.
3. Turn on the logs. On GCP, inference calls (PredictionService.Predict, GenerateContent, StreamGenerateContent) are Data Access logs, which are disabled by default. Enable them. Flag attempts to disable model-invocation logging outside infrastructure-as-code as high severity.
4. Watch for tiny requests. Alert on anomalous low-volume calls such as max_tokens=1.
5. Revoke thoroughly. Revoking the first stolen key is not enough: look for new access keys, new admin users, SSH keys added to metadata and service accounts named like billing tools.
6. Scan for keys. Use secret scanning on repositories and rotate anything exposed. Our post-vendor-breach rotation runbook is a practical checklist.
7. Patch and inventory gateways. Include LLM proxies like LiteLLM in vulnerability management, and look for shadow LLM endpoints (an open Ollama is the example GTIG gives).

This is the same family as the Wiz CIRT case where attackers charged Gemini usage to a victim's billing account, and the Symantec report on agents scanning for exposed AI endpoints.

How Beam handles this

Beam does not watch cloud audit logs or billing, so it cannot detect the account-side activity above. What it does cover is one upstream leak: on your own machine it watches what Claude Code, Codex and similar agents read and run, flags credential exposure, and redacts known key formats before anything is stored, all on-device. Workspace policy can deny risky tool calls through Claude Code and Codex PreToolUse hooks. The limits: the deny is hook-based, not a kernel sandbox, and it does not see keys already in a public repository or a phished session token. Pair it with cloud-side monitoring (how it works).

What is not in the report

GTIG does not name victims, give a count of affected organisations, or say how many of the incidents involved a coding agent as the leak path. The report describes sources (public repositories, phishing portals, misconfigured service-account keys) rather than ranking them. It also does not publish the full indicator set; the extra IOCs sit behind a registered-user collection. Read the numbers as examples of what happened in the incidents Mandiant handled, not as a measure of the whole market.

Two practical questions follow for any team. First, if a key for one of your agents were validated tonight with a single-token request, would any alert fire? Most spend-based alerting would not. Second, if an attacker enabled an AI service in a project that never used one, who would be paged, and how quickly? In several of the reported incidents that enablement was the first and only early signal, and the report's advice to treat it as a critical event is the cheapest control on this list. Teams that already export cloud audit logs to a SIEM can add the event names above as rules in an afternoon.

If you do find abuse, remember the persistence section of the chain: rotating the stolen key closes only the door the attacker used first. Sweep for new users, keys, service accounts and metadata SSH entries before you declare the incident over.

What to take away

The notable shift is commercial. Stolen keys have a market, with subscription pricing and outage chatter, which means the incentive to find your key does not depend on your data being valuable. The defences are unglamorous: narrow keys, hard budgets, logs that are actually on, alerts for the first enablement of anything AI, and a gateway that is patched.

Frequently asked questions

What is LLMjacking?

LLMjacking is the hijacking of an organisation's access to large language models, through stolen cloud credentials or API keys, so the attacker uses or resells the capacity while the victim pays. Google says it can produce large cost spikes within hours, unlike the slower drain of cryptojacking.

How big were the losses?

Google and Mandiant report charges above $100,000 in a single day in some 2026 incidents and cumulative charges up to $1 million at some organisations before access was revoked. One actor made more than 500,000 API calls in under eight hours.

What is an LLM Mixer?

It is GTIG's term for an illicit routing gateway that proxies, aggregates and resells unauthorised LLM access to underground subscribers, often built on open-source tools such as new-api and gcli2api.

Why does max_tokens=1 matter?

Attackers validated stolen keys with requests that ask for a single token, which costs almost nothing and stays below volume-based alert thresholds. Alert on those tiny probing requests, not only on spend.

What does CVE-2026-40217 have to do with it?

GTIG says a follow-on cluster exploited a LiteLLM flaw tracked as CVE-2026-40217 to turn ordinary virtual keys into PROXY_ADMIN credentials. Beam's CVE database describes that identifier differently, so check the advisory and your LiteLLM version.

How do I reduce the risk for my coding agents?

Give each agent its own scoped, budget-capped key, keep keys out of repositories and agent-readable files, enable model-invocation logging, alert on new LLM service enablement, and patch any LLM gateway you run.

Related reading

• Wiz: LLMjacking via billing accounts
• Symantec: Skynet mode and exposed AI endpoints
• Black October: Wiz and stolen developer-platform keys
• November 2026 attacks timeline
• Sources: GTIG and Mandiant report; GHSA-wxxx-gvqv-xp7p

Figures and names are as published by GTIG and Mandiant on November 3, 2026, and may be revised. Beam is a local prototype; check current docs before relying on any feature described here.