An attacker doesn’t need to hack an AI model to steal its value. Sometimes, all they need is the API key.
LLMjacking is the unauthorized use of large language models through stolen credentials, compromised cloud accounts, exposed API keys or unprotected model infrastructure. Instead of paying for access to expensive AI models and compute, attackers use somebody else’s account. The victim gets the bill. The attacker gets the AI.
As organizations put LLMs into products, development workflows, internal tools and automated agents, the credentials that provide access to those models are becoming valuable targets themselves. An OpenAI API key, Anthropic credential or cloud token with access to AWS Bedrock can effectively become a transferable unit of AI compute.
For security teams, that makes LLMjacking part of a much larger problem: the theft of Non-Human Identities (NHIs) from employee endpoints.
What Is LLMjacking? #
The term LLMjacking was introduced by Sysdig researchers in 2024 after they observed attackers using stolen cloud credentials to access cloud-hosted LLM services. Their tooling checked credentials against multiple AI providers and cloud services to determine which models were available, what quotas the compromised account had and whether the credentials could be used for unauthorized inference.
The economics can be significant. Sysdig calculated that one worst-case configuration involving unauthorized Claude usage through AWS Bedrock could produce more than $46,000 in model-consumption costs per day for the victim. Researchers also found evidence of reverse proxies being used to provide others with access to compromised AI accounts, suggesting that stolen LLM access could itself be monetized.
The original version of LLMjacking was essentially resource theft: steal someone else’s credentials, use their AI services and leave them with the cost.
Since then, the concept has expanded.
In June 2026, Sysdig documented an attacker using exposed AI compute as the reasoning engine for a multi-stage offensive security tool. The system scanned targets, matched services to vulnerabilities, generated proof-of-concept exploits and attempted to compromise systems while an LLM made decisions throughout the process. That incident involved an exposed Ollama server rather than a stolen API key, but it showed how stolen or unauthorized AI resources can be used for much more than free chatbot access.
LLMjacking can now mean stealing AI resources to run automated workloads, operate offensive tooling, resell access, analyze data or consume expensive inference at somebody else’s expense.
The LLMjacking Attack Can Start on an Employee Laptop #
When organizations think about leaked AI credentials, they often think about source-code exposure. A developer accidentally commits an API key to GitHub, a secret scanner discovers it and the key is rotated.
That is an important control, but it addresses only one way machine credentials leave an organization.
Infostealer malware attacks the endpoint itself.
Developer and administrator workstations frequently contain .env files, command histories, CLI credentials, configuration files, cached application data, local projects and temporary scripts. Those files can contain OpenAI or Anthropic API keys, AWS credentials, GitHub personal access tokens, OAuth tokens, service-account credentials and other secrets.
Modern infostealers use broad file-grabber modules that collect large amounts of data from infected machines. Machine credentials can therefore end up inside stealer logs even when the secret was never committed to a repository or intentionally shared outside the organization.
We wrote about this problem in more detail in The Token Haystack: Parsing and Verifying Exposed Tokens in Stealer Logs. The challenge is not simply recognizing a token-shaped string. Security teams need to identify what service the credential belongs to, connect it to the compromised employee or endpoint, preserve the surrounding forensic evidence and determine whether the credential is still usable. Lunar’s token-monitoring system was built around exactly that problem.
For an AI credential, the result can be a direct path from an infected developer laptop to unauthorized model usage.
Why Password Resets and MFA Don’t Stop LLMjacking #
Imagine that a developer becomes infected with an infostealer. The security team follows the normal response process: isolate the workstation, reset the employee’s password, terminate browser sessions and require the employee to authenticate again using MFA.
That may secure the employee’s human identity. It does not necessarily revoke the OpenAI API key sitting inside a local .env file.
API keys and many other machine credentials have authentication lifecycles that are independent of the user’s corporate password. If the credential remains valid, an attacker may continue presenting it directly to the issuing API without logging in as the employee again.
There may be no password prompt and no new MFA challenge. From the AI provider’s perspective, the request may simply contain a valid credential.
This is why Lunar’s approach to Stolen Access Token & Secret Monitoring treats machine credentials as a separate exposure category. Lunar analyzes collected infostealer data for API keys, OAuth tokens, personal access tokens, cloud credentials and other machine secrets, then adds the service, validation and endpoint context security teams need to investigate them.
A modern infostealer incident therefore needs to answer another question after passwords and browser sessions have been handled: What machine credentials were stolen from the same computer?
From Stolen Token to LLMjacking #
Consider a simple scenario. A developer is building an internal application that uses an LLM API. The application reads its API key from a local environment file. The developer’s workstation becomes infected by an infostealer, and that environment file is collected by the malware.
The attacker now has a credential that may provide direct programmatic access to the company’s AI account.
The next step is relatively simple: determine whether the credential still works and what access it provides. If it remains valid, the attacker can begin consuming the service using the victim’s account.
The first sign the organization notices may be unusual API traffic, exhausted quotas or an unexpected bill.
This creates a detection gap between secret exposure and secret abuse. API monitoring may eventually detect abnormal usage, but by that point the stolen credential is already being used.
Finding the credential inside stolen infostealer data creates another opportunity to respond: rotate the key, inspect its usage and investigate the compromised endpoint before the exposure becomes—or further develops into—an LLMjacking incident.
How Lunar Finds Stolen AI Tokens #
Lunar’s NHI capability extends compromised-credential monitoring beyond usernames and passwords and into machine-to-machine credentials.
The system analyzes infostealer data for exposed machine credentials, including API keys, OAuth tokens, personal access tokens, cloud credentials and service-account secrets. For supported credentials, Lunar can identify the issuing service and check the credential’s status against that service. A verified result means the credential was active when it was checked.
Just as important is the surrounding evidence. A random API key by itself does not tell an analyst whose credential it is or how it was exposed. Lunar connects the finding to the available context from the compromised endpoint, such as associated identities, file paths, malware information and surrounding log data.
For AI providers, this can turn an anonymous leaked string into a concrete security finding: an AI credential associated with a particular compromised endpoint was captured by malware and was active when checked. Our technical breakdown in The Token Haystack shows examples of this process for OpenAI credentials alongside GitHub tokens, AWS access keys and payment API keys.
This matters because the same endpoint infection rarely exposes only one secret. A developer machine containing an AI API key may also contain cloud credentials, GitHub PATs, SSH keys, database credentials or other tokens. The AI key may be the beginning of the investigation rather than the end.
LLMjacking Is Really an Identity Problem #
LLMjacking is usually categorized as an AI security problem, but underneath it is an identity problem.
The attacker has obtained a credential representing a user, application, workload or service and is using the permissions assigned to that identity. The fact that the resource behind the credential happens to be an LLM does not fundamentally change the authentication problem.
The same pattern applies elsewhere. A stolen GitHub token can provide access to private repositories. An AWS access key can expose cloud infrastructure. A payment API key can create financial or data risk. An AI API key can provide access to paid inference, proprietary applications and increasingly capable AI systems.
The common element is the machine identity.
This is why traditional compromised credential monitoring is expanding beyond passwords. Infostealers increasingly collect the broader set of authentication artifacts available on an endpoint: passwords, browser sessions, API keys, OAuth tokens and other machine credentials.
Security teams already assume that a password recovered from an infostealer log has been compromised. The same logic needs to apply to machine credentials.
The Infostealer Response Playbook Needs to Change #
A typical infostealer response focuses heavily on the human identity. Security teams reset passwords, invalidate sessions, review MFA and rebuild the infected endpoint.
Those steps remain necessary, but they do not cover everything modern infostealers take.
In The Missing Infostealer Playbook: Rotating the Machine Credentials Attackers Take, we argue that machine-credential discovery needs to become a standard stage in infostealer incident response. A compromised workstation should trigger a search for API keys, cloud credentials, OAuth tokens, PATs, service-account credentials and other secrets that may have been copied along with the employee’s passwords and cookies.
When an exposed AI credential is found, the immediate priority is to revoke or rotate it. The security team should then examine API and billing activity from the relevant period, look for abnormal model usage, identify what permissions the credential carried and determine whether the same infected endpoint exposed other machine credentials.
A token found in infostealer data should be treated as compromised even when no evidence of LLMjacking has yet been found. Absence of observed abuse is not evidence that the credential remained private.
Find the Token Before Someone Else Uses It #
LLMjacking shows why securing AI infrastructure cannot stop at prompt security, model controls and application-layer defenses. The credentials that unlock those systems matter just as much.
An attacker who steals an active AI API key may not need to defeat MFA, exploit the AI application or compromise the model. The credential itself can provide the access.
And that credential may already be sitting inside an infostealer log taken from an employee workstation.
Lunar’s Non-Human Identity and Token Exposure Monitoring is designed to find that missing piece. It identifies machine credentials captured by infostealers, adds the context needed to understand their source and, for supported services, verifies whether the credential was active when checked.
Because the best point to stop an LLMjacking incident is not after the AI bill arrives. It is when the stolen key first becomes visible.