Hard2bit
← Back to the cybersecurity blog

LLMjacking: how attackers steal your AI compute, hand you the bill and build their attack infrastructure

By Adrián González · CEO · Published: 13 July 2026 · Updated: 13 July 2026
LLMjacking

Between December 2025 and January 2026, an operation named Bizarre Bazaar logged more than 35,000 attack sessions against exposed AI infrastructure, roughly 972 attempts a day. When the target was an account with access to top-tier models, the bill charged to the victim ran past 100,000 dollars a day. This is not data theft or encryption. This is someone burning your artificial-intelligence compute and leaving you the invoice.

The pattern has had a name since 2024, LLMjacking, and in 2026 it stopped being a curiosity and became an industry with suppliers, brokers and marketplaces. Researchers have catalogued around 175,000 Ollama instances reachable from the internet across more than 130 countries, and firms such as Sysdig report a 376% rise in credential theft aimed specifically at AI services between the fourth quarter of 2025 and the first of 2026. If your organisation already uses cloud models or self-hosted inference servers, this is your problem, not somebody else's.

What LLMjacking is, and why it matters now

LLMjacking is the unauthorised use of an organisation's AI capacity: either through stolen cloud-provider credentials (Amazon Bedrock, Azure OpenAI, Google Vertex AI, Anthropic) or through self-hosted inference servers left exposed without authentication. The attacker is not chasing your data first; they are after your compute budget and the reasoning power of the models you pay for.

Two things have shifted in 2026. First, the surface: every product team that wires up a model, every API key sitting in a repository, every AI gateway spun up to "try things out" widens the ground. Second, the purpose: the most advanced attackers no longer merely resell access, they consume that compute to power their own offensive tooling. The stolen resource turns from commodity into weapon.

The anatomy of the attack, at a conceptual level

It is worth understanding the mechanics without turning them into a manual. LLMjacking relies on two conditions that almost every organisation meets without noticing.

Route 1: stolen cloud credentials

An AI-provider API key leaked in a repository, a container registry, a configuration file, or through a malicious plugin or extension, is enough. In June 2026, researchers documented malicious JetBrains plugins stealing AI keys while browser extensions captured chatbot conversations. With the key in hand, the attacker invokes the model from their own infrastructure and the consumption is billed to the victim. It is the same non-human identity abuse we saw in Microsoft 365 account takeover, moved onto the inference bill.

Route 2: exposed inference servers

Tools such as Ollama, widely used to serve models on your own hardware, listen by default on port 11434 and ship with no authentication. A server of that kind reachable from the internet is simply free model capacity for whoever finds it, which is why some 175,000 exposed instances have been counted. AI gateways that centralise credentials for several providers make it worse: compromising a single library can expose an organisation's entire portfolio of keys at once, a supply-chain risk we covered when analysing the Langflow flaw that turned AI flows into a credential store.

The trail the attack leaves is distinctive: spikes in model invocations from unusual addresses or regions, automated request patterns at odd hours, and spend that climbs with no internal project to justify it.

From wrecking the bill to building attack infrastructure

Operation Bizarre Bazaar, documented jointly by Sysdig and Pillar Security, gave the first attributed, end-to-end picture of LLMjacking as an organised industry: distributed scanning bots probing for exposed endpoints, scripts validating the credentials they find, and a commercial marketplace reselling access to more than 30 providers. An account with Claude 2.x could generate around 46,080 dollars a day in inference costs; with Claude 3 Opus the figure passed 100,000 dollars a day.

The 2026 leap is qualitative. As the Cloud Security Alliance research note sets out, the most sophisticated actors no longer stop at reselling tokens: they consume that compute to run automated offensive frameworks. Sysdig identified an exploitation framework, VAPT, that used a hijacked Ollama server as its reasoning engine to fingerprint services, match vulnerabilities and chain steps with no human between stages. It is the same trajectory we saw with MCP security for enterprise AI agents: automation stops being solely the defender's tool and becomes the attacker's too.

The figures, with their source

These are the verifiable data points behind the analysis, each with its origin:

  • Around 175,000 exposed Ollama instances across more than 130 countries, per the count reported by The Hacker News.
  • A 376% rise in credential theft aimed at AI services between Q4 2025 and Q1 2026, per Sysdig.
  • More than 35,000 attack sessions in Operation Bizarre Bazaar, with daily cost above 100,000 dollars when premium models were targeted, per BleepingComputer.
  • A resale marketplace offering access to more than 30 AI providers, per Sysdig.

A note on honesty: individual stories of bills leaping into the tens of thousands of dollars within hours circulate widely and cannot always be verified one by one. The numbers used above can, because they come from research with telemetry behind them.

Why traditional controls miss it

LLMjacking slips through the gaps of a security model built for something else. The cloud bill aggregates consumption and an inference spike dissolves among dozens of services; by the time anyone asks, the month has closed. AI API keys are rarely treated as critical credentials: they are issued with broad permissions, no expiry and no rotation. And shadow AI, the models and gateways a team stands up without going through security, appears on no inventory.

On top of that, the malicious activity looks a lot like the legitimate kind. Invoking a model is technically identical whether your application does it or an attacker with your key does. Without telemetry specific to identity, volume and origin, there is no signal to trip the alarm.

Operational detection

Detection rests on sources most organisations already have, only they do not read them with this threat in mind. The key is correlating identity, volume, origin and cost.

  • Provider invocation logs: InvokeModel events in Amazon Bedrock (CloudTrail), Azure OpenAI diagnostic logs and Vertex AI audit logs. Watch for invocations from identities, regions or network ranges that do not match your workloads.
  • Cost anomalies: billing alerts by threshold and by relative variation, not only monthly. A jump in inference spend over a few hours is one of the most reliable signals.
  • Monitoring of your own inference endpoints: anomalous request volume, automated patterns and content consistent with offensive tooling, such as heavily structured output contracts or chained-instruction markers.
  • Secrets detection: continuous scanning for AI keys in repositories, container images, logs and developer workstations, including IDE plugins and browser extensions.

This work sits squarely within the operation of a managed SOC and the threat intelligence that anticipates which of your organisation's credentials are already circulating in underground markets, which we address through Threat Intelligence.

Practical defence

The controls that genuinely cut exposure are concrete and testable:

  • Authentication in front of every model endpoint. Ollama and similar gateways do not ship with it: add it at a reverse proxy or the network layer, and never expose these services to the internet.
  • Non-human identity hygiene: short-lived keys, least privilege, project-scoped, automatic rotation and revocation within minutes. It is the same principle we apply to non-human identity security for service accounts, tokens and API keys.
  • Continuous discovery of what is exposed: knowing which of your inference servers, gateways and endpoints are reachable from outside before the attacker does, which is the job of attack surface management.
  • Hard budgets and quotas per project and per key, with automatic cut-off once the threshold is passed. It turns a 100,000-dollar incident into one of a few hundred.
  • Egress filtering and allow-lists: constrain which destinations and models each workload may call, so a stolen key is of little use outside its context.
  • Vulnerability management over the AI ecosystem itself: gateways, libraries and dependencies enter the same patch cycle as everything else, as set out in vulnerability management.

For organisations without the internal capacity to sustain this monitoring continuously, it makes sense to lean on a managed security service (MSSP) that folds detection, response and exposure management into a single operation.

Compliance implications

LLMjacking is not only a billing problem. When stolen compute is used to attack third parties from your identity, your organisation can end up caught in an incident it never started. Under NIS2, managing supplier and digital supply-chain risk is an explicit obligation, and a compromised AI gateway is precisely that: a link in the chain. For financial entities, DORA requires control of concentration and risk across technology providers, AI ones included. And in the public sector, national security frameworks demand access control and traceability that an open inference endpoint breaks at the root.

At a glance

AI compute has become an asset with a market price, and therefore a target. The defence is not to stop using models but to treat them for what they are: critical infrastructure with identity, telemetry, spend limits and a surface that must be known and reduced. Whoever puts authentication in front of every model, treats AI keys as first-class credentials and watches the bill the way they watch access logs will have shut the door most of these attacks currently walk through. The rest is a matter of time.

Frequently asked questions

What exactly is LLMjacking?

It is the unauthorised use of an organisation's AI capacity, either through stolen cloud-provider credentials such as Amazon Bedrock, Azure OpenAI or Google Vertex AI, or through self-hosted inference servers exposed without authentication. The attacker consumes your AI compute and the cost is billed to your organisation; in the most advanced cases they also use that capacity to power their own offensive tooling.

Why is exposing an Ollama server to the internet dangerous?

Because Ollama listens by default on port 11434 and ships with no authentication. A server of that kind reachable from the internet is free model capacity for anyone who finds it. Researchers have counted around 175,000 exposed instances across more than 130 countries. Authentication must be added at a reverse proxy or the network layer, and these services should not be reachable from outside.

How much can an LLMjacking incident cost?

It depends on the model and the time to detection. In Operation Bizarre Bazaar, an account with access to top-tier models could generate more than 100,000 dollars a day in inference costs. The difference between a scare and a disaster usually comes down to whether hard spend quotas and billing alerts by hourly variation existed, not only monthly close.

How do I detect that my AI models are being abused?

By correlating identity, volume, origin and cost. Review provider invocation logs (InvokeModel in CloudTrail for Bedrock, Azure OpenAI diagnostics, Vertex AI audit), set billing alerts by threshold and relative variation, and monitor your own inference endpoints for anomalous volume and automated patterns. A jump in spend over a few hours is one of the most reliable signals.

Do traditional security controls protect against this?

Only partly. The cloud bill dilutes consumption spikes across many services, AI API keys are rarely treated as critical credentials, and AI stood up without going through security appears on no inventory. Besides, invoking a model is technically identical whether your application does it or an attacker with your key does. Telemetry specific to identity, volume and origin is required.

How does LLMjacking relate to non-human identities?

Directly. The API keys, tokens and service accounts that grant access to models are non-human identities, and they are usually issued with broad permissions, no expiry and no rotation. Treating them as first-class credentials, with short lifetimes, minimal scope, automatic rotation and fast revocation, is one of the most effective defences against AI compute abuse.

Which compliance obligations touch this risk?

Under NIS2, managing supplier and digital supply-chain risk is an explicit obligation, and a compromised AI gateway is a link in that chain. DORA requires financial entities to control concentration and risk across their technology providers, AI ones included. In the public sector, national security frameworks impose access control and traceability that an open inference endpoint breaks.

Can stolen compute be used to attack other organisations?

Yes, and it is the most worrying evolution. The most sophisticated actors consume hijacked compute to run automated offensive frameworks that carry out reconnaissance, match vulnerabilities and chain steps with no human intervention. That means your compromised AI infrastructure can show up as the origin of attacks on third parties, with the legal and reputational consequences that carries.