Some breaches announce themselves on the invoice. Google's threat intelligence group and Mandiant say they've investigated cases this year where attackers used stolen cloud credentials to run AI models on the victim's account, running up more than $100,000 in charges in a single day, and up to $1 million in total before anyone revoked the access.
The attack has a name, LLMjacking, and on 2 November Google published a detailed report on how it works (The Hacker News summary is shorter). Three days later, Microsoft described an attacker running reconnaissance against customers' Azure AI workloads using secrets harvested from public code. Our view: most organisations' AI spend is now big enough to hide a breach, and the SOC needs to see it.
How LLMjacking works
The goal is simple. Model access costs money, so attackers take someone else's and either use it or sell it. Google describes the routes in:
- Stolen or exposed cloud credentials, which Google calls the dominant way in: service account keys, access keys, personal access tokens and session tokens.
- AI API keys leaked in public code, checked with tiny test requests (a single token of output) to see which still work.
- Exposed model endpoints and flaws in AI gateway software, including one that let ordinary keys become master keys. We covered why those gateways matter in Your AI Gateway Holds More Keys Than Your Domain Admin.
Once in, attackers enable AI services the victim never used, create new keys and deployments, ask for quota increases, try for expensive compute in several regions, and switch off logging where they can. Some put a reverse proxy in front of the stolen access and resell it. Google describes one service offering "unlimited" access for about $60 a month, while passing nearly a million dollars of token costs to a single victim.
Why the bill is the alarm
LLMjacking is quiet in the places SOCs usually look. Nobody signs in from a strange country. No malware runs. The attacker uses a valid key to call a legitimate service exactly as your developers do, just much more often. The one thing it can't hide is cost, and cost usually lands with finance, a month later, as a line item nobody can explain.
That's the gap. Your security team gets an alert when someone fails to sign in five times. It probably doesn't get one when your AI spend goes up tenfold overnight.
What to do about it
1. Put a ceiling on it
Set budgets with alerts on every subscription that can run AI services, and set quotas on the deployments themselves. Google's advice is to use per-model quotas and spending caps. A cap won't stop the breach, but it turns a million-dollar problem into a manageable one.
2. Send the spike to security, not just finance
Route cost anomaly and budget alerts on AI resources to the SOC. A sudden jump in calls to a model is a security event until someone shows it isn't.
3. Watch the management plane in Azure
Google's report lists the Azure operations to watch: new deployments (Microsoft.CognitiveServices/accounts/deployments/write), reconnaissance of accounts and deployments, and changes to diagnostic settings. A starting point for Sentinel, to tune for your environment:
AzureActivity
| where TimeGenerated > ago(30d)
| where OperationNameValue has_any ("MICROSOFT.COGNITIVESERVICES/ACCOUNTS/DEPLOYMENTS/WRITE",
"MICROSOFT.COGNITIVESERVICES/ACCOUNTS/WRITE",
"MICROSOFT.COGNITIVESERVICES/ACCOUNTS/LISTKEYS/ACTION",
"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE",
"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/WRITE")
| where ActivityStatusValue in ("Success", "Succeeded")
| project TimeGenerated, Caller, CallerIpAddress, OperationNameValue, ResourceGroup, _ResourceIdTreat a new deployment by anyone outside your infrastructure-as-code pipeline as high priority, and a logging change on an AI resource as higher still. Note that model calls themselves only show up if diagnostic logs are switched on for the resource.
4. Take the keys away
Prefer Entra ID authentication to API keys for AI services, give each workload its own managed identity, and deny AI service permissions to every identity that doesn't need them. Where keys are unavoidable, keep them in a vault and rotate them. Our guide to secrets management covers the basics.
5. Scan your code
Microsoft's case shows how leaked secrets get found: automated searches of public repositories, run by AI agents. Turn on secret scanning with push protection, and treat any key that has ever been public as compromised. Our threat research on that campaign has the hunting queries.
Who owns this?
In most organisations, AI services were set up by a product or data team, the subscription is paid by IT, and the bill is checked by finance. Security often sits outside all three. That's how a service that can cost six figures a day ends up with less monitoring than an email inbox.
The fix is organisational more than technical. Put AI resources on the same asset register as everything else, give each one an owner, and make sure the SOC sees the signals above. AI services aren't new territory for attackers. They're a new way to spend your money.
How we help
Our managed SOC monitors Azure activity alongside identity and endpoint signals in Microsoft Sentinel, so a new AI deployment by an unfamiliar identity, or a logging change on an AI resource, is investigated rather than discovered on the invoice. Our SOCs are staffed 24/7. Our Microsoft security consultancy helps move AI workloads off API keys and onto managed identities with sensible quotas.
If you'd like to know who can create AI deployments in your Azure estate today, book a demo or talk to our team.