Summary
- Google has formally named and warned against ‘LLMjacking’ — the theft and abuse of enterprise LLM API keys to fraudulently consume AI computing resources.
- Attack vectors include phishing, source code leaks, misconfigured cloud environments, and exposed client-side code.
- Financial exposure can reach approximately $1 million in unexpected cloud charges for a single compromised organisation.
- The technique is a modern adaptation of classic cloud resource hijacking, now targeting the high compute costs associated with LLM inference.
- Enterprises using third-party or cloud-hosted AI services are in scope, not just those building their own models.
A familiar attack, new economics
Resource hijacking is not a new concept in cloud security. Attackers have long compromised cloud credentials to mine cryptocurrency, run spam campaigns, or spin up compute infrastructure at a victim’s expense. LLMjacking follows the same logic, but the economics have shifted dramatically. AI inference — running queries against large language models — is computationally intensive and priced accordingly. Where a rogue cryptocurrency miner might cost a business tens of thousands of dollars before detection, an attacker with unfettered access to an enterprise’s LLM API can generate charges approaching $1 million, according to Google’s warning issued this week.
How attackers gain access
Google identified several entry points that threat actors are exploiting to obtain valid API keys. Phishing remains a reliable standby, targeting developers and engineers who hold legitimate credentials. Source code repositories — particularly public or poorly secured ones — are another significant source, with API keys inadvertently committed alongside application code. Misconfigured cloud environments expose credentials that should never have been accessible externally. Client-side code is also a vector: applications that embed API keys directly in front-end code hand those credentials to anyone who inspects the source. None of these are novel weaknesses, which is precisely what makes the attack surface so broad.
What attackers do with access
Once a valid API key is in hand, an attacker can query the victim’s AI service as though they were an authorised user. The source material does not specify exactly what attackers are using this access for — whether reselling inference capacity to others, running large-scale automated tasks, or something else — but the financial impact is the clearest indicator of the scale of consumption. The victim organisation receives the bill; the attacker receives the benefit.
Who is exposed
Any enterprise that has integrated a cloud-hosted or third-party LLM service into its operations holds credentials that are potentially valuable to this class of attacker. This is not limited to organisations building proprietary AI products. Businesses using AI APIs for customer service automation, internal tooling, document processing, or any other operational function are equally in scope. The broader the adoption of AI services — and adoption is accelerating — the larger the aggregate attack surface becomes.
Detection is a known challenge
One structural problem with this threat is that legitimate and malicious API usage can look identical at the network and application layer. Without anomaly detection tuned to consumption baselines, organisations may not discover the abuse until a billing alert fires or an invoice arrives. Cloud providers typically offer cost and usage monitoring, but those controls need to be actively configured and thresholds set at meaningful levels. Corroborating coverage from BleepingComputer confirmed the $1 million figure and the Google advisory, but neither source provided detail on how long typical compromises persist before discovery.
Why it matters
For CISOs, LLMjacking represents a convergence of credential hygiene failures and AI adoption risk that can produce direct, measurable financial harm — not a hypothetical future breach but an immediate, operational cost. As AI service spend enters enterprise budgets and procurement, the API keys governing that spend become high-value targets. Security teams that have not yet classified LLM credentials as privileged secrets requiring the same controls as cloud IAM keys should do so now. The reputational and operational dimensions of a seven-figure surprise bill also create board-level exposure that security leaders will need to explain.
What to do now
- Audit all LLM and AI service API keys across your environment — including those embedded in source code repositories, CI/CD pipelines, and client-side applications.
- Rotate any API keys that may have been exposed in source code, public repositories, or misconfigured environments.
- Apply least-privilege principles to AI service credentials: restrict keys to specific services, IP ranges, or usage patterns where the provider supports it.
- Configure cloud cost and usage alerts for AI services at thresholds that would surface anomalous consumption before charges become significant.
- Include AI API keys in your secrets management programme and enforce scanning of code repositories for inadvertently committed credentials.
- Review environment configurations for any AI-related services that may expose credentials through misconfiguration or insecure defaults.
