For the past few years, one topic has constantly been on the minds of tech professionals around the world: AI.
AI is no longer just another piece of the tech stack but is fast becoming its foundation. Major business features, like customer support and data analysis pipelines, are being shifted to Large Language Models (LLMs), and businesses are more dependent on LLMs every day. That dependency has not gone unnoticed by attackers. As LLMs become more central to core business processes, they have become a valuable target in their own right.
This article explains how LLMjacking works, the potential risks and costs associated with an attack, and what you can do to detect and prevent it.
What Is LLMjacking?
LLMjacking involves attackers hijacking access to your LLM. Although the widespread adoption of LLMs is a relatively recent development, LLMjacking itself is just a different spin on a familiar attack: Gaining access to stolen or exposed credentials. Before the LLM era, criminals used to look for AWS or GCP access keys, which could potentially give them access to compute resources, storage, and sensitive company information.
The repercussions from stolen and exposed credentials are bad enough, but LLMjacking has the potential to cause significantly more harm (financial or reputational) to both an organization and its clients. LLM usage is often metered and expensive, so abuse can translate directly into financial impact. If the key is tied to custom models, internal prompts, or sensitive data pipelines, the risk is no longer solely about compute resources. Unlike a stolen cloud key, a compromised LLM credential can give an attacker access to far more than raw data.
What Harm Does LLMjacking Cause?
The impact of an LLMjacking incident goes beyond unexpected API usage or inflated billing. It can very quickly escalate into a significant financial loss, disruption of day-to-day operations, and exposure of sensitive company or customer data.
Understanding these risks in detail is important because the potential consequences extend across multiple aspects of your business.
Financial impact of LLMjacking
This is usually the first place where you notice that "something is wrong". If you see the impact of LLMjacking in your bills, it is likely that the attack has already done significant damage. An attacker with unfettered access to your LLM API could easily have used it to spin up spam email templates, phishing sites, and even malware for their own nefarious purposes.
If you have usage and billing limits, you might think you are safe. There is only so much an attacker could do with your LLM, right? However, any downstream agentic processes or automated workflows dependent on the LLM will also be affected. This could have an even bigger financial impact on the organization, especially if those processes are tied to critical business functions.
Malicious use of custom models
Some organizations rely heavily on custom models, usually trained on internal documents and business processes to help the model better understand how your organization operates. Increasingly, these kinds of models are being used for new and existing employees as a kind of "wiki". If you are not sure what to do with a specific document or which employee to speak to about a specific situation, just ask the LLM using the custom model.
Should an attacker gain access to this model, however, they could gain knowledge about your organization that was never intended to be public. This kind of information could be used to further extend their foothold on your network, or it could allow an attacker to sell this information on the dark web.
Data poisoning
In some environments, these same custom models are constantly being refined and trained using new organizational or financial data. Should an attacker gain access to the training data or the method used to train your custom models, it can create opportunities for data poisoning.
An attacker could gradually influence the model over time to provide misleading or biased responses to employees. While this is a more time-consuming exercise, it allows them to nudge decisions, surface false information, or steer internal processes. Any changes made to the model are usually very subtle and therefore difficult to detect.
Different Attack Vectors
As discussed before, LLMjacking is not really something new. These attack vectors are similar to the ones already employed by attackers for getting AWS/GCP/Azure access. The difference is that these API keys to your LLMs have the potential to create more harm for your organization.
In practice, LLMjacking typically involves an attacker obtaining an API key through phishing, source code leaks, misconfigured environments, or exposed client-side code.
Good old phishing
Despite increasingly sophisticated AI-assisted attacks, attackers still rely on one of the oldest tricks in the book: convincing someone to just hand over their credentials. Phishing campaigns remain a highly effective way to gain access to LLM resources, as these campaigns target people rather than technology.
A well-crafted phishing page is probably the easiest way that most attackers would gain access to your credentials. All of the old tactics still work: creating a false sense of urgency or spoofing platform notifications, all of which are designed to pressure a user into acting quickly.
Bad cloud or application configurations
Misconfigured cloud environments continue to be one of the easiest ways for attackers to obtain sensitive credentials, and LLM integrations are no exception. API keys are often stored in environment variables, configuration files, container images, CI/CD pipelines, or logging systems that were never meant to be publicly accessible. Overly permissive S3 buckets, an exposed Kubernetes dashboard, or a poorly secured Git repository can hand attackers everything they need without requiring them to exploit a vulnerability directly.
The speed at which LLM integrations are being deployed in the modern tech stack makes the potential impact of this attack vector even worse. Teams will frequently prioritize function over security best practices. This is exactly how credentials end up getting leaked, giving potential attackers free, unadulterated access to your LLMs.
How Do You Monitor and Detect LLMjacking Attacks?
Detecting an LLMjacking incident is less about spotting a single obvious breach (although you should still be on the lookout for those) and more about identifying unusual patterns of usage.
Stolen API keys are often used in ways that mimic legitimate usage, which could make it harder for traditional security monitoring tools to spot the anomalies.
Baseline your organization's LLM usage first
Before you can detect abnormal behavior, you need to know what "normal" looks like for your organization. This means establishing a baseline of API request volumes, token consumption, and common API endpoints. This baseline should also be established across different time periods. Do you normally have usage spikes on month-end? What about every second Tuesday?
A solid baseline can help distinguish between organic usage changes and potential abuse. This baseline should be used to constantly compare against current usage patterns, and anomalies should be investigated as soon as possible to determine whether it was legitimate usage spikes or something more nefarious.
Monitor billing usage alerts
A billing usage alert will probably be the first sign of something other than "normal" happening inside your environment. If attackers are blending in and abusing your LLMs in a "low and slow" manner, you might not be able to pick it up.
However, most attackers will probably try to use your LLM resources as much as possible, for fear of losing access before they have been able to do what they need to do. This will inevitably trigger billing usage alerts, in which case, you should investigate and act as soon as possible.
How Do You Defend Against LLMjacking?
Defending against LLMjacking is largely about making the credentials harder to obtain in the first place. Since the attack typically relies on valid API keys rather than exploiting the model itself, traditional firewalls and other security hardware do not really feature here. Instead, effective defense relies on a combination of strong credential management, tight access controls, and continuous visibility into how those credentials are being used across your systems.
Enforce good credential hygiene
This is one of the most effective ways to limit the impact of an LLMjacking incident. It reduces the window of opportunity an attacker has if one of your keys is exposed. Regularly rotating API keys ensures that any leaked credentials have a limited lifespan.
Workload-specific keys add another important layer of containment. Instead of one shared credential granting broad access across multiple services, each application, service, or environment gets its own narrowly scoped identity. This should make abuse much easier to detect and isolate, since unusual usage can be traced back to a specific workload rather than blending into general traffic.
Workload-specific keys also have the added benefit of reducing the blast radius of a compromised key. These keys should only have access to specific endpoints for a specific set of operations.
Apply the principle of least privilege
Workload-specific keys are one way of achieving the principle of least privilege. Applying the principle of least privilege is really about resisting the temptation to give every integration a "just in case" level of access. If a single API key can reach multiple models, environments, or downstream systems, whoever steals it effectively inherits far more capability than that key should ever have had in the first place.
These same principles should be applied to your human users as well. Does Carol from marketing really need access to production prompts, customer data pipelines, and your fine-tuned legal summarization model? Probably not. Again, by tightly scoping permissions to specific workloads, endpoints, and even models, you ensure that a compromised key will limit the capabilities an attacker might gain from that key.
Basic security principles
Sometimes we forget that the basics can also help to protect you from LLMjacking attacks. LLMjacking is not a fancy new exploit that threatens to bring down your entire organization. The following points will help strengthen your overall security posture and help you detect and prevent LLMjacking incidents.
- Use a proper secrets management platform, like Hashicorp Vault. This is especially useful for automating the rotation of workload-specific keys so as to minimize the usefulness of a compromised key.
- GitHub enables push protection by default on all repositories, blocking commits containing secrets before they ever reach your codebase. Make sure it has not been disabled in your repository settings. This does not mean secrets cannot slip through. If that does happen, treat that secret as compromised and rotate it immediately.
- Centralize your audit and access logs, for example, using a SIEM solution. This can help to create your initial baseline as well as monitor for anomalies, all from a centralized location.
LLMjacking Is New; The Vulnerabilities It Exploits Are Not
Resource hijacking is a familiar story to many a cybersecurity professional. Attackers steal credentials and exploit them for their own gain at the victim's expense. LLMjacking is just one of the newer chapters in that story, and one with potentially higher stakes than what came before it. With LLMjacking, attackers get the same level of access as your systems and employees. This can lead to financial harm and risks exposing your company's and customers' sensitive data.
This threat is particularly concerning because of how deeply LLMs are embedded in modern tech stacks. They are no longer isolated tools, but components that influence decisions, automate processes, and interact with data in real time.
Defending against LLMjacking does not require newfangled security mechanisms; it requires getting the basics right. Treat those API keys as high-value assets, limit their scope, and monitor their usage with intent. While the technology behind those keys is new, the weak points being exploited are well known and well understood.
About the author
Thinus Swart
Cybersecurity Specialist