Quick Answer: LLMjacking is the unauthorized use of paid AI services, often through stolen API keys or other access credentials. Criminals submit their own requests or resell access, leaving the account owner with unexpected charges. Businesses can reduce the risk by protecting credentials, monitoring usage, and establishing spending controls and clear response responsibilities.

An AI Bill Nobody Can Explain

LLMjacking can turn your company’s paid AI account into a service for strangers, leaving you with their bill. This form of AI resource theft often begins with exposed credentials that allow software to access a paid service. For businesses adopting AI, unexpected spending can therefore deserve attention from both finance and security. 

Consider a fictional company that uses AI to summarize customer support tickets and prepare internal reports. One month, its finance manager notices a sharp increase in charges and assumes another department has launched a project. Engineering checks, but nobody recognizes the additional work. Support requests remain steady, and the reporting schedule has not changed.

“Are we paying for something we didn’t ask for?” the finance manager wonders. What looked like growing adoption now raises a different question about who controls the account.

What Is LLMjacking, and What Gets Stolen?

LLMjacking is the unauthorized use of large language model services, often through stolen access credentials. In this scenario, criminals consume paid AI resources while the account owner receives the charges. They do not need to steal the model itself to profit from the access. 

An API key is a digital credential that allows an application to access a service. Someone holding a stolen key may submit requests within its permissions and restrictions, charging usage to the associated account. 

The word “token” needs care here. Unit 42 describes this credential abuse as “token jacking.” However, the input and output tokens on an AI usage statement mean something different. They represent pieces of text that a model processes, such as words or parts of words. Access credentials authorize requests; processing tokens help measure the work. 

A company fuel card offers a useful comparison. A thief does not need your delivery van to buy fuel on your account. Likewise, your AI access can have value to someone who has no interest in your internal reports.

How Stolen Access Becomes Someone Else’s Business

AI API key theft can begin with credentials exposed in code repositories or stolen through compromised developer accounts. Once attackers obtain usable access, they can submit their own requests or route other people’s requests through it. 

Some LLMjacking operations turn that access into a revenue source. Sysdig researchers documented proxy services using stolen credentials across multiple AI providers. These services act as intermediaries between customers and the actual models. An operator can sell access while compromised accounts absorb the underlying usage charges. Not every intermediary operates illegally; the issue is whether it has authorization to use the capacity it sells. 

Unit 42 describes cases where exposed credentials entered unauthorized resale services within minutes. Its report cites nearly $1 million in charges before discovery and containment. That figure illustrates potential severity, not a typical loss or what every victim should expect. 

Our finance manager now has a plausible explanation for the mismatch. The account could be supporting somebody else’s customers, without any connection to an internal project.

Who Would Notice the Unfamiliar Work?

“Why is our AI bill suddenly higher?” sounds like a finance question, but answering it requires context. In our example, engineering compares the provider’s usage records with the company’s applications. The team might investigate activity linked to an idle project or model use nobody remembers approving.

A higher bill alone would not prove an attack. Perhaps the team approved a large processing job, or an application repeatedly retried failed requests. The team needs to test those explanations rather than jump from an uncomfortable number to a security verdict.

Finance can clarify the charges, engineering can trace application activity, and security can investigate whether someone misused access. Sysdig specifically recommends that security and finance review unexpected spikes in AI usage and cloud spending. 

The useful question goes beyond whether the total increased: Can the business account for the work behind it?

What Should an AI Spending Review Actually Reveal?

For your business, a useful review starts with ownership. Who is responsible for each paid account, and which business activities should it support? “The development team” leaves room for confusion; a named owner gives colleagues somewhere to take an unexplained charge.

Next comes the relationship between spending and expected work. At the company in our example, support-ticket summaries should broadly connect to support activity. A new project might explain additional spending, but someone should be able to identify that project.

Finally, the review needs to establish who can respond. Who receives an unusual-usage alert, and who follows up when its recipient is unavailable? Who can restrict access, and who understands which legitimate services that decision might interrupt?

These questions turn an invoice review into a conversation about responsibility. The aim is not to justify every generated sentence, but to avoid paying for activity nobody can explain.

How Can Your Business Reduce the Risk?

There is no single measure that can prevent unauthorized AI usage, but a few basic practices can reduce the risk. The goal is to protect access, recognize unusual activity, and understand what happens when spending crosses an expected threshold.

LLMjacking prevention starts with access

Credentials belong in protected storage rather than shared source code or publicly accessible applications. OpenAI warns that exposing API keys in browsers or mobile apps can allow outsiders to make unauthorized requests. It also recommends restricting permissions and maintaining a process for replacing keys. 

Where providers support temporary credentials, shorter lifetimes can reduce how long stolen access remains usable. Unit 42 recommends moving away from long-lived access keys as part of its mitigation guidance. 

A baseline gives the bill some context

Monitoring becomes more useful when teams know which applications normally generate requests and how much activity they produce. Provider records and application logs can help teams investigate activity they do not recognize. Sysdig recommends monitoring cloud activity and maintaining appropriate logs to detect unauthorized use. 

For the company in our example, “spending increased” would be a starting point rather than a conclusion. Comparing that increase with support volume would help the team decide where to investigate next.

An alert is not a stop button

“Doesn’t our budget setting stop this?” is a reasonable question. The answer depends on what the setting actually does.

OpenAI distinguishes spending alerts from enforced hard limits. An alert sends a notification while requests continue; an enforced limit rejects affected requests after tracked spending reaches the threshold. Enforcement is not instantaneous, so recorded spending can slightly exceed the configured amount. Hard limits can also interrupt legitimate applications. 

A sensible discussion therefore includes both financial exposure and acceptable disruption. Someone needs authority to investigate an alert before the business reaches a stopping point.

When a Billing Question Becomes an Incident

When evidence points to a leaked key, the response needs to address access as well as the invoice. OpenAI recommends reviewing usage, immediately replacing the compromised key, updating affected applications, and contacting support. Replacing the key includes revoking the old one, not simply creating another. 

However, a leaked key and a compromised administrator account require different scopes of investigation. Unit 42 describes attackers using privileged accounts to create additional keys and disable spending or monitoring controls. Replacing one credential would not resolve an attacker’s continued control of that account. 

Finance should help document disputed charges and distinguish them from legitimate activity while technical teams contain the incident. The company should approach those discussions without assuming that the provider will issue a refund.

In our scenario, the company discovers an exposed development key and revokes it. Engineering updates the affected application while finance documents the unexplained charges. Security investigates how the key escaped and whether the attacker gained any additional access. The teams then assign responsibility for monitoring the account instead of assuming somebody else already handles it.

Conclusion: Whose Work Is on Your AI Bill?

The company began with a familiar assumption: More spending meant more business activity. Its investigation revealed that the extra work belonged to someone else.

The practical lesson is to connect paid AI access with clear ownership, understandable usage, and authority to respond. A useful spending review should establish who requested the work, not merely which department receives the expense.

Before asking whether your AI spending delivered value, there is one more question: Was the work actually yours?

For more perspectives on cybersecurity and AI adoption, join the conversation at Tech Scope Connect.

Sources:

• LLMjacking: From Emerging Threat to Black Market Reality | sysdig.com
• LLMjacking: Stolen Cloud Credentials Used in New AI Attack | sysdig.com
• Best Practices for API Key Safety | help.openai.com
• Token Jacking: Cybercriminals Could Be Stealing Your AI Resources | unit42.paloaltonetworks.com
• Understanding and Counting Tokens | help.openai.com
• LLMjacking Targets Deepseek | sysdig.com
• Spend Limits | developers.openai.com