LLMjacking: Stolen-Key Cost Abuse Against Enterprise LLM Endpoints
What LLMjacking is
LLMjacking is the theft of cloud LLM credentials to run inference at the victim's expense. The term was coined by Sysdig's Threat Research Team in 2024 to describe a fast-growing pattern: attackers obtain a set of cloud LLM keys, confirm which models the account can reach, and then drive high-volume inference through the victim's account. The victim discovers it as an unexplained, often eye-watering, line item on the monthly bill. It is best understood as cloud-resource abuse aimed precisely at the model-invocation layer - the same economic logic as cryptojacking, pointed at expensive frontier models instead of compute.
The mechanics are unglamorous, which is part of why it works. There is no exotic exploit. The attacker needs a valid credential and a reachable endpoint, and the rest is ordinary API traffic. That makes LLMjacking a credential and visibility problem far more than a vulnerability problem, and it puts it squarely in the same territory as broader LLM gateway and proxy security.
How the attack unfolds
The lifecycle is consistent across reported cases. First, credential acquisition. Attackers harvest keys from leaked or exposed API keys in public code, keys committed to config or environment files, and compromised cloud credentials that happen to carry LLM permissions. Second, reconnaissance: the intruder probes the account, frequently with non-invasive calls, to learn which models are enabled and what the usage limits look like. Third, monetization: the attacker drives high-volume inference, often from new regions, either using the access directly or reselling it to others as a cheap gateway to premium models.
The exposure is amplified by how modern AI tooling handles keys. Agents and skills frequently read plaintext LLM keys straight from endpoint configuration - a dotfile, an environment variable, a tool manifest - rather than fetching a short-lived token from a vault. Every laptop and server that runs such an agent becomes another place a high-value key sits in the clear, far outside the reach of a central secrets manager or an LLM gateway. This is the same over-exposure pattern covered in secrets management for AI agents, and it is why endpoint-level discovery matters.
Why it is an agentic-endpoint risk
LLMjacking looks like a billing problem, but its root cause lives on the endpoint. A stolen key almost always originates from a copy of that key that nobody was tracking: a developer's local config, a skill bundle that ships credentials, a CLI that caches a token in plaintext. This is the artifact layer that traditional controls were never built to see. A network monitor sees ordinary HTTPS to a legitimate model API. A DLP tool sees no obvious data leaving. The malicious signal is economic - who is calling which model, how often, from where - and it only becomes legible when you can tie usage back to the identities and keys scattered across the fleet.
It is also a textbook case of AI as the new shadow IT. Teams wire an LLM key into an agent to ship a feature quickly, the key gets copied into a config file, and no one in security ever inventories where it landed or what it can reach. When the abuse starts, the first question - which key was stolen and from which endpoint - is unanswerable without an inventory that was never built. Least privilege on those keys, covered in least privilege for AI agents, bounds the damage, but only if you know the keys exist.
Detection signals
LLMjacking is noisy in the right dimension if you are watching it. The strongest signals are behavioral and economic rather than signature-based. The table maps each observable signal to what it tends to indicate.
| Detection signal | What it indicates |
|---|---|
| Sudden cost spike on the LLM bill | High-volume inference driven by someone other than your workloads |
| Unusual model-invocation volume | Automated abuse or resale traffic, not organic application load |
| Calls to models the account never used before | An attacker enabling and exercising premium models after reconnaissance |
| Access from new regions or IP ranges | Use of the stolen key from attacker infrastructure or a proxy pool |
| Non-invasive probing of enabled models | Early-stage reconnaissance before monetization begins |
| Quota or rate-limit exhaustion | Abuse crowding out legitimate service, sometimes the first user-visible symptom |
None of these is individually conclusive - a legitimate new feature can drive volume up, and a traveling engineer can appear from a new region. The signal is in the combination and the timing. Budget and quota alarms tuned to model usage give you the earliest, cheapest warning, because cost is the metric the attacker cannot hide.
Mitigations
The defensive stack is a mix of key hygiene, blast-radius reduction, and monitoring. None of it is exotic; the difficulty is applying it consistently across every endpoint that touches an LLM key.
- Key hygiene and rotation. Rotate LLM API keys on a schedule and immediately on any suspicion of exposure. Scan repositories and config for committed keys and treat any found key as burned.
- Least privilege on LLM keys. Scope each key to the minimum models and operations it needs, and issue distinct keys per workload so one theft does not expose everything. Prefer short-lived tokens over static long-lived keys where the platform supports it.
- Budget and quota alarms. Set hard spending caps and per-model quotas, and alert on deviations from baseline so a cost spike pages someone within hours, not at month-end.
- Egress controls. Restrict which hosts and regions can call your LLM endpoints, and constrain outbound paths so a stolen key cannot be exercised from arbitrary attacker infrastructure.
- Monitor model-invocation patterns. Baseline normal model usage and alert on new models, volume anomalies, and access from unfamiliar regions or IPs.
- Keep keys off the endpoint in plaintext. Move agents and skills away from reading raw keys out of config toward brokered, short-lived credentials so there is no static key on the laptop to steal.
A related supply-chain risk worth pairing with this work is slopsquatting and hallucinated package installs, because a malicious dependency pulled into an agent is one of the ways a plaintext key gets exfiltrated in the first place.
How Anomity surfaces and governs it
Every mitigation above shares a precondition: you have to know where your LLM keys live and which agents, skills, and CLIs read them. That is discovery work on the endpoint, and it is where Anomity sits. Anomity runs a lightweight, unprivileged Endpoint Sensor on every managed endpoint and inventories eight AI artifact types - agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs - so the plaintext keys that agents and skills read from config become visible before an attacker finds them. Secrets are redacted on the endpoint and only metadata leaves the host over HTTPS, so discovery never creates a new copy of a key to steal.
On agents that expose a hook, Anomity applies runtime governance, returning allow, deny, or log on each tool call before it runs, so a model-invoking call that falls outside policy can be stopped rather than billed. Continuous policy evaluation routes violations to your SIEM, Slack, email, and Jira, and every added, removed, or modified artifact lands in a queryable 90-day audit trail - the exact record you need to scope which key was exposed, on which endpoint, and for how long. None of this replaces your LLM gateway, cloud cost alarms, or key-rotation discipline; it complements them by making the endpoint-level exposure visible in the first place.
You can't govern what you can't see.The Anomity principle
For the wider context, pair this advisory with securing LLM gateways and proxies, non-human identity governance, and least privilege for AI agents. To see where plaintext LLM keys live across your own fleet and what runtime governance would deny, book a 30-minute demo.
Frequently asked questions
What is LLMjacking?
LLMjacking is a term coined by Sysdig's Threat Research Team in 2024 for attacks where adversaries steal cloud LLM credentials and abuse the victim's model access to run their own inference. The victim pays the bill while the attacker gets free access to expensive models. It is functionally cloud-resource abuse aimed specifically at the LLM API layer rather than at compute or storage.
How do attackers get the keys in the first place?
The common sources are leaked or exposed API keys in public repositories, keys hardcoded in config or environment files, and compromised cloud credentials that carry LLM permissions. Once inside, attackers often probe non-invasively to learn which models are enabled on the account before they start driving traffic. This reconnaissance step is itself a useful detection opportunity.
What is the actual business impact?
The most immediate impact is cost. Sustained abuse of high-end models can generate unexpected bills reaching thousands of dollars per day. Beyond the bill, attackers use the stolen access as a proxy or resell it to others, and the extra load can exhaust your quota and disrupt legitimate service.
How is LLMjacking different from normal cloud account compromise?
It is a specialization of it. Classic cloud abuse tends to spin up compute for cryptomining or exfiltrate data. LLMjacking targets the model-invocation surface specifically, so the tell-tale signs are model-usage anomalies - new models, volume spikes, new regions - rather than new EC2 fleets or storage reads. Many general cloud alarms will miss it because the API calls look superficially legitimate.
Why do AI agents and skills make LLMjacking worse?
Agents and skills frequently read plaintext LLM keys directly from endpoint configuration files rather than from a central secrets manager. That scatters copies of high-value keys across laptops and servers, well outside the view of any vault or gateway. Every endpoint that holds a plaintext key is another place a stolen credential can originate, which is why the endpoint is where discovery has to happen. See secrets management for AI agents.
What are the best detection signals for LLMjacking?
Watch for cost spikes on the LLM bill, unusual model-invocation volume, calls to models that account has never used before, and access from new regions or IP ranges. A single one of these can be benign; several together strongly indicate abuse. Budget and quota alarms tied to model usage give you the fastest early warning.
How does Anomity help with LLMjacking?
Anomity inventories eight AI artifact types on every managed endpoint - including secrets and the CLIs, agents, and skills that read them - so it surfaces where plaintext LLM keys live before an attacker finds them. Secrets are redacted on the endpoint and only metadata leaves the host, so discovery never adds a new copy of a key. On agents that expose a hook it can allow, deny, or log model-invoking tool calls before they run, and every change lands in a queryable 90-day audit trail for scoping an incident.
