Your Business Could Be Paying for Hackers' AI Usage: Understanding LLM-Jacking
An API key forgotten in a Git repository, development tool or configuration file may allow someone else to use your AI services. This threat, known as LLM-jacking, is becoming more prominent in 2026.
Imagine this situation.
Your company uses artificial intelligence to automate certain tasks.
A developer has integrated an API into an internal application.
The service works well.
Nobody thinks much about it.
Then, one day, someone notices unusual AI resource consumption.
API calls are increasing.
Quotas are running down.
Processes appear to have been executed even though no employee requested them.
The problem is not necessarily a software bug.
Someone else may be using your AI resources without your knowledge.
This scenario has a name: LLM-jacking.
And it is no longer just a theoretical risk.
What Google Observed in 2026
In an analysis published in September 2026, Google Threat Intelligence Group described a shift in cybercriminal activity targeting artificial intelligence environments.
Attackers are no longer interested only in stealing documents or conventional passwords.
They are also targeting AI service accounts, developer credentials, API keys and cloud computing resources.
Google reported cases in which compromised cloud environments were hijacked to run unauthorised AI workloads.
CERT-EU also highlighted this trend in its bulletin published on October 2, 2026.
In other words, AI access itself is becoming a valuable target for cybercriminals.
Source: Google Threat Intelligence — September 2026
An API Key Is Not Just Another Line in a File
For many developers, an API key is simply another technical component.
A string of characters in a configuration file.
An environment variable.
A secret stored in a CI/CD tool.
But that key may represent genuine access to a billable service.
If it is exposed, and the provider's controls allow it, someone else may be able to consume the associated resources.
The consequences depend on the service: quota consumption, unexpected charges, misuse or access to certain resources authorised by the key.
That is exactly why a technical secret must be treated as a sensitive credential.
How Are These Keys Stolen?
There are several possible scenarios.
A developer accidentally publishes a secret in a Git repository.
A workstation is infected with information-stealing malware.
A .env file is exposed.
A CI/CD system provides access to sensitive variables.
A backup or application log contains credentials.
Or an AI coding assistant stores authentication information in its configuration files.
This last scenario is not imaginary.
In 2026, Google documented malware operators showing interest in the configuration files of AI coding assistants, which may contain API keys.
The problem is therefore not limited to AI itself.
It includes the entire access ecosystem surrounding it.
Why SMEs Are Also Affected
It might seem that only major AI laboratories have to worry about this.
Yet a small business can now use several AI services without having a specialised team.
A sales chatbot.
A support assistant.
A CRM integration.
A document-generation tool.
An AI coding agent.
Internal scripts connected to external models.
Every integration may create a new technical access point.
And when nobody is responsible for monitoring its security, that access can remain active for far too long.
The Risk Goes Beyond the Bill
Unauthorised resource consumption can generate additional charges, depending on the provider's pricing model.
But the problem does not end there.
A compromised key may reveal much broader weaknesses.
Who created the key?
Why does it have those permissions?
Is it shared by several applications?
Can it be revoked without stopping production?
Is its activity recorded in logs?
If nobody can answer these questions, the risk goes far beyond AI consumption.
It reveals a problem with technical identity management.
Five Practical Ways to Reduce the Risk
1. Inventory Your AI Services
Start by identifying the platforms in use, the associated accounts and the applications consuming their APIs.
Do not forget pilot projects and tools used only by developers.
2. Look for Exposed Secrets
Review code repositories, CI/CD pipelines, configuration files and secrets-management systems.
The review should cover both current secrets and those that may appear in the code history.
3. Limit Permissions
Where supported by the provider, use separate keys for each application and restrict their privileges as much as possible.
Avoid sharing one credential across ten different services.
4. Monitor Usage and Costs
Configure consumption alerts, budget thresholds and the available usage logs.
An unusual spike may be an early warning.
However, malicious activity can also remain below normal thresholds. Billing alerts alone are not sufficient.
5. Prepare a Revocation Procedure
If a key is compromised, you need to be able to disable it, replace it in affected applications and review how it was used before revocation.
Key rotation should be planned to minimise service disruption.
The Test Every CTO Should Run
Ask your team:
"If an API key for our main AI service was stolen today, how long would it take us to detect the theft and revoke the key?"
A reliable answer requires three things.
Knowing which keys exist.
Knowing where they are used.
Having logs that allow unusual activity to be identified.
Without this information, the company is relying on luck.
Visibility Is Becoming as Important as Protection
Businesses are rapidly adding new AI tools.
But they do not always expand their monitoring capabilities at the same pace.
And that is exactly the problem.
At Cyberhack, we advocate an approach in which every new critical service becomes part of the risk inventory, with clearly identified responsibilities and verifiable controls.
The objective is not to slow down AI adoption.
It is to avoid introducing access that nobody is monitoring.
To understand this approach better, you can explore Cyberhack Platform.
Conclusion
LLM-jacking shows that artificial intelligence creates new assets that need protecting.
Models, API keys, developer credentials and cloud resources now have direct value for cybercriminals.
The danger is not necessarily visible.
Your application may continue working while someone else consumes some of your resources.
That is why the question is no longer simply:
"Are our employees using AI securely?"
It becomes:
"Do we really know who is using our AI services, what permissions they have, and how we would detect unauthorised use?"
