LLM Jacking: What It Is, How It Works, and How to Stop It

Published on: 26/10/2026 | Updated on: October 26, 2026

LLM jacking is the unauthorized use of large language model (LLM) services through stolen credentials, compromised cloud accounts, or exposed AI endpoints. Attackers exploit this access to run AI workloads, resell model access, or shift computing costs onto victims. The result can include unexpected API charges, compromised cloud infrastructure, and limited visibility into unauthorized activity.

For businesses using AI APIs, the risk extends beyond a leaked API key. A compromised cloud identity or billing account can allow attackers to use AI services without exposing their requests in the victim’s usual application logs.

What Is LLM Jacking?

LLM jacking is a type of resource abuse in which attackers hijack access to large language models or the infrastructure that supports them. Instead of paying for their own AI usage, attackers exploit another person’s or organization’s credentials, accounts, or computing resources.

The term was popularized by the Sysdig Threat Research Team, which documented the abuse of stolen cloud credentials to access hosted LLM services. Its March 2026 explainer describes the attack as a form of resource jacking. Read Sysdig’s LLM jacking explanation.

The attack can affect organizations using commercial AI APIs, managed cloud AI platforms, or self-hosted inference services. Depending on the access obtained, attackers may consume expensive models, sell unauthorized access to other users, or run workloads that the legitimate account owner never approved.

Why do attackers target LLM services?

AI services offer a resource that attackers can monetize: access to model inference and computing capacity.

Common motivations include:

• Cost shifting: Running AI workloads on a victim’s account so the victim pays the bill.
• Unauthorized resale: Selling access to compromised AI accounts or API credentials.
• Resource abuse: Using cloud GPUs, model endpoints, or other infrastructure without permission.
• Operational concealment: Hiding activity behind a legitimate organization’s identity or billing relationship.
• Abuse of AI capabilities: Using unauthorized access for automated tasks, code generation, or other activities that violate the service’s terms or the victim’s security policies.

These motivations are not mutually exclusive. However, the exact purpose of an incident should be established through evidence rather than assumed from unusual AI usage alone.

How Does LLM Jacking Work?

LLM jacking generally begins when an attacker gains unauthorized access to an AI service, cloud identity, or exposed inference endpoint. The attacker then uses that access to consume computing resources or establish an arrangement in which someone else pays for the workload.

The precise sequence varies by incident. Some attacks rely on exposed API keys, while others involve phishing, compromised cloud administrators, or manipulated billing permissions.

1. Attackers obtain access to credentials or infrastructure

An attacker may obtain a credential through a leaked source-code repository, compromised developer account, phishing attack, infostealer malware, or insecure application configuration. In other cases, the weakness is an AI endpoint that accepts requests without adequate authentication.

A credential may provide direct access to a model API or broader permissions within a cloud environment. Those two situations create different risks and require different investigative approaches.

2. Attackers establish unauthorized AI access

With valid credentials or an exposed endpoint, attackers may send requests to an AI model, create service accounts, generate new API keys, or modify access permissions.

If the compromised identity has excessive privileges, the attacker may also be able to change cloud policies or manipulate how resources are billed.

3. Attackers run or resell AI workloads

The attacker may use the service directly or offer access to other people. Large-scale inference can generate substantial consumption, especially when workloads run continuously or use resource-intensive models.

In a cloud billing hijacking scenario, the attacker may instead use an attacker-controlled project linked to the victim’s billing account. This can separate the workload from the victim’s ordinary project-level monitoring.

4. The victim discovers the abuse

Organizations may notice an unexpected invoice, abnormal token consumption, unfamiliar service accounts, or suspicious cloud configuration changes.

However, a billing alert alone does not explain how access was obtained. Investigators must trace the activity through identity, API, administrative, and billing records where those records are available.

The following diagram summarizes this conceptual attack path.

This is a conceptual model, not a universal sequence. An attacker who compromises a billing relationship may never need to steal the victim’s direct AI API key.

LLM Jacking vs. API Key Theft and Other AI Attacks

LLM jacking and AI API key theft are closely related, but they do not mean the same thing. API key theft is one possible way to obtain unauthorized access. LLM jacking describes the broader abuse of AI access or resources.

Threat	What it means	Main concern
LLM jacking	Unauthorized use of AI services or infrastructure	Resource abuse, financial losses, or unauthorized access resale
AI API key theft	An attacker obtains an API credential without permission	Unauthorized requests and access to whatever the key permits
Prompt injection	Malicious instructions manipulate an AI system’s behavior	Data exposure, unauthorized actions, or control-flow manipulation
Model extraction	An attacker uses model queries to infer or reproduce aspects of a model	Intellectual property loss
Denial-of-wallet attack	Activity deliberately drives up usage-based service costs	Unexpected expenditure and possible service disruption
Cryptojacking	Unauthorized use of computing resources to mine cryptocurrency	Resource consumption and financial losses

These threats can overlap. For example, stolen credentials might enable both LLM jacking and a denial-of-wallet attack. Prompt injection could also contribute to an incident if it causes an AI agent to misuse permissions. Nevertheless, each threat requires its own investigation.

For the broader security context, the MITRE ATT&CK Resource Hijacking technique provides a useful reference for unauthorized resource consumption.

What the 2026 LLM Jacking Reports Reveal

Recent threat intelligence shows that LLM jacking can involve more than a leaked API key. Two reports published in 2026 illustrate different ways attackers can exploit AI access and cloud infrastructure.

Google’s September 2026 threat intelligence findings

On September 8, 2026, the Google Threat Intelligence Group (GTIG) published From Prompting to Autonomy: The Evolution of Adversarial AI. The report describes adversaries targeting AI assets, stealing API credentials, and compromising cloud environments to sustain unauthorized AI workloads.

GTIG also reported that underground marketplace prices for AI accounts had more than doubled in 2026 within the markets it tracked. This finding concerns the observed underground market, not every AI provider or every type of account. Read the official Google Cloud report.

The report’s documented activity reinforces an important security lesson: organizations must protect both AI-specific credentials and the cloud identities that can create or modify AI infrastructure.

Wiz’s October 2026 cloud billing investigation

On October 20, 2026, the Wiz Customer Incident Response Team published an investigation into attacks that abused Google Cloud billing accounts to fund unauthorized Gemini API usage.

According to Wiz, the investigated campaigns began with phishing through sponsored search advertisements. Attackers captured cloud user credentials and authentication codes, manipulated cloud permissions, and linked attacker-controlled projects to victims’ billing accounts.

The attacker-controlled projects generated AI API usage that was charged to the victim. Because the requests ran in external projects, the victim organization could lack visibility into the prompts and model outputs through its own ordinary project logs.

Wiz reported that the investigated victims experienced unexpected charges ranging from tens of thousands to hundreds of thousands of dollars within 24 to 48 hours of initial access. These figures describe the reported incidents, not a typical or guaranteed loss from LLM jacking. Read the Wiz investigation.

The key lesson: protecting API keys alone is not enough. Cloud administrators must also protect billing permissions, monitor changes to identity policies, and investigate unexpected links between projects and billing accounts.

Warning Signs of LLM Jacking

LLM jacking may first appear as a financial anomaly, but organizations can sometimes identify suspicious activity earlier by monitoring identities, AI usage, and cloud configuration changes.

No single indicator proves an attack. The strongest evidence comes from several unusual events that occur together or cannot be explained by legitimate business activity.

Unexpected AI usage or API charges

Look for sudden increases in token consumption, API request volume, or model usage without a matching deployment or change in application traffic. Unfamiliar models, unusual usage patterns, or activity on previously dormant keys may also warrant investigation.

Compare current usage with the normal baseline for each application, project, API key, or model. A company-wide monthly total may hide abuse concentrated in a single credential.

Unusual cloud identity changes

Investigate changes that create or expand access unexpectedly, including:

• New service accounts or API keys in projects that rarely use AI.
• Privileged roles assigned to unfamiliar identities.
• External accounts added to cloud projects or billing accounts.
• Unexpected changes to organization-level identity policies.
• Existing administrators unexpectedly losing their privileges.

These indicators are especially relevant to the cloud billing abuse described by Wiz.

Unexpected AI services or resource provisioning

Check for newly enabled AI APIs, unfamiliar model endpoints, unusual GPU resource activity, and cloud projects that have no clear business owner.

Also investigate unexpected changes to billing relationships. A workload can generate charges through a billing account even when the actual AI requests occur outside the victim’s own project.

Missing or incomplete monitoring

A lack of visible AI requests does not always mean that no unauthorized usage occurred. If an attacker runs workloads in a separate project, the victim’s normal application logs may not capture the model requests themselves.

When billing activity does not match recorded workloads, investigate the billing account, organization-level audit logs, IAM changes, and external project relationships rather than relying only on model invocation logs.

How to Prevent LLM Jacking

The most effective approach combines credential protection, least-privilege access, cloud billing controls, and monitoring. Each control addresses a different part of the attack, so no single measure should be treated as a complete solution.

1. Inventory and secure AI credentials

Maintain an inventory of AI API keys, service accounts, model endpoints, and the applications that use them. Remove unused credentials and investigate keys whose owners or purposes cannot be established.

Keep secret credentials on trusted backend systems rather than embedding them in public client-side code. Use an approved secrets manager where appropriate, restrict access to secrets, and rotate exposed credentials promptly.

Environment variables can help separate secrets from source code, but they are not a complete security boundary. Anyone who compromises a process or environment with permission to read a secret may still obtain it.

2. Apply least privilege to cloud identities

Give users, service accounts, and applications only the permissions they need. Separate routine AI inference permissions from administrative permissions that can create identities, modify organization policies, or change billing relationships.

Protect privileged accounts with phishing-resistant multifactor authentication where supported. Review external identities and administrative role assignments regularly, and alert on unexpected privilege changes.

3. Protect cloud billing relationships

Treat billing-account administration as a sensitive security function, not merely a finance task.

Review who can attach projects to billing accounts, modify billing permissions, or change organization policies governing external identities. Restrict these capabilities to approved administrators and alert on unexpected changes.

For Google Cloud environments, the Wiz investigation provides a useful list of areas to inspect, including billing IAM roles, organization policy changes, external project links, and service account creation. Validate the applicable controls against your own cloud configuration and current provider documentation.

4. Set usage alerts, quotas, and budget controls

Configure alerts for unexpected spending, unusual request volumes, and abnormal model consumption. Where supported, use service quotas and provider-specific spending controls to limit the impact of misuse.

These measures reduce the potential damage, but they do not prevent every attack. An attacker may expose data, misuse access, or cause disruption before a spending threshold is reached. Some budget alerts also notify administrators without automatically stopping resource consumption.

5. Monitor AI and cloud audit logs

Collect and review the logs that are available for your AI provider, cloud platform, and identity system. Monitor model requests where supported, API key creation, service account changes, privilege assignments, organization policy modifications, and billing activity.

Correlate events across systems. A new service account followed by unexpected API usage and a billing spike is more concerning than any of those events in isolation.

6. Establish an AI security review process

Before deploying an AI application, identify which identities can access the model, which data the application can send, how secrets are stored, and which logs are retained.

Review the setup after changes to the model provider, cloud project, API permissions, or application architecture. This is particularly important when AI agents or automation tools can invoke external services on their own.

What to Do If You Suspect LLM Jacking

If you suspect unauthorized AI usage, prioritize containment while preserving enough evidence to understand how the compromise happened.

1. Confirm the suspicious activity. Review billing records, usage metrics, identity changes, and available API or cloud audit logs. Record relevant timestamps and affected accounts.
2. Revoke compromised credentials. Disable exposed API keys or tokens and revoke compromised sessions or identities. If a cloud administrator is compromised, secure the affected identity and its recovery paths.
3. Contain unauthorized access. Remove unapproved permissions, external identities, and suspicious billing relationships. Stop unauthorized workloads where you can safely identify them.
4. Preserve evidence. Retain relevant logs, configuration changes, billing records, and incident timestamps. Avoid deleting resources before collecting evidence unless immediate containment requires it.
5. Review financial exposure. Identify the affected services and billing accounts, estimate unauthorized consumption, and contact the provider promptly to report the incident and ask about its billing-dispute process.
6. Investigate the original entry point. Determine whether the incident involved phishing, leaked credentials, an exposed endpoint, compromised developer access, or excessive permissions.
7. Recover and strengthen controls. Replace credentials, restore approved permissions, validate billing relationships, and monitor for renewed suspicious activity.

If the attack involves cloud billing hijacking, do not assume that revoking an AI API key alone will stop all unauthorized charges. Investigate the billing relationship and the identities controlling it.

Frequently Asked Questions About LLM Jacking

Can LLM jacking happen without stealing an AI provider account?

Yes. An attacker may compromise a cloud identity, misuse billing permissions, or access an exposed AI endpoint. The resulting abuse can occur without taking over the victim’s direct account with the model provider. The exact risk depends on the permissions and infrastructure involved.

Can an exposed cloud account lead to unauthorized AI charges?

Yes. A compromised cloud account may allow an attacker to create AI credentials, enable services, provision computing resources, or modify billing relationships. The extent of the exposure depends on the account’s privileges and the provider’s security controls.

Do API usage limits prevent LLM jacking?

No. Quotas, rate limits, and spending controls can limit some forms of abuse, but they do not prevent credential theft or guarantee protection against data exposure. Use them alongside access restrictions, credential security, audit logging, and billing alerts.

Can legitimate AI traffic hide unauthorized usage?

Yes. If an attacker uses a valid credential, their requests may resemble authorized application traffic. Monitoring per-key usage, model selection, request patterns, identity changes, and expected application behavior can help uncover anomalies. Some cloud billing attacks may require investigation beyond the victim’s ordinary model request logs.

Which logs should a security team investigate first?

Start with the records closest to the suspected abuse. For unexpected AI consumption, inspect provider usage and billing data alongside cloud audit logs. For suspected identity compromise, examine authentication events, role assignments, service account creation, organization policy changes, and billing-account modifications. Log availability varies by provider and configuration.

Conclusion

LLM jacking is best treated as both an identity-security problem and a resource-abuse problem. Protecting AI credentials matters, but organizations must also understand who can create AI workloads, change cloud permissions, and control billing relationships.

For an immediate improvement, review your AI credential inventory and cloud billing permissions together. That single review can expose risks that a conventional API key audit would miss.

For further guidance, consult the Google Threat Intelligence Group’s 2026 report and the Wiz cloud billing investigation. Use their documented findings to inform your own threat model, then validate the relevant controls against your infrastructure.