Imagine the bill from your company's AI provider arrives at the end of the month and it is ten times higher than usual. Nobody on the team has been using the assistant more. What has happened is that someone outside the company has been using your account to make AI models work for them, and the bill is yours.

That is LLMjacking, the hijacking of access to language models, and it is in the news because in late October a cloud hosting platform, Northflank, warned its customers that it had suffered a security incident and that AI keys stored on it were being used without permission.

◢What is LLMjacking?

An API key is a password that lets a program use an AI service, and usage is charged to whoever created it. If someone steals the key, they can run the models at your expense: they do not need to break into anything else, having the key is enough.

The word blends LLM (large language model) and hijacking. You will also hear "stolen AI keys" or "API key abuse". The risk is twofold: the direct cost, and the fact that meanwhile someone is using your account for whatever they want without you knowing.

◢A real case: Northflank, October 2026

◢Why can your company be a target?

You do not need to be a large company. These are some of the routes by which a key ends up in the wrong hands:

• ▹It is written inside the code and someone pushes it to a public repository.
• ▹It is pasted into a shared document, a chat or an email to "pass it on" to a colleague.
• ▹A tool or an outside provider uses it and suffers an incident, as in the case above.
• ▹It stays on the computer of someone who leaves the company or whose machine gets infected with malware.

If, on top of that, each person signs up for their own paid AI account, nobody in the company knows how many keys exist or where they are. It is the same situation I describe in the article on what data not to paste into ChatGPT: you cannot protect what you do not control.

◢How much can it cost?

OWASP does not discuss stolen keys on that page, but the consequence is the same. That is why its measures, such as per-user limits and usage monitoring, apply here too.

◢What can you do to prevent it?

• ▹Keep keys out of code and repositories. Store them in environment variables or a secrets manager, not in a file that gets shared.
• ▹Give them an expiry date and rotate them regularly: create the new one, update the application and revoke the old one once you have checked everything works.
• ▹Separate projects for testing and production, and limit who can access the production one.
• ▹Set spending limits and alerts. An alert tells you when usage goes up; a hard limit stops traffic when it reaches the figure. Check how it behaves in production first so you do not cut off a service your customers rely on.
• ▹Look at the usage dashboard from time to time. A spike at three in the morning is the earliest signal you will get.

And a question any manager can ask today: who in the company holds an AI key, and where is it stored? If nobody knows, that is the first job.

◢What if I suspect a key has leaked?

Do not wait to confirm it. Create a new key, put it in the application, revoke the old one and check in the provider's dashboard what usage there was and since when. If the source is a platform with an incident, do the same with every key you had there, not just the AI ones, and follow the instructions its company publishes. Then tell the AI provider that there has been unauthorised use.

If your assistant also has access to data or can take actions, review what permissions you have given it too: a stolen key with too many permissions does far more damage than one that can only read.

◢Make sure the whole team knows

Almost every key leak starts with a rush: someone needs to test something and pastes it where it does not belong. A clear rule explained in ten minutes prevents more trouble than any tool. If you want your staff to understand these risks with examples from their own day, that is part of what I cover in my cybersecurity and AI training.