If your app calls an AI model, somewhere there's a key that lets it do that. Google's threat intelligence team and Mandiant published a report on 2 November about what happens when criminals get hold of those keys, and the numbers are not small. In individual incidents, fraudulent charges went over $100,000 in a single day. At some organisations the total reached $1 million before anyone revoked the access.
They call it LLMjacking. It's the AI version of cryptojacking, except it doesn't creep up on you over months. Google says it can generate large spikes in fraudulent charges in a matter of hours.
What's actually going on
The short version: someone steals a key or token that can talk to your cloud account or your AI provider, then uses your account to run expensive models for themselves or to resell access to other people. The report describes a whole little industry around it, with some people breaking in and others running the services that pool stolen keys and sell cheap "unlimited" AI access to subscribers. Your bill pays for their customers.
The interesting bit for anyone running bespoke software is how they get in. The report doesn't describe clever zero days in the AI models. It describes the boring stuff:
- Keys left in code. One group harvested corporate AI API keys from public GitHub repositories.
- Cloud credentials. Exposed or stolen IAM credentials, service account keys, GitHub personal access tokens and session tokens. Google calls stolen cloud identity tokens the dominant way in.
- Misconfiguration. One intrusion started with a misconfigured service account key. Another paired a stolen token with a suspected web application vulnerability.
- Exposed model servers. Attackers probed publicly reachable Ollama endpoints.
- Unpatched gateways. In one case they exploited a flaw in LiteLLM, an AI proxy gateway, tracked as CVE-2026-40217.
And here's the part I'd underline. In several incidents the AI services weren't even switched on when the attacker got in. They used the stolen access to enable services like Bedrock or the Gemini API, created fresh API keys and signed the account up to pay-as-you-go billing on premium models. So "we don't use AI on that account" isn't the comfort it sounds like. If a key can turn things on, it can turn on the expensive things.
Why this matters for small businesses
A lot of the AI features going into business software right now were added quickly. That's not a criticism. Getting something working first is sensible. But quick tends to mean a key pasted into a config file, a cloud account with one all-powerful set of credentials, and no spending limit because nobody got round to it.
If the app was built with Lovable, Bolt or Cursor, or by a developer who has since moved on, it's worth knowing where those keys live before someone else finds out for you. I wrote about the basics in a guide to API keys in your code: treat them like passwords, rotate one the moment it leaks, and move them out of the code into environment variables or a proper secrets manager.
What to check this week
Google's report lists seventeen mitigations. Not all of them apply to a small business with one app on one cloud account, so here are the ones I'd do first.
- Search your code and its history for keys. Not just the current files. A key committed two years ago and "removed" is still in the Git history. Automated secret scanning on your repositories catches this.
- Rotate anything that's been near a repo, a chat message or a shared document. Then put keys in a secrets store, so rotating them is a routine job and not a project.
- Cut permissions down. Google's advice is to deny anything not explicitly required, including access to cloud AI services. The account your app runs as should not be able to enable new services or create new keys.
- Give each key one job. Separate keys for live and test, scoped to the model you actually use, with usage limits. A leaked test key then can't burn through your production budget.
- Set spending caps and budget alerts. Per model where your provider allows it. An alert at breakfast beats a bill at month end. We've covered how to stop runaway AI bills before, and the same controls help here.
- Don't leave model servers on the open internet. If you run Ollama or a similar server, keep it behind a firewall or VPN and let only your app reach it.
- Patch the AI plumbing. Proxies and gateways like LiteLLM are software like any other and need updating like any other.
- Turn on phishing-resistant MFA for your cloud console, your AI provider and GitHub.
On the monitoring side, Google's advice is to treat any unauthorised enablement of an AI service as a critical security event. The report gives the specific log events for AWS, Azure and Google Cloud, and points out that on Google Cloud the data access logs are off by default, so you have to switch them on to see model calls at all. If you've never looked at your cloud bill line by line, this guide to high AWS bills is a decent place to start getting familiar with what normal looks like.
A word on running your own models
One answer to "what if our AI key gets stolen" is not to have a metered key at all. A model running on hardware you own has no per-token bill for anyone to run up. It isn't automatically safe, mind. The report specifically mentions exposed Ollama endpoints, so a private model still needs to be private. If that route appeals, there's more on private AI on hardware you own.
Where we come in
If you've got an app that calls an AI model and you're not sure where its keys are or what they can do, our code audit is £250 + VAT. You get a written report on how it's put together, the security issues and who can see what they shouldn't, with a fixed price for each fix.
If you'd rather someone just kept on top of it, Look after it starts from £355 a month + VAT and covers security updates, hosting, monitoring and tested backups, with direct access to the developers who know the code.
Either way, the first job costs nothing: find out where your AI keys are and what they're allowed to do. Get in touch if you'd like a hand.
Cheers, Rob
