LLMjacking and the AI workloads nobody inventoried

The problem

LLMjacking does not need a vulnerability. It needs a credential with model permissions — a long-lived access key in a repository, a stolen OAuth token, a CI runner's role — and after that it is a bill.

The attacker validates the key, enumerates the models the account can reach, then invokes. From the attacker's side this is cheap and deniable: the calls are indistinguishable from your own application's traffic by method and endpoint alone, and the first symptom most organisations see is spend.

The LiteLLM 1.107.0 compromise in October 2026 is the reference case. Stolen GitHub CLI OAuth tokens belonging to three engineers were used to publish a poisoned release from a lookalike repository, the payload carried a 16-module stealer, and the follow-on used the harvested cloud credentials to call sts:GetCallerIdentity and bedrock:ListFoundationModels — a validate-then-enumerate sequence against a model API that took minutes and was detected by nobody until the incident was written up.

How Hanu approaches it

Cost is a bad primary signal

Spend is aggregated, delayed, and dominated by legitimate variation. A retry storm and a hijacked key are the same shape on a cost chart, and by the time the chart moves the credential has been in use for days. What separates them is behaviour at the credential, minutes after first use.

Two stages, in order, inside a window

LLM_JACKING_ACTIVITY requires a sequence rather than an event: a credential that is new to this account validating, then model enumeration or invocation within twelve hours, with at least two distinct stages observed. Requiring the second stage is what keeps the signal quiet — a new deployment that starts calling a model API produces exactly one stage and no incident.

AI workloads as discovered inventory

Inventories of model endpoints, agent credentials, vector stores and prompt templates are usually maintained by hand, which is another way of saying they are wrong. Hanu treats them as discovered resources: the model services reachable from each account, the identities that can reach them, and how many assumption hops separate those identities from something that matters.

What you get

Limits

We do not read your prompts or your completions. Inference payloads are not collected, so the platform cannot tell you what data left. It can tell you which identity called which model endpoint, when, and from where — which is the set of facts that determines containment.

Coverage is cloud-side. Calls originating from a gateway you host are visible to the extent that the gateway's logs are connected; a model API key used entirely outside your cloud accounts is outside this view.

There is no model-quality or prompt-injection scoring here. Prompt-injection surface is a design problem in the application that consumes the model, and a cloud collector has no standing to measure it.

Oracle Cloud is not supported, so model access on OCI is not covered.

Questions