Stolen AI API keys are turning into six-figure cloud bills. Here's how to check yours this week.

What happened

On November 2, 2026, Google's Mandiant and Google Threat Intelligence Group published a report on LLMjacking: attackers hijacking a company's access to large language models and passing the usage bill to the victim. Across the cases Mandiant worked in 2026, fraudulent charges from that abuse exceeded $100,000 in a single day, and at some organizations the cumulative bill reached about $1 million before access was revoked. Victims spanned financial services, retail, technology and transportation in North America, South America and Asia Pacific.

The usual way in was not a clever prompt. Mandiant says the dominant path was stolen or exposed cloud credentials — service account keys, IAM credentials, GitHub personal access tokens and session tokens — plus AI API keys scraped from public GitHub repositories. In several cases, the company had never turned on its cloud LLM services; the attackers used the stolen access to enable them, then burned tokens at high volume. One underground resale setup Mandiant tracked, Jet Night, left a single victim organization with nearly $1 million in token costs after more than 500,000 LLM API calls in under eight hours.

The same week, the platform side of the story kept growing. Security firm Wiz has been tracking what it calls "Black October" for AI developer platforms: a run of disclosures in which attackers reached stored customer secrets, especially environment variables that hold AI provider keys. Wiz's public list started with platforms such as Fireworks AI, Railway, Warp, Lightning AI and Northflank, and by early November it had added more disclosures (including Trigger.dev, Chainstack, Blacksmith and Tensorlake). Wiz says the entry points differed by vendor, but the target was consistent. In two Amazon Bedrock abuse cases Wiz investigated after a vendor compromise, stolen keys were first tested within about 30 minutes. Days later they were used for roughly 800,000 and 1.7 million model calls — more than $100,000 at list prices before the keys were cut off.

Two practical points for anyone running a site or an AI-powered workflow:

A key on a third-party platform is only as safe as that platform. Encryption at rest does not stop an attacker who reaches the build system or the path that decrypts secrets at run time.
Removing the key from the breached tool is not enough. Only the AI or cloud provider that issued the key can revoke it. Until you rotate it there, anyone who copied it can keep spending on your account.

Who it helps

Owners and teams that store AI API keys for chatbots, content tools, support assistants, coding agents or site automations.
Anyone hosting apps on AI developer platforms or PaaS hosts that inject environment variables at deploy time.
Teams using Amazon Bedrock, Google Cloud AI, Azure OpenAI or similar pay-as-you-go model APIs, where a stolen key can enable services and burn budget overnight.
Anyone whose developers keep keys in GitHub, staging servers or shared .env files.
People who should wait: if you only use consumer chat apps in a browser and have never created an API key or cloud AI project, this checklist is still worth a quick pass, but the urgent risk is lower.

How to apply

List every AI key and cloud AI project you have (10 minutes). Include OpenAI, Anthropic, Google AI / Gemini, Amazon Bedrock, Azure OpenAI and any smaller providers. Note where each key is stored: production host, staging, CI/CD, Zapier-style tools, AI coding tools, admin laptops and old test apps that are still online.
Check whether a platform you use disclosed a breach. If you got an email from a host or AI tooling vendor in the last few weeks, open it. Assume any long-lived key that sat in that environment may have been copied.
Rotate at the provider, then update every consumer. In the OpenAI, Anthropic, Google or AWS console, create a new key (or access credential), put it in the places that still need it, then revoke the old one. Deleting it only from the breached dashboard leaves the old secret working.
Turn on spend alerts and hard caps where they exist. OpenAI's production guidance says you can set spend alerts on the limits page and a hard spend limit that stops API traffic when tracked spend hits the cap. AWS Budgets can alert on Bedrock spend; Google Cloud has budget alerts too. Set a number you would notice the same day, not at month-end.
Scope keys and split environments. Prefer a project or service-account key for each app, not one personal key everywhere. Keep staging keys out of production. Where the provider allows it, limit which models or endpoints a key can call so a low-tier utility key cannot invoke the most expensive models.
Get keys out of public places. Search your GitHub orgs and old repos for API_KEY, OPENAI, ANTHROPIC, GEMINI and aws_access. OpenAI's own guidance: keep keys in environment variables or a secrets manager, set expiration dates and rotate on a schedule.
Watch for odd usage, not just total spend. Mandiant saw attackers test stolen keys with tiny one-token requests that slip under volume alerts, then flood later. Look for new API keys you did not create, LLM services enabled that you never turned on, and usage from regions or user-agents you do not recognize.
Lock the account doors. Turn on phishing-resistant MFA on your cloud console and AI provider logins. Review who on the team can create keys or change billing.

How CerpaMedia can help

If you would rather not dig through every dashboard yourself, we can do the check with you. We inventory where your site, automations and AI tools store keys, rotate anything that sat on a disclosed platform, turn on spend alerts and hard caps where the provider allows them, and separate staging from production secrets. Then we leave you a one-page map of what key lives where and what alert fires if usage spikes, so the next vendor notice is a short checklist instead of a surprise bill. To talk it through, Book a call.