If your business has plugged AI into anything (a chatbot on your website, an automation that drafts emails, a tool that summarizes calls), somewhere there's an AI API key: the password your software uses to talk to OpenAI, Anthropic or Google. In October 2026, stolen AI API keys became one of the most sought-after things an attacker can take. Here's what happened, why criminals want those keys, and the handful of settings that limit the damage if one leaks.
What happened in October
Cloud-security firm Wiz counts nine breaches of AI developer platforms in October alone. The ones with public details:
- Railway, a popular hosting platform, said an attacker pulled the encrypted settings where customers' apps keep their passwords and keys (called environment variables) and decrypted some of them, affecting up to 1.85% of workspaces. Its preliminary report says the attacker was after AI provider keys.
- OpenCode said AI provider keys belonging to about 1.4% of its Console users may have been exposed.
- Northflank, another hosting platform, told customers on October 30 to assume all their environment variables had been decrypted and to rotate every key. Customers then reported their stored AI keys being used without permission.
- LiteLLM, a widely used open-source library for calling AI models, shipped a poisoned release (version 1.107.0) that stole cloud logins and OpenAI, Anthropic and Cohere keys from the machines that installed it. The Register traced the root cause to a master key accidentally published in a public code repository back in May. Someone deleted it, but nobody revoked it, and months later an attacker used it to take over the project's release process.
- Gitee, a public code-hosting site: a researcher scanning public repositories there found 26,400 working credentials, including 1,348 OpenAI keys and thousands of keys for Chinese AI providers.
Why attackers want your AI keys
- To spend your money. Security researchers call it "LLMjacking": using stolen keys to run AI at the victim's expense, often reselling the access. In two cases Wiz traced on Amazon's AI platform, abuse started within 30 minutes of the breach, ran to about 2.5 million requests, and likely cost more than $100,000 at list prices.
- To copy a model. Railway and OpenCode both said the attackers' goal was "distillation": feeding huge numbers of prompts through stolen accounts to harvest a model's answers and train a rival model on them.
- To run their attacks on your account. Anthropic's threat-intelligence team reported criminals moving their attack tooling onto victims' keys, which also hides who is really behind the traffic. One campaign ran for a month entirely on stolen keys.
They also go looking for keys directly. Security firm Cequence described a scanner that pretended to be the web crawlers of OpenAI, Anthropic and other AI companies while requesting about 90 well-known locations for secret files, like .env files left on web servers.
How to protect your keys
None of this needs to be complicated. These settings exist on the major AI platforms today.
1. Set a hard spending limit
A leaked key with a spending cap is an annoyance; one without a cap can be a five- or six-figure bill.
- OpenAI lets you set hard monthly limits for the whole organization or per project. Once a limit is hit, requests stop (it can run slightly over). Alerts on their own don't stop anything.
- Anthropic offers organization-wide limits plus spend limits and alerts per workspace.
- Google AI Studio offers per-project spend caps (still marked experimental, and billing data lags about 10 minutes). Standard Google Cloud budgets only send alerts.
2. Give every project its own key
Use a separate key for each app and each environment (testing versus live), scoped as narrowly as the platform allows: OpenAI project keys and permissions, Anthropic workspaces, and Google keys restricted to the specific APIs they need. When one leaks, you replace one key instead of breaking everything.
3. Revoke, don't just delete
Deleting a key from your code, or deleting the code, does nothing to the key itself. LiteLLM is the cautionary tale. When a key may have been exposed, create a replacement, switch your software to it, confirm it works, then revoke the old key on the provider's website. Anthropic suggests rotating keys about every 90 days regardless.
4. Keep keys out of code, documents and chat
Store keys in a secrets manager or your hosting platform's secret settings, never in source code, shared documents, spreadsheets or team chat. OpenAI and Anthropic both work with GitHub's secret scanning, which automatically disables their keys when they're found in public code, but don't rely on that safety net.
5. Restrict where a key can be used from
If your software always calls the AI service from the same servers, lock the key to those addresses. OpenAI supports allowlists of up to 50 IP addresses per organization or project, and Google lets you restrict a key to specific IP addresses. Anthropic offers IP allowlisting on enterprise plans.
6. Watch the bill
Turn on usage and billing alerts and look at them. A sudden spike is often the first sign a key is in the wrong hands.
If a platform you use was breached
If you use Railway, OpenCode or Northflank, or anyone on your team installed LiteLLM 1.107.0:
- Rotate every password and key stored on that platform, starting with payment, email and cloud accounts.
- Revoke the old AI keys at the AI provider, not just on the platform.
- Review your AI usage and billing since mid-October, and report misuse to the provider.
- Treat any machine that installed the poisoned LiteLLM release as compromised: rotate everything it could reach, from a different, clean computer.
Questions to ask your developer or agency
If you don't touch the code yourself, these four questions cover most of it:
- Which AI services do we use, and where are the keys stored?
- Does every AI account have a hard spending limit and billing alerts?
- Does each app have its own key, and when were they last rotated?
- Were any of our keys on Railway, OpenCode, Northflank, or a machine that installed LiteLLM 1.107.0?
For the bigger picture of this month's attacks, see our Black October explainer, and for another way AI tools themselves became the target, the poisoned Claude Code extension.
Sources
- Wiz: "Black October" for AI developer platforms (Oct 30, 2026) and From phishing to LLMjacking (Oct 20, 2026)
- Railway: Preliminary report on the October security incident (Oct 22, 2026)
- BleepingComputer: Northflank security breach leads to abuse of customers' AI API keys (Oct 31, 2026)
- The Register: LiteLLM supply chain attack started with an exposed master key (Oct 26, 2026)
- The Hacker News: 26,400 valid cloud and AI credentials found exposed in public Gitee repositories (Oct 29, 2026)
- Cequence Security: AI agent impersonation (Oct 28, 2026)
- Anthropic: Detecting and countering misuse of AI: September 2026
- Sysdig: LLMjacking: stolen cloud credentials used in new AI attack (2024)
- OpenAI: Spend limits, Production best practices and IP allowlist
- Anthropic: API key best practices and Workspaces
- Google: Using Gemini API keys and Gemini API billing
- OWASP: Secrets management cheat sheet
This post reflects reporting available on November 1, 2026.