A developer wakes up on a Saturday to a spend alert from her AI provider. Overnight, someone has been running up charges on a key she’d pasted into a coding tool weeks earlier and forgotten about. She hasn’t done anything wrong in the usual sense. Her laptop is clean, her passwords are strong and her own code never leaked. The key was sitting in a vendor’s system, and the vendor was breached.
That’s roughly what happened to some OpenCode users in mid-October. Users reported unauthorised charges, with some saying they’d been billed more than $1,700 overnight. It wasn’t an isolated story. One security recap counted 15 well-known companies and projects reporting incidents in October, and in six of them attackers ended up holding secrets such as API keys, tokens or environment variables.
AI keys are an especially attractive target because they turn directly into money. A stolen database password needs a buyer or a plan. A stolen AI key can be put to work immediately, running queries at someone else’s expense. And because teams now scatter these keys across coding tools, agents, automation platforms and hosted dashboards, there are far more places for them to leak than there used to be.
In this post we’ll explain what happened at OpenCode and the pattern behind October’s incidents, then set out five practical principles for protecting AI keys, with a focus on two that limit the damage: making secrets short-lived and putting spend limits behind them. We’ll finish with what to do when a key leaks, a checklist and answers to common questions.
What Happened at OpenCode
On October 17, 2026, OpenCode, the open-source AI coding project, told some users of its hosted Console that third-party AI provider keys saved in their workspaces may have been exposed. It said the breach affected 1.4% of Console users, specifically those who had linked external providers such as OpenAI, Anthropic and Google.
OpenCode described the incident as “a large scale distillation attack.”
According to reporting, attackers got into a legacy system that OpenCode was preparing to shut down, and the earliest possible exposure was 00:30 UTC on October 17. Anthropic and Google blocked keys believed to be exposed, and one report says OpenAI was refunding affected API customers. OpenCode said its command-line tool and desktop apps weren’t affected, since the exposed keys lived only in the Console. Its public statement doesn’t explain how the attackers got in, how long they stayed or how many keys were involved, so some details remain unknown.
Two things stand out. The keys were stored in a hosted service because users had chosen to link them for convenience. And the weak point was a forgotten legacy system, the kind of thing nobody thinks about until it’s the way in.
The Wider Pattern
Six of October’s incidents put secrets in attacker hands, and in four of them the attackers got in using credentials they had stolen earlier.
The same recap lists several more cases that fit the pattern. Railway found unauthorised access to the systems that store customer environment variables and told all customers to rotate credentials stored before October 21. Fireworks AI found unauthorised use of internal credentials, and a third party read environment variables, including API keys, from evaluation jobs in a small number of accounts. Attackers used stolen GitHub tokens from three LiteLLM engineers to publish a malicious release to PyPI that was live for about 1 hour 40 minutes. TiDB Cloud’s maker reported an intruder using stolen service account credentials to copy a table of encrypted API keys. And attackers used hijacked maintainer accounts to add a fake “Security Audit” workflow to 345 repositories, sending each one’s Actions secrets to their own server.
The incidents had different causes, but they share a shape. One stolen secret opens a door, and a door opened with a valid secret often looks like normal use. That’s why it’s worth assuming that some secret, somewhere, will eventually leak, and designing so that a leak is survivable.
Principle 1: Make Secrets Short-Lived
A long-lived key is a standing invitation. If it leaks in January and nobody notices, it still works in October. A short-lived credential limits that window by expiring on its own, so even a stolen one has a narrow shelf life.
Where your platform supports it, prefer short-lived credentials issued to your workloads over static keys stored in files or environment variables. One approach some teams use is a gateway that holds the real provider key and lets applications authenticate with a short-lived token instead. That means the long-lived secret lives in one well-guarded place, not in every tool.
Where you must use a static key, rotate it on a schedule and whenever someone leaves or a tool is retired. And avoid pasting keys into hosted tools you don’t control. If a tool genuinely requires one, give it a separate, capped, short-lived key of its own, so a breach there can’t touch anything else.
Principle 2: Cap the Damage with Spend Limits
Short-lived keys reduce the chance of a problem. Spend limits reduce its cost. Together they turn a catastrophe into an annoyance.
What’s available differs by provider, and the details change, so check each provider’s current documentation. Based on recent summaries of those docs:
- OpenAI offers monthly spend limits at the organisation or project level, with an option to enforce a hard limit. When it’s reached, requests fail, though enforcement isn’t instant.
- Anthropic offers monthly spend limits per workspace, below the organisation limit, but they can’t be set on the Default Workspace, so move agents and tools into their own workspaces.
- Google announced project spend caps for the Gemini API on March 16, 2026. They’re set per project in AI Studio, are described as experimental, can lag by around ten minutes, and apply to the Gemini API, not Vertex AI. Batch jobs can run past them.
Notice what’s missing: none of the sources I found describes a cap on a single key. The nearest thing is a workspace or project with the key living inside it. The practical lesson is to give each tool its own project or workspace, each with its own cap, so one leaked key can only spend one budget. Also prefer hard limits to alerts. An alert tells you something went wrong. A hard limit stops it going further.
Principle 3: Separate and Scope
Use one key per tool, per project and per environment. A key for your staging environment shouldn’t work in production, and a key for a coding assistant shouldn’t be the same one your customer-facing application uses. If every tool shares one master key, one breach exposes everything. If each has its own, a breach becomes a contained incident you can fix by revoking one key.
Give each key only the permissions and models it needs, and set sensible rate limits where the provider allows them.
Principle 4: Detect Quickly
Most of the damage in cases like OpenCode’s happened overnight. The faster you notice, the less it costs. Set spend alerts at low thresholds, well below your hard cap, so they fire early. Check provider dashboards regularly, and learn how to revoke a key in each one before you need to. If you have more than a couple of providers, a single view of spending across them saves time, since provider caps and dashboards are separate.
Principle 5: Hold Fewer Secrets and Trust New Code Slowly
Every secret you keep somewhere is a secret that can leak from there. Review where yours live, and remove the ones you no longer use. Scan your repositories and build pipelines for accidentally committed secrets, and treat any that appear as already compromised. We described how to build that kind of check into review in our post on risk-tiered code review for AI-generated code.
The LiteLLM incident carries another lesson. The malicious versions were live for under two hours, so waiting a day before installing a brand-new package version would have avoided them. It’s a cheap habit with a real payoff, as is checking what your dependencies run when they’re installed. The same discipline applies to developer tools and extensions, which we’ve seen attackers target.
Ask Your Vendors the Right Questions
In our post on the Cloudflare cache bug, we argued that what a vendor does with your data while processing it matters as much as what it promises about storage. Keys follow the same logic. Any hosted tool that holds your keys inherits your risk, and your security depends on theirs. Before you store a key in a vendor’s system, ask:
- How are keys stored and encrypted, and who inside the company can access them?
- What happens to old or legacy systems, and are they included in security reviews?
- Can I use scoped or short-lived credentials instead of a master key?
- How will I be told if something goes wrong, and how quickly?
- Can I revoke a key from my side, and see what it’s been used for?
The OpenCode case is a reminder of why the second question matters. A decommissioning system is still a live one until it’s switched off.
What to Do When a Key Leaks
Move quickly and in order.
- Revoke the key at the provider, then create a replacement and update the applications that use it.
- Check usage on the provider’s dashboard for requests and charges you don’t recognise.
- Contact the provider. In the OpenCode case, providers blocked exposed keys, and refunds were reported, so ask what they can do.
- Rotate related secrets. If one key leaked from a tool, assume others stored alongside it may have too.
- Find the cause. Work out where the key was stored and how it got out, so you can close the gap.
- Record and review. Write down what happened and update your practices. If personal data may have been involved, involve your legal advisers. This isn’t legal advice.
The same discipline applies to wider incidents, such as the one we covered in our PHP2Shell checklist, where rotating credentials was among the first steps.
An AI Key Protection Checklist
- Listed every place an AI provider key is stored, including hosted tools and CI settings
- Removed keys for tools and projects you no longer use
- Given each tool, project and environment its own key
- Put each tool in its own provider project or workspace with a hard spend limit
- Set spend alerts well below the cap
- Moved agents out of default workspaces where limits can’t be set
- Switched to short-lived credentials or a gateway where possible
- Set a rotation schedule for keys that must remain static
- Added secret scanning to repositories and build pipelines
- Adopted a delay before installing brand-new package versions
- Written a short key-leak response plan and named an owner
Frequently Asked Questions
What happened in the OpenCode breach? On October 17, 2026, OpenCode said attackers accessed a legacy system and that third-party AI provider keys stored by 1.4% of its Console users may have been exposed. Some users reported unauthorised charges, including more than $1,700 overnight.
Can I set a spend limit on a single AI API key? Not according to the sources I found. Limits are generally set at the organisation, workspace or project level, so the practical approach is to give each tool its own workspace or project and cap that.
Are spend alerts enough? No. Alerts tell you something is wrong, but they don’t stop it. Hard spend limits do, though enforcement isn’t always instant, so use both.
What is a short-lived secret? A credential that expires on its own after a short time, so a stolen copy has a narrow window of use. Where possible, prefer them to static keys that never expire.
Should I store my AI keys in a third-party tool? Only if you must, and then use a separate, capped key for that tool, so a breach there can’t affect anything else. Ask the vendor how keys are stored and what happens to legacy systems.
What should I do first if a key leaks? Revoke it at the provider, create a replacement, and check usage for requests and charges you don’t recognise.
Where to Start This Week
If you only do a few things, begin with these.
- Find your keys. Search your tools, code, CI settings and shared documents for provider keys and make a list.
- Cap your spend. For each provider, set a hard monthly limit on every project or workspace, and move tools out of any default workspace where limits aren’t available.
- Separate your keys. Make sure each tool has its own, and retire any that are shared.
- Set an early alert. Create a spend alert at a level that would be unusual for you, so you hear about a problem in hours, not weeks.
None of this needs new software. It needs someone to own the question of where your keys live and what they could cost you if they leaked, which is often the missing piece.
Assume a Leak, and Build for It
It’s tempting to respond to news like this by promising to be more careful. Care helps, but it isn’t a plan. Keys will leak from tools you didn’t build, systems you didn’t know existed and accounts you didn’t think about. The teams that stay calm when that happens are the ones that made a leak small: short-lived credentials that expire, separate keys that contain the damage, caps that stop the bill and alerts that tell them quickly.
That approach also makes the rest of your security easier to reason about. When you know where every key lives, what it can do and what it can cost, you can answer a vendor’s breach notice in minutes instead of days. If you’d like help putting that structure in place, our work through Kilowott Intelligence includes reviewing how AI tools are connected and governed, automation can handle key rotation and spend monitoring, and our web and e-commerce team can check the credentials sitting behind your sites. You can see how we approach this kind of work across other clients in our case studies.
