Mandiant Finds LLMJacking Turning Stolen Cloud Access Into Resale Revenue

Compromised cloud access can become a resale business for AI services, with the victim paying for customers it never authorised. Google Threat Intelligence Group and Mandiant’s report, published on 2 November, describes multiple LLMJacking incidents investigated during 2026, rather than a single newly discovered breach.

Mandiant says fraudulent resource consumption exceeded $100,000 in one day in individual incidents, while cumulative charges at some organisations reached $1 million before access was revoked. Those are observed cases, not a typical loss estimate.

Stolen or exposed cloud credentials, active session tokens and model API keys supplied access; publicly exposed model endpoints were another route. GTIG describes illicit routing gateways, called LLM Mixers, that combine and resell unauthorised access. In one investigation, separate clusters handled compromise and monetisation.

The report recommends tightening identity permissions, scanning code for secrets, monitoring unauthorised model-service enablement and watching low-volume credential tests as well as usage spikes.

A budget notification is not necessarily a spending limit

Google’s Cloud Billing documentation makes an important distinction for teams assessing that financial exposure: an alerts-only budget sends notifications but does not automatically cap service usage or charges. An email threshold can flag a problem without stopping it.

Separate spend-cap budgets can pause selected eligible services in a project when estimated gross spending reaches the threshold. Availability is limited, and reporting latency can still leave overage costs. Teams therefore need to check the controls supported by their particular service rather than assume a billing alert enforces a hard ceiling.

Check which activity your logs actually record

The Data Access audit-log guidance also separates administrative visibility from resource-use visibility. Most services do not enable Data Access logs by default, so administrators must explicitly configure them where needed. Admin Activity audit logs are enabled automatically.

Enabling the relevant data logging can increase log volume and costs, and access to private logs requires appropriate permissions. Reviewing those settings before an incident helps establish whether investigators can reconstruct resource access rather than merely see management changes.

Latest articles

Related articles