A stolen LLM key is an incident and a bill at the same time

An AI provider key sitting in an environment variable is a credential that spends money every time someone uses it. When a platform that stores those variables is breached, the first sign of trouble may show up on a usage dashboard before it shows up in a security alert. Northflank's incident page tells that story in its own updates: an instruction to rotate environment variables on October 30, then a note that evening that "users have reported unauthorised use of AI API keys supplied to the Northflank platform."

I want to stay inside what Northflank and BleepingComputer have published. The interesting part for most teams is not how the attacker got in. Northflank has not said yet, and it says it intends to share a root cause analysis once it has confirmed findings. The interesting part is what the response guidance asks every team to do, and how much of it is about money.

What the incident page says

The timeline on the status page starts with a threat alert from Wiz at 11:43 UTC on October 30. Northflank engineers reviewed it a minute later, deployed an initial network policy patch at 12:02, and pushed more patches after that. By 13:58 UTC the guidance was blunt: "Assume all environment variables have been decrypted. Disable/rotate all keys."

Over the next two days, Northflank turned on secret rotation for its managed databases and other add-ons, and on October 31 it enabled audit logs for all users, including free accounts. Its November 2 update says it believes the attack vector was contained within an hour of the first alert, that running workloads appear unaffected, and that the evidence suggests the attack focused on secrets held in its control plane. Independent forensic auditors are still reviewing it.

BleepingComputer notes what is still unknown: how the attackers got access, how many accounts were affected, and whether credentials other than the AI keys were abused. It also reports that Wiz counted at least nine incidents at AI development platforms in October, and that some of those attackers specifically went after environment variables holding AI service credentials. Northflank itself says the reports it received "may be consistent with the broader pattern of attacks targeting AI credentials." That is a careful sentence, and I will leave it as careful as they wrote it.

Why an AI key is a different kind of secret

A leaked database password lets someone read or change your data. A leaked AI provider key lets someone run workloads on your account. BleepingComputer describes the practice, which Wiz calls LLMJacking, as using stolen credentials to reach AI models on another organization's keys, either to run up charges or to resell the access.

That changes who notices first. The security team watches for logins and data movement. The person who sees an AI key being abused is often whoever reads the provider bill or the usage page. Northflank's guidance reflects this. Its first recommendation in the November 2 update is to start rotation with AI provider keys, and it tells users to review provider logs and contact their AI providers directly if they see "unexpected AI usage or spend."

So a stolen model key is a security incident and a cost incident at once. If your incident response plan only talks about the first half, nobody owns the second half until the invoice arrives. I wrote about building a basic spend-tracking routine in the seat no longer caps your AI bill. This is the case where that routine pulls double duty as detection.

A rotation checklist for AI provider keys

Northflank's October 30 guidance spells out the order: revoke existing credentials with the issuing provider, generate replacements, then update the affected secrets and workloads. Here is how I would turn that into a checklist a small team can run today, whether or not you use Northflank.

• List every place an AI provider key lives: platform environment variables, secret groups, CI variables, local developer files, and any agent or automation config. If you cannot list them, you cannot rotate them.
• Revoke at the provider first. Changing the value in your hosting platform does nothing if the old key still works at the provider.
• Issue one key per workload or environment, never one shared key for everything. A shared key turns one exposure into a full rebuild.
• Scope each new key as narrowly as the provider allows: specific models, a project or workspace, and an IP or network restriction if one exists.
• Update the secret where it lives, redeploy, and confirm the old key now fails. Rotation is done when the old value is dead, not when the new one is saved.
• Record what was rotated, when, and by whom. That list is the evidence you will want when someone asks whether everything was covered.

Northflank's own priority list is a reasonable model for the rest: after AI provider keys, it names cloud provider credentials, payment provider keys, private keys, and database and other service credentials.

Spend alerts are detection too

Rotation closes the door. It does not tell you whether someone already walked through it. For that you need the usage side, and most teams set it up for budgeting and never look at it again.

• Turn on usage or budget alerts at the provider for every project, and set them low enough to fire on an abnormal day, well before the monthly total looks wrong.
• Send those alerts to a shared channel that someone on the security or operations side also watches, not only to the finance inbox.
• Know what normal looks like for each key: which models it calls, roughly how much, and at what hours. A key that only powers a daytime internal tool should not be busy at 3 a.m.
• Pull provider usage logs for the exposure window, starting from the earliest date your secrets could have been read, and compare them to your own application logs. Usage your application did not generate is the finding.
• If you find it, report it to the provider and the platform, as Northflank asks, and keep the exports with your incident notes.

None of this needs a new product. It needs someone to decide that usage dashboards are part of the security telemetry for AI workloads.

Who owns this before the next one

Northflank's update says it revoked access tokens, sessions, version control integrations, and cross-account roles on its side where it could. Everything stored as a user-provided secret was left to its users. That split is normal for hosting platforms, and it means the clock on your keys is yours.

The question I would put to any team running AI features on a hosted platform is simple. If your hosting provider posts "rotate all secrets" at lunchtime, who rotates the AI keys, how long does it take, and who checks the usage logs for the days before the alert? If those are three different people who have never talked about it, that is the gap to close this week.