LLMJacking: How Stolen AI Access Left Companies With $1 Million Bills

Hackers are stealing companies’ access to artificial intelligence services and using their cloud resources to run their own operations. In some cases, the activity has generated more than $100,000 in fraudulent charges in a single day, with cumulative bills reaching $1 million before companies managed to revoke the attackers’ access.

Google’s Threat Intelligence Group (GTIG) and Mandiant disclosed the findings on November 2, 2026, following investigations into multiple incidents involving organisations across North America, South America and Asia-Pacific. The affected sectors included financial services, retail, technology and transportation.

The attacks are known as LLMJacking. Instead of directly stealing money from company bank accounts, criminals hijack access to expensive AI models and cloud computing resources. They then use those resources for their own operations or sell access to other people, leaving the legitimate organisation responsible for the resulting charges.

Google’s findings reveal an increasingly organised criminal operation in which different groups obtain access to company infrastructure and sell the stolen AI resources through underground services.

How does LLMJacking work?

LLMJacking is a form of resource hijacking in which attackers obtain unauthorised access to large language models (LLMs) and the cloud infrastructure supporting them.

Companies use these models through services that process AI requests. Depending on the provider and service, usage can be charged according to the number of input and output tokens, model selection and computing resources consumed.

Developers typically connect their applications to these services using API keys and other authentication credentials.

An API key works like a digital access pass. It allows an application to communicate with an AI service without requiring someone to enter a password for every request.

If criminals obtain a valid key or another credential with sufficient permissions, they may be able to use the company’s AI resources without its knowledge.

The organisation can then receive charges for requests it never authorised.

Google found that attackers used several methods to gain access. These included searching for publicly exposed AI endpoints and obtaining cloud identity credentials, service-account keys, GitHub personal access tokens and active session tokens.

Hackers tested stolen AI keys with tiny requests

One of the more concerning findings involves how criminals checked whether stolen credentials were still working.

Google observed a threat actor collecting exposed corporate AI API keys from public GitHub repositories.

Rather than immediately sending large numbers of requests, the attacker used automated checks that generated minimal responses containing just one output token.

These requests used a setting called max_tokens=1, which limits the maximum number of tokens an AI model can generate in a response.

This allowed the attacker to check whether stolen credentials were valid without immediately generating large amounts of traffic.

Google said these validation requests went undetected by the affected organisation’s endpoint detection and response (EDR) and security information and event management (SIEM) volume-anomaly alerts.

This is an important finding because security teams cannot rely exclusively on unusually high API traffic to identify compromised credentials. Even a small request can indicate that someone is testing stolen access before launching a much larger operation.

How attackers gained deeper access to company systems

Once inside a company’s cloud environment, some attackers searched for additional credentials and permissions that could help them maintain access.

Google observed threat actors examining source-code repositories, cloud services, access logs and databases for sensitive information.

In some investigations, attackers used compromised service accounts and cloud permissions to create additional credentials. Others created unauthorised identity and access management (IAM) accounts, attached administrative permissions to service roles or inserted SSH keys into computing instances.

These actions can make an intrusion more difficult to contain. Revoking one exposed API key may not remove other credentials or access mechanisms that criminals have already created.

Google also documented activity involving a financially motivated threat cluster identified as UNC6993.

In one investigation during mid-2026, UNC6993 gained access to a cloud instance through a misconfigured service-account key and used that access to obtain further access to an LLM API.

Google also observed the group operating a session-hijacking page that impersonated an application portal.

The page instructed users to visit a legitimate AI service and paste a raw JSON payload containing an active access token. The token was then submitted to the attacker’s backend, allowing the attacker to use the existing session rather than relying on the victim’s password.

This is particularly concerning because stolen active session tokens can allow criminals to misuse an authenticated session without completing the normal sign-in process themselves.

The findings show why protecting cloud identities and active sessions is just as important as protecting individual AI API keys.

Criminals are selling stolen AI access for $60 a month

Google’s investigation also revealed an underground market built around compromised AI resources.

Some of the services involved are known as LLM Mixers. These operate as routing gateways that combine access to multiple AI resources and resell unauthorised access to customers.

The criminals who obtain the original access do not necessarily operate the resale services themselves. Different groups can handle the intrusion, infrastructure and commercial distribution.

One example identified by Google was Jet Night.

Researchers observed a threat actor using stolen third-party API keys to support more than 500,000 LLM API calls in less than eight hours.

Jet Night passed nearly $1 million in token costs to the victim organisation.

Google also found that the service advertised an unlimited-token plan for approximately $60 per month, claiming to offer access to advanced AI models.

The researchers believed the unusually low prices were possible because the service relied on stolen credentials rather than paying the normal costs of the AI resources it supplied.

This creates a business model in which criminals sell inexpensive access to expensive AI services while the legitimate account owner absorbs the financial burden.

In other words, the customer gets access to the AI service, the criminals collect the subscription payment, and the compromised company receives the usage bill.

Why the cloud bills can increase so quickly

Unlike traditional cryptojacking, which often consumes a victim’s computing resources over an extended period, LLMJacking can generate substantial usage spikes within hours.

AI services charge according to the models and resources used. Large numbers of requests, expensive models and sustained inference workloads can quickly increase consumption.

Google observed one threat actor subscribing compromised accounts to pay-as-you-go agreements, selecting premium foundation models and launching high-volume inference streams.

Another technique involved repeatedly creating and deleting short-lived service accounts to work around rate limits.

Attackers also used compromised cloud environments to deploy their own proxy endpoints, AI agents and computing workloads.

The financial impact is not necessarily limited to AI API requests. Depending on the permissions obtained, criminals may also create additional cloud resources, access internal credentials and establish persistent access to company infrastructure.

This means that an unexpected AI bill can be a sign of a much wider security incident.

How companies can protect their AI accounts

Practical security guide

How to Stop Hackers Turning Your AI Access Into a Costly Bill

LLMJacking attacks can begin with a leaked key or exposed AI endpoint. These controls help reduce the chance that attackers can use company AI accounts, expand their access or run up unauthorised cloud charges.

01

Lock down every API key

Keep keys out of source code, configuration files and public repositories. Store credentials securely, restrict each key to the APIs and applications that need it, and remove unused keys.

Why it matters: Google found attackers harvesting exposed corporate AI keys from public GitHub repositories. Google’s investigation explains the technique.

02

Stop secrets before they are committed

Enable secret scanning and push protection where available. If a real key or token leaks, revoke or rotate it immediately. Deleting the visible text does not make an exposed credential safe.

Why it matters: GitHub push protection can block supported secrets before they enter a repository. GitHub also says exposed real secrets must be revoked. GitHub push protection.

03

Limit what each account can do

Give employees, applications and service accounts only the permissions they need. Avoid broad administrator access and unnecessary long-lived service-account keys.

Why it matters: Google documented intrusions in which compromised cloud identities were used to expand access and obtain further credentials. Google’s service-account guidance.

04

Look beyond large usage spikes

Monitor API activity, newly enabled AI services, permission changes and new credentials. Investigate unusual requests even when their volume is very small.

Why it matters: In one investigation, attackers tested stolen keys with requests limited to one generated token (max_tokens=1). A high-volume alert alone could miss this early activity. Google’s technical findings.

05

Make usage limits more than an alert

Set provider-supported quotas and usage limits. Add billing alerts, but also establish a response that can restrict or disable compromised resources when necessary.

Important distinction: Google says alerts-only budgets do not automatically stop usage or spending. A spend cap is a separate control and is available only where supported. Google Cloud budget guidance.

06

Protect logins and active sessions

Use phishing-resistant multifactor authentication where supported. Review unusual sign-ins and revoke suspicious sessions, tokens and credentials rather than relying on password changes alone.

Why it matters: Google described a session-hijacking operation that tricked users into handing over active access tokens. Read Google’s account of the attack.

07

Find AI services exposed to the internet

Maintain an inventory of AI endpoints, model gateways and internal tools. Check that public-facing services require appropriate authentication and are not unintentionally exposed.

Why it matters: Google observed attackers probing publicly accessible LLM endpoints to run their own models. See the exposed-endpoint findings.

What makes LLMJacking different from ordinary AI misuse?

LLMJacking is not simply someone using an AI chatbot for a malicious purpose.

It involves the unauthorised use of another organisation’s AI accounts, computing resources or cloud infrastructure.

The attackers can use those resources for their own operations or sell access to other people. The financial burden remains with the organisation whose credentials or infrastructure have been compromised.

Google expects this activity to grow as more businesses integrate higher-tier AI models and automated AI agents into their operations.

For companies, the problem is therefore not limited to protecting AI applications themselves. It also involves securing cloud identities, service accounts, developer credentials and the permissions that make those applications work.

The findings provide a clear warning: a stolen AI credential can become much more than an account-security problem. If attackers obtain sufficient access, it can turn into a costly cloud infrastructure incident.

Editorial transparency

How We Checked This

We based this report on Google’s threat-intelligence investigation and checked the practical security recommendations against documentation published by the relevant technology providers.

Primary investigation

• Google Threat Intelligence Group and Mandiant — The Rise of LLMJacking . The main source for the attack methods, investigated incidents, unauthorised AI usage and reported cloud charges.

Credential and repository security

• Google Cloud — Best practices for managing API keys . Key restrictions, secure handling, monitoring and rotation.
• GitHub — Push protection . How supported exposed secrets can be blocked before they reach a repository.
• Google Cloud — Best practices for service accounts . Reducing unnecessary credentials and limiting account privileges.

Monitoring and financial controls

• Google Cloud — Budgets and budget alerts . Clarifies that alerts-only budgets do not automatically stop usage or spending.
• Google Cloud — Cloud Audit Logs . Explains audit-log coverage and the configuration required for Data Access logs.
• AWS — Monitoring Amazon Bedrock API calls with CloudTrail . Explains how Bedrock activity can be recorded and which data events need additional configuration.

Scope and limitations: Google’s public report describes investigated organisations in North America, South America and Asia-Pacific. It does not identify every affected organisation or establish that UK companies were among the victims. The reported charges are unauthorised cloud-resource consumption costs, not confirmed losses from stolen bank funds. Security recommendations in this article are based on the providers’ published guidance.