LLMJacking: When Criminals Sell Your AI Access—and Your Business Gets the Bill

A company can lock down its employee login and still end up paying for an AI service it never intended to offer. The attacker does not need a seat in the office or an account in the company’s chatbot. A separate route to the underlying model service may be enough.

That is what makes LLMJacking a business story as much as a security story: the party selling the answers and the party funding them can be entirely different organizations.

New research brings the problem into focus. Understanding it requires two views at once: how unauthorized access becomes something criminals can sell, and how an enterprise can restrict the spending authority behind that access.

What the report documents

In its November 2, 2026 report, Google Threat Intelligence Group and Mandiant describe investigations involving stolen enterprise LLM access. Observed consumption charges exceeded $100,000 in a day in individual incidents; cumulative charges at some organizations reached $1 million before access was revoked. Exposed or stolen cloud identities were the dominant entry route. Researchers also describe operators of “LLM Mixers” pooling and reselling unauthorized access, sometimes separately from the actors establishing the initial foothold.

These are incident examples, not an average loss or evidence of what every victim ultimately paid. For leadership, the practical question is how much unauthorized work can occur before the organization detects it and restricts the access responsible.

This is not a newly discovered threat. Sysdig documented stolen cloud credentials targeting hosted model services in May 2024, including potential resale while the account owner paid. Today’s report adds evidence of the resale ecosystem around that underlying technique.

The economics of resale

The economic appeal is straightforward. A criminal reseller does not have to train a frontier model or buy the hardware behind it. If unauthorized access lets someone else’s account fund the inference, the reseller can separate the price charged to its customer from the cost imposed on the victim.

That changes what defenders should regard as valuable. An API credential can authorize future consumption. Treating it merely as a technical configuration value understates the financial authority it may carry. Procurement and finance therefore have a stake in how model access is issued, scoped and withdrawn.

A low price alone does not establish criminal activity. Promotions, subsidies and legitimate commercial arrangements exist. A buyer should instead ask who supplies the service, what access the supplier is authorized to resell and how customer data is handled. A bargain is not a substitute for a credible supply chain.

Our reading is that separating access acquisition from resale can make this harder to address as a series of isolated stolen-key events. The victim must close its compromised access; buyers and service operators also need to examine the legitimacy of the infrastructure they depend on.

For a buyer, continuity matters too. If a service depends on access its operator cannot legitimately maintain, the customer has a fragile dependency regardless of how polished the interface looks. Due diligence should reach beyond the chat screen to the operating arrangement behind it.

Different failures require different controls

Several AI risks can appear in the same environment. Separating them helps teams choose the right response.

• Access abuse differs from copying model weights. Unauthorized inference consumes a service; stealing a trained model takes a different asset. Either could occur within a wider intrusion, but one does not establish the other.
• Prompt injection is another mechanism. It attempts to redirect an AI workflow through untrusted input. Stolen credentials can permit requests without manipulating the model’s instructions at all.
• Runaway legitimate work also needs limits. OWASP’s LLM10 guidance covers uncontrolled inference, financial exposure and service degradation, with measures such as quotas, timeouts, resource controls and monitoring. Accidental consumption and intrusion can share safeguards while requiring different investigations.
• Human sign-in and machine access need separate review. Strong multifactor authentication remains important. It does not, by itself, govern an independent service credential held by a backend workload.

Where the loss actually accumulates

Counting requests answers how much happened. An investigation also needs to establish which identity authorized the activity, what that identity could change and which business workload it was supposed to serve.

Alongside usage spikes, investigate unexpected service enablement, new credentials, permission changes and changes to logging. The Google report shows why activity around access matters as well as the model calls themselves. An unexpected change is a reason to investigate, not proof on its own of malicious activity.

In practical terms, connect identity events, model usage and cost records through timestamps and request identifiers. For a shared platform, retain the workload or tenant attribution needed to distinguish one customer’s activity from another’s. Record enough to investigate without filling logs with secrets or unnecessary sensitive prompt content.

A budget, a quota and an enforced cap are different controls

A budget can describe what the business intends to spend. Enforcement determines what a system permits. The word “limit” needs an operational definition.

An alerts-only budget sends a notification. Google Cloud’s documentation distinguishes these budgets, which do not automatically cap consumption, from spend-cap budgets offered for eligible services. Confirm which mechanism is configured, rather than assuming a budget amount blocks further use.

A provider cap also has boundaries. Google’s spend-cap documentation describes monthly budgets scoped to one project and one eligible service. It says enforcement is not instant, in-flight requests can finish and overages are billed normally. Persistent compute and storage can continue accruing charges. A supported cap is useful; it is not a promise that every resource in an account stops at an exact dollar amount.

AWS Budgets carries a latency characteristic worth knowing. Per AWS's own documentation, budget information is updated up to three times a day, typically eight to twelve hours after the previous update. Budget actions and alerts are optional additions, not a universal immediate cutoff.

A quota limits a defined unit of activity. Requests per minute, concurrent operations, token allowances and dollar budgets are different measurements. A request counter alone does not distinguish a short answer from a long, expensive one. Controls should reflect the models and work the organization actually permits.

An application cap covers its enforcement path. If a provider credential permits direct calls that bypass the gateway, a limit inside that gateway cannot govern those calls. Restricting the underlying identity and access routes is part of the design, not an optional dashboard setting.

How a secure application can still fund an attacker

Consider this hypothetical company, rather than a reported victim.

It runs a customer-facing assistant with strong employee authentication. A separate backend credential can invoke several premium models. The application checks each customer’s spending allowance before forwarding work through its gateway.

The credential is copied and used directly against the provider's API. The request never touches the assistant. The gateway cap never sees it. Nothing about the browser session is involved at any point.

A later billing alert may reveal the problem, but the application’s spending counter has not seen the unauthorized requests. Fixing the login page would not repair this route. The company needs controls on the credential and the provider access it authorizes.

Even within the intended route, concurrency needs attention. If many requests read the same remaining allowance before any records its charge, they can all appear affordable. One engineering approach is to reserve an estimated allowance atomically before dispatch, then reconcile actual usage. Retries, queued work and in-flight requests also need explicit rules. Test expected overrun behavior instead of assuming that a cap guarantees zero overshoot.

What containment actually requires

• Inventory and ownership. Identify model services, invoking identities, issued credentials and the business owner of each workload.
• Segmentation. Scope access by workload, tenant and environment, with only the model and administrative permissions each needs.
• Administrative boundaries. Separately control who can enable services, create credentials or change permissions. Investigate changes outside the approved process.
• Persistence checks. Look beyond the first exposed credential for additional access or unauthorized resources. Rotating one key is not proof that the compromise has ended.
• Evidence preservation. Preserve relevant logs while containment proceeds. Do not leave known compromised access active merely to complete an evidence collection. Record what responders changed and when.
• Provider coordination. Follow the response steps for the affected identity and credential type, and reconcile unauthorized usage with the provider.
• Continuity planning. Know which legitimate workloads a restriction will interrupt and how essential operations can continue safely.

There is an important detail in Google’s compromised-credential guidance: service-account access tokens exist separately from the key used to obtain them. Deleting a key is not equivalent to invalidating those tokens. The guidance describes blocking affected access through measures such as disabling the service account or an appropriate deny policy, alongside credential replacement and activity review. Responders need the correct authority and a plan for affected workloads before an emergency.

On identity hygiene, the direction of travel is well documented: avoid long-lived user-managed keys where better authentication exists, reduce how many keys exist, apply least privilege and keep secrets out of source code. Short-lived credentials help. They are not immunity, because they still carry whatever permissions they were granted.

Inside an AI application, explicit tool permissions, human checkpoints for consequential actions and evaluation of actual behavior serve a related purpose: keeping authorized workflows within their intended scope. Those controls need their own tests. They do not replace protection of the provider identity outside the application.

Questions for the board, the CFO and the CIO

• Which model services are enabled in our accounts, and who authorized each one?
• How many non-human identities can invoke them, and when was each credential last rotated?
• Is our limit an alert, an enforced control, or a provider quota — and what bypasses each?
• How stale is our cost data during a working day, in hours?
• What is the maximum we could lose before a human notices, and who owns that number?
• Can we produce one timeline across identity, model invocation and billing if we had to, today?

The practical test is whether the organization can explain the access, attribute the consumption and restrict the right activity under pressure. AI adoption creates useful capacity. Security architecture must make the authority to consume that capacity visible, limited and accountable.