Google Warns of LLMjacking Attacks Costing Companies Up to $1 Million

Google has warned that cybercriminals are hijacking corporate AI systems and generating unauthorized cloud computing charges that can reach $1 million before companies detect the attacks.

In a security report published on November 2, 2026, Google Threat Intelligence Group (GTIG) and Mandiant revealed a growing cybercrime technique known as LLMjacking.

The attacks target organizations that use large language models (LLMs) through cloud infrastructure, AI APIs, and managed artificial intelligence services.

Instead of attacking AI models to steal their training data, many criminals aim to gain unauthorized access to expensive AI computing resources.

Once inside, they can use the victim’s API keys, cloud credentials, or computing infrastructure to run AI workloads.

The legitimate organization receives the resulting usage charges.

According to Google’s official threat intelligence report, some incidents resulted in more than $100,000 in unauthorized resource charges within a single day.

Other affected organizations accumulated approximately $1 million in charges before the compromised access was revoked.

The attacks have affected organizations in North America, South America, and Asia Pacific, spanning financial services, retail, technology, and transportation.

The central security concern is that stolen machine credentials can provide direct access to expensive cloud services, sometimes without requiring a new interactive login.

Key findings from Google’s LLMjacking investigation

Google’s investigation demonstrates how quickly attackers can monetize stolen access to enterprise AI systems.

What Is LLMjacking and How Does It Work?

LLMjacking is a cyberattack in which criminals obtain unauthorized access to large language model services and use the victim’s computing resources, API quotas or cloud accounts for their own purposes.

The technique is similar in concept to cryptojacking, in which attackers secretly use compromised computers to mine cryptocurrency.

However, LLMjacking targets AI inference and computing resources rather than cryptocurrency mining.

Why LLMjacking can be expensive

Modern AI services often charge customers according to their usage.

For example, an enterprise may pay for:

• The number of input and output tokens processed.
• Requests sent to premium AI models.
• GPU computing resources.
• Hosted inference infrastructure.
• Specialized cloud services.

These expenses are legitimate when generated by authorized applications.

However, if an attacker gains control of the credentials used to access these services, they can generate requests under the victim’s billing account.

High-volume automated activity can accumulate costs extremely quickly.

Google’s investigation found that LLMjacking attacks can produce substantial unauthorized usage within hours, leaving security teams with little time to detect and contain the activity.

Typical LLMjacking attack process

The attack generally follows five stages:

1. Initial access: Criminals locate an exposed AI endpoint or steal valid cloud credentials.
2. Credential validation: They test the stolen credentials to determine which services are accessible.
3. Privilege expansion: Attackers search for additional permissions, API keys, and cloud resources.
4. Resource abuse: They send automated AI requests or deploy unauthorized workloads.
5. Monetization: They resell access to AI services while the legitimate organization incurs the usage charges.

Not every incident includes every stage.

However, Google’s findings show that these activities are becoming increasingly coordinated across multiple criminal groups.

How Hackers Steal AI API Keys and Cloud Credentials

One of the most important findings concerns the initial access methods used by attackers.

Google found that stolen or exposed cloud identity tokens were a dominant entry point across investigated incidents.

Exposed API keys in public repositories

Developers sometimes accidentally include sensitive credentials in application code or configuration files.

If those files are uploaded to a public repository, an attacker may discover the credentials.

For example, an exposed API key could grant access to an organization’s AI model endpoints.

Attackers can use automated tools to search public repositories for these credentials.

Google observed criminals performing low-volume verification requests to determine whether stolen keys were still valid.

Some tests used extremely small token requests to avoid generating enough activity to trigger conventional volume-based monitoring.

Even one exposed API key can create financial risk if it has broad permissions and no effective usage limits.

Developers should therefore avoid storing production secrets directly in source code.

For guidance on protecting repository access, see our GitHub Two-Factor Authentication Guide.

Stolen cloud identity credentials

Not every LLMjacking attack begins with a leaked AI API key.

Google also identified cases involving compromised:

• Identity and Access Management (IAM) credentials.
• Cloud service account keys.
• GitHub personal access tokens.
• Active authentication session tokens.
• Cloud federation credentials.

These credentials may give attackers the ability to discover, activate, or manage additional cloud services.

In one observed incident, a threat actor identified as UNC6993 compromised a cloud instance through a misconfigured service account key.

The attackers used the resulting access to enable additional LLM services.

This allowed them to consume AI resources using the victim organization’s cloud environment.

Session token theft and social engineering

Another documented technique involved a fake application portal designed to capture active authentication tokens.

According to Google, the attackers tricked users into submitting raw authentication information from a legitimate AI service.

Because the stolen material contained an active access token, the attacker could potentially use it without completing the normal password and MFA process.

This illustrates an important difference between password theft and session hijacking.

A stolen authenticated session can sometimes be abused even when an account requires multi-factor authentication for a fresh login.

Organizations should therefore treat active access tokens as highly sensitive credentials.

Exploiting AI infrastructure weaknesses

Google also documented exploitation of security weaknesses within LLM routing infrastructure.

In one investigation, attackers abused CVE-2026-40217, a vulnerability affecting a LiteLLM gateway.

The reported exploitation allowed an attacker to elevate limited virtual-key access to more powerful administrative permissions.

This demonstrates that protecting API keys alone is insufficient.

Organizations must also secure the applications, gateways, and supporting infrastructure that manage access to AI models.

Inside Google’s Investigation: 500,000 AI Requests in Eight Hours

One of the most striking findings involved a criminal operation using stolen third-party API keys.

Google reported that an attacker executed more than 500,000 LLM API calls in less than eight hours.

The stolen credentials were used to support an unauthorized AI routing service identified as Jet Night.

Nearly $1 million in AI token charges

According to GTIG, Jet Night passed almost $1 million in token costs to a victim organization.

The service offered access to premium AI models through an underground subscription system.

Google reported that Jet Night advertised an unlimited-access plan costing approximately $60 per month.

This unusually low subscription price was possible, according to Google’s assessment, because the service appeared to rely on stolen AI credentials rather than paying the full infrastructure costs itself.

The legitimate owners of those credentials were left facing the resulting usage charges.

Why the attack escalated so quickly

The financial damage came from the scale of automated requests.

When an attacker controls a valid API key, requests can appear to the provider as authorized usage.

Without effective monitoring or spending restrictions, thousands of unauthorized requests may continue before anyone identifies the problem.

The attackers may also distribute their activity across multiple compromised accounts.

Google observed techniques involving repeated creation and deletion of temporary service accounts to evade limits and maintain access.

These methods make resource hijacking more difficult to contain.

The reported $1 million figure represents accumulated unauthorized resource charges in investigated incidents. It should not automatically be interpreted as confirmed payments or unrecoverable financial losses.

How Criminals Profit From Stolen AI Resources

Google’s investigation identified a developing criminal marketplace built around unauthorized AI access.

Researchers described intermediary services called LLM Mixers.

What are LLM Mixers?

LLM Mixers are services that aggregate access to AI models using credentials controlled by criminal operators.

Instead of each customer obtaining a legitimate subscription directly from an AI provider, requests are routed through intermediary infrastructure.

The intermediary may rely on stolen credentials or compromised cloud environments.

As a result, customers receive access to AI services while victims bear some or all of the associated computing costs.

Google observed attackers using open-source API gateways and custom proxy systems to route unauthorized requests.

Criminal groups are specializing

Another important finding is the division of responsibilities between attackers.

One group may specialize in obtaining access to corporate cloud environments.

Another may operate infrastructure that converts that access into a commercial service.

This specialization creates opportunities for criminals to monetize compromised AI resources more efficiently.

It also makes investigations more complicated because the individuals responsible for the initial compromise may not be the same people generating the unauthorized AI traffic.

Google expects this market to continue developing as more enterprises integrate powerful AI systems into their operations.

Why Traditional MFA Cannot Prevent Every LLMjacking Attack

The investigation raises an important question for organizations using cloud platforms:

Can multi-factor authentication prevent LLMjacking?

MFA can significantly reduce the likelihood of unauthorized account sign-ins, but it does not directly protect every machine credential or API request.

MFA protects interactive account authentication

Multi-factor authentication requires users to verify their identities through more than one factor.

For example, a cloud administrator may sign in using a password and a verification method.

An authenticator app can generate temporary verification codes for supported services.

This makes password-only account compromise more difficult.

Organizations can also use phishing-resistant authentication methods, including FIDO2 passkeys and hardware security keys.

These provide stronger protection against credential-phishing attacks.

API keys often work differently

An API key is usually used by an application or service rather than a person manually signing in.

Once issued, the key may allow programmatic access until it expires or is revoked.

Depending on the provider and configuration, an API request may not require an additional authentication challenge.

Consequently, an attacker who obtains a valid API key may be able to use it without possessing the legitimate user’s current OTP code.

An authenticator app cannot automatically prevent abuse of an API key that has already been stolen.

This is why organizations must combine user authentication with API key management, restricted permissions, and continuous monitoring.

Session tokens introduce additional risks

Google also documented cases in which attackers obtained existing session tokens.

A valid session token may represent an account that has already completed its authentication process.

That means an attacker using the token might not be prompted to authenticate again.

Phishing-resistant MFA reduces the risk of many account takeover techniques, but it cannot independently eliminate all session theft or backend credential abuse.

For more information about account protection, read our Microsoft Multi-Factor Authentication Guide.

Warning Signs of LLMjacking Activity

Organizations using cloud AI services should monitor their systems for signs of unauthorized resource consumption.

Google emphasized the importance of detecting both unusual AI usage and suspicious changes to cloud identities.

Common indicators of potential LLMjacking

These indicators do not prove that a breach has occurred.

Legitimate application deployments, testing, or configuration changes can produce similar behavior.

However, unexplained activity should be investigated promptly.

Why normal security alerts may miss early activity

Attackers do not always begin with large volumes of traffic.

Google observed credential validation attempts designed to consume very few tokens.

Such requests may appear harmless individually.

Only after confirming that a key is valid might the attacker begin generating large-scale AI workloads.

This is why organizations should monitor authentication events, API key creation, service enablement, and unusual request patterns rather than relying exclusively on high-volume alerts.

How Companies Can Prevent LLMjacking Attacks

Google recommends a layered security approach covering cloud identities, credentials, infrastructure and financial controls.

1. Protect and rotate API keys

Organizations should store API credentials using approved secrets management systems.

Avoid embedding sensitive credentials directly in applications, public repositories, or client-side code.

Where possible, automatically rotate keys and invalidate credentials that are no longer needed.

Use separate API keys for development and production environments.

If a credential is exposed, revoke or replace it promptly.

2. Apply least-privilege access

Cloud users and service accounts should receive only the permissions required for their legitimate tasks.

A basic application should not automatically have permission to create new cloud accounts, enable premium AI models, or modify billing-related configurations.

Granular access restrictions can reduce the damage caused by a stolen credential.

Organizations should also review service account roles and remove unused permissions.

3. Enforce phishing-resistant MFA

Google recommends phishing-resistant authentication for cloud identity providers, management consoles and developer platforms.

Suitable methods may include FIDO2 security keys and supported passkeys.

For services that do not offer these methods, authenticator-based MFA can still provide an additional security layer.

The Authenticator App supports time-based verification codes for compatible online accounts.

However, user MFA must be combined with separate controls for service accounts, API keys, and already authenticated sessions.

To understand the differences between common authentication methods, explore our Google Authenticator Guide.

4. Establish AI spending limits and alerts

Organizations should configure budgets, usage quotas and billing alerts for cloud AI services.

For example, administrators can create notifications when API usage exceeds normal operating levels.

Where supported, hard quotas or spending restrictions can help limit unauthorized consumption.

Budget alerts notify teams about unusual costs, but they do not necessarily stop resource usage automatically.

Therefore, financial controls should be paired with technical enforcement.

5. Scan repositories for exposed credentials

Development teams should implement automated secret scanning.

These tools can detect accidentally committed API keys, tokens and other sensitive credentials.

Regular repository reviews should include private projects, shared development environments, and third-party integrations.

If exposed credentials are discovered, removing them from the repository is not enough.

The affected credentials must also be revoked or rotated.

6. Secure AI gateways and dependencies

Organizations should regularly update their AI middleware, application dependencies and cloud integrations.

Google highlighted the importance of patching model-routing systems, including software affected by CVE-2026-40217.

Security teams should also review the permissions available to gateway administrators.

Restrict unauthorized software installation and monitor changes to AI infrastructure.

7. Monitor cloud identities and API activity

Security teams should review:

• Newly created service accounts.
• Unexpected IAM policy changes.
• Unusual API key generation.
• High-volume inference activity.
• Unapproved model deployments.
• Suspicious geographic access patterns.
• Attempts to disable security logging.

Early detection can prevent a compromised API key from becoming a large financial incident.

What to Do If Your AI API Keys Are Compromised

If an organization suspects LLMjacking, the response should focus on both credential containment and infrastructure investigation.

Step 1: Stop unauthorized access

Immediately revoke or disable confirmed compromised credentials.

Pause suspicious workloads and restrict access to affected AI services where operationally appropriate.

Do not assume that stopping the visible workload removes every unauthorized credential.

Step 2: Review cloud identity permissions

Investigate whether attackers created additional service accounts, access keys, or administrative roles.

Examine IAM changes and remove unauthorized permissions.

Review active sessions and credentials associated with compromised identities.

Step 3: Investigate unauthorized usage

Compare AI API activity with approved application workloads.

Identify when suspicious requests began and which credentials were used.

Preserve relevant logs for incident investigation.

Step 4: Review financial exposure

Contact the cloud provider’s security and billing support teams.

Document suspicious charges and request an investigation of unauthorized resource consumption.

Billing adjustments depend on the provider’s policies and circumstances.

They should not be assumed to occur automatically.

Step 5: Prevent reinfection

Before restoring full access, review application secrets, repository exposure, gateway vulnerabilities and persistence mechanisms.

Issue new credentials with restricted permissions.

Enable monitoring and usage controls before resuming normal operations.

Frequently Asked Questions

What is an LLMjacking attack?

LLMjacking is the unauthorized use of large language model resources, typically through stolen API keys, cloud credentials, or exposed AI endpoints. Attackers consume or resell the victim’s AI computing resources.

How much can LLMjacking cost a company?

Google reported incidents generating more than $100,000 in unauthorized cloud charges within one day. Some organizations accumulated approximately $1 million in usage charges before attackers lost access.

Were Google’s AI models hacked?

Google’s report describes compromises involving enterprise cloud identities, exposed credentials, and vulnerable AI infrastructure across different providers. It does not establish that Google’s underlying Gemini models were directly compromised.

Can hackers use stolen API keys without a password?

Yes. Many APIs accept valid credentials directly without requiring an interactive password login for every request. The exact risk depends on the provider’s authentication and authorization controls.

Can MFA stop LLMjacking?

MFA can reduce the risk of unauthorized interactive account sign-ins. However, it does not automatically prevent misuse of stolen API keys, active session tokens, or compromised service accounts.

Which companies are affected?

Google reported investigations involving organizations in North America, South America, and Asia Pacific across several industries. The public report did not provide a complete list of affected organizations.

How can developers protect AI API keys?

Use a secrets manager, avoid exposing keys in source code, apply least-privilege permissions, rotate credentials regularly, restrict API usage, and monitor cloud activity.

Final Thoughts

Google’s November 2026 investigation highlights a growing cybersecurity problem as more businesses integrate large language models into their operations.

LLMjacking attacks allow criminals to turn stolen cloud credentials into unauthorized AI computing resources, potentially generating hundreds of thousands of dollars in charges within hours.

The discovery of underground LLM reselling services also suggests that attackers are developing increasingly sophisticated ways to monetize compromised infrastructure.

For organizations, the most important defense is a layered security strategy.

This includes protecting API keys, restricting cloud permissions, monitoring resource consumption, securing AI gateways, and implementing effective spending controls.

Phishing-resistant MFA can further strengthen the security of human accounts and administrative access.

However, no single authentication method can protect every component of an AI infrastructure.

The key takeaway: securing enterprise AI requires protecting both user identities and the machine credentials that power cloud applications.

As AI adoption continues to expand, organizations must treat their model access, API keys, and computing quotas as valuable digital assets requiring continuous protection.

Sources and References

1. Google Threat Intelligence Group & Mandiant — The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources — November 2, 2026.
2. BleepingComputer — Google: LLMjacking Attacks Rack Up $1 Million in Cloud AI Charges — November 3, 2026.
3. The Hacker News — Google Warns LLMjacking Attacks Are Costing Some Enterprises Up to $1 Million — November 3, 2026.
4. Google Threat Intelligence Group — From Prompting to Autonomy: The Evolution of Adversarial AI — September 8, 2026.

Last updated: November 4, 2026. This article is based on Google’s published research and independent security reporting. The financial figures describe observed unauthorized cloud usage charges, not necessarily final paid losses.