Large language models (LLMs) have become another metered cloud resource. Organizations pay for model access, tokens, hosting, and compute. Attackers have recognized that stolen access can be monetized.
On November 2, 2026, Google Threat Intelligence Group and Mandiant described multiple incidents in which threat actors hijacked enterprise LLM access. In some cases, fraudulent consumption generated more than $100,000 in charges in one day with cumulative costs reaching $1 million, showing that LLMjacking is no longer theoretical.
Preventing it requires more than watching the AI bill, which comes after the breach has already occurred. Organizations must protect credentials, restrict access, limit authority, and monitor both authentication attempts and consumption spikes.
What is LLMjacking?
LLMjacking is the unauthorized use of an organization’s LLM services or infrastructure. Attackers obtain cloud credentials, service-account keys, API keys, personal access tokens, or authenticated sessions. They then consume the organization’s AI resources or proxy and resell that access while the victim receives the bill.
Sysdig introduced the term in 2024 after observing stolen cloud credentials tested against multiple hosted AI services. Mandiant has since found actors targeting exposed endpoints and valid credentials across providers.
LLMjacking is not prompt injection. While prompt injection manipulates an LLM’s instructions or outputs, LLMjacking compromises access to the model service.
The risks can overlap but require different controls.
How does an LLMjacking attack begin?
The most direct route is a stolen or exposed secret obtained through phishing, infostealer malware, a compromised developer device, a public repository, or an application configuration file. Long-lived keys also provide more time to validate and exploit access.
Misconfiguration creates another route. A self-hosted model, development interface, or gateway may lack effective authentication. Broad service-account permissions can let someone who compromises one workload enable LLM services, create keys, or reach other cloud resources.
Vulnerable applications and model-routing software can provide an initial foothold. Attackers may then search repositories, environment variables, secret stores, and configurations for more credentials. Mandiant has observed actors creating accounts and keys, changing policies, and establishing persistence.
Attackers can test a credential with a minimal request before beginning high-volume use. A response can confirm the key, available models, and quotas without an obvious consumption spike.
The impact extends beyond an unexpected cloud bill
Unauthorized token and compute consumption is the defining consequence.
Attackers can enable premium models, provision GPU resources, or route users through the victim’s account, exhausting quotas and degrading legitimate services. OWASP describes this broader risk as unbounded consumption.
Data exposure is possible but not automatic. An inference API key does not necessarily provide access to organizational documents. The risk depends on its permissions and connections to retrieval systems, storage, databases, applications, or workflows.
With broad cloud permissions, LLMjacking can become a wider intrusion. Attackers may enumerate services, harvest secrets, create persistent identities, access repositories, or misuse integrated tools. Poor separation between model access and cloud administration further increases the blast radius.
How can organizations prevent LLMjacking?
To prevent LLMjacking, organizations should prioritize securing AI credentials, enforcing least privilege, restricting access to LLM endpoints, and monitoring for unusual or unauthorized usage.
To reduce the risk of LLMjacking, organizations should:
- Inventory every hosted model, self-managed endpoint, gateway, integration, service account, and key. Disable unused services and remove unnecessary public exposure. Controls cannot protect AI resources the organization does not know exist.
- Keep secrets out of source code, application files, tickets, and collaboration channels. Use a centralized secrets manager and temporary credentials where supported. AWS recommends temporary credentials over long-term access keys and warns against placing keys in application or project files.
- Rotate keys regularly, but revoke, replace, and investigate a confirmed leak immediately. Repository scanning can identify committed secrets, while phishing-resistant MFA strengthens access to cloud consoles, repositories, and developer platforms. Train users to recognize and report credential-harvesting attempts.
- Apply least privilege to users, services, and LLM applications. Separate development and production identities. Scope keys by model, endpoint, environment, and operation. An inference credential should not administer identities, billing, services, or unrelated resources.
- Limit LLM and agent permissions. An assistant using one knowledge base should not receive general cloud storage, administrative API, or external network access. Restrict agent tools separately and require approval for sensitive actions.
- Keep private AI endpoints, gateways, and supporting systems off the public internet where possible. Allow only approved users, devices, workloads, and pathways. Restrict outbound communication to necessary destinations to reduce unauthorized relays and exfiltration.
- Monitor usage and control-plane changes. Establish normal token, model, user, geography, and time patterns. Alert on new keys, enabled services, quota changes, unfamiliar SDKs, unexpected regions, and logging changes. Watch small validation requests and consumption spikes. Use quotas, rate limits, and budget alerts as containment—not substitutes for access control.
How ThreatLocker can reduce LLMjacking exposure
ThreatLocker helps reduce LLMjacking exposure by enforcing Zero Trust controls over access to AI resources, application execution, network connections, and agentic permissions. These policies limited what users, applications and agents can access and do, reducing opportunities for credential abuse and unauthorized activity.
ThreatLocker provides several layers of protection:
- Zero Trust Network Access can restrict private LLM endpoints, gateways, administrative interfaces, and supporting systems to authorized users on approved devices. Policies specify permitted resources, ports, and protocols without exposing internal services through open inbound ports. For designated cloud and SaaS services, Zero Trust Cloud Access adds device verification.
- Application Allowlisting and Ringfencing™ can limit which local tools and scripts execute, which applications access stored secrets, and where they connect.
- For agentic workflows, Zero Trust AI Control can maintain application, data, execution, and network boundaries as the agent invokes other processes.
These controls complement secrets management, MFA, audit logs, rate limits, and provider monitoring.
LLMjacking begins with access, but its impact is determined by authority. Protect the credentials, narrow the permissions, restrict the pathways, and continuously verify how AI resources are being used.
Frequently asked questions
Is LLMjacking the same as prompt injection?
No. LLMjacking is the unauthorized use of LLM access or infrastructure, usually through stolen credentials or exposed endpoints. Prompt injection attempts to alter how a model or agent follows instructions.
What are the signs of LLMjacking?
Possible indicators include unexplained token consumption, unfamiliar models or regions, new API keys, unexpected service enablement, unusual SDKs, quota changes, and small validation calls followed by high-volume use. Cloud audit logs and model gateway logs should be reviewed together.
Can rotating API keys prevent LLMjacking?
Rotation reduces the useful lifetime of a leaked long-term key, but it is only one control. Temporary credentials, least privilege, secret scanning, device-aware access, usage limits, and monitoring provide stronger coverage across the attack path.
What should an organization do after discovering LLMjacking?
Revoke affected keys, tokens, and sessions immediately. Disable unauthorized services or identities, review cloud and repository logs, search for newly created credentials and persistence, determine what data or systems were accessed, and preserve evidence for incident response.
