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 pasted into a coding tool weeks ago and forgot about. Her laptop is clean and her passwords are strong. Her own code never leaked. The key was sitting in a vendor’s system, and the vendor was breached.
That is close to what some OpenCode users reported in mid-October 2026, with a few saying they were billed more than $1,700 overnight. It was not a one-off. A security recap cited in research by Kilowott 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 attractive target because they turn directly into money. A stolen database password needs a buyer or a plan, while a stolen AI key can be put to work immediately, running queries at someone else’s expense. Teams now scatter these keys across coding tools, agents, automation platforms and hosted dashboards, so there are far more places for them to leak than there used to be.
What Happened at OpenCode
On October 17, 2026, the open-source AI coding project OpenCode told some users of its hosted Console that third-party provider keys saved in their workspaces may have been exposed. It said 1.4% of Console users were affected, specifically those who had linked providers such as OpenAI, Anthropic and Google.
According to reporting, the attackers got in through a legacy system that the project was preparing to shut down. Anthropic and Google blocked keys believed to be exposed, and one report says OpenAI was refunding affected customers. OpenCode’s public statement does not explain how the attackers got in or how many keys were involved, so some details are still unknown.
Two things stand out. The keys were in a hosted service because users had chosen to link them for convenience, and the weak point was a forgotten system that nobody was watching.
The Wider Pattern
The same recap describes several other incidents with a similar shape. Railway found unauthorised access to the systems that store customer environment variables and told customers to rotate their credentials. Attackers used stolen GitHub tokens from LiteLLM engineers to publish a malicious package release that was live for about an hour and forty minutes. The maker of TiDB Cloud reported an intruder using stolen service account credentials to copy a table of encrypted API keys.
The causes differed, but the shape is the same. One stolen secret opens a door, and a door opened with a valid secret often looks like normal use. That is why it makes sense to assume some secret, somewhere, will eventually leak, and to build so that a leak is survivable.
If a Key Leaks: Six Steps in Order
First, revoke the key. Log in to the provider, delete or disable it, create a replacement and update the applications that use it. Every minute the key stays live is a minute it can be abused, so do this before anything else.
Second, check your usage. Look at the provider’s dashboard for requests, models or charges you do not recognise, and note the times, since they help you work out when the misuse began.
Third, contact the provider. In the OpenCode case, providers blocked exposed keys and refunds were reported, so it costs nothing to ask what they can do for you.
Fourth, rotate related secrets. If one key leaked from a tool, assume the others stored beside it may have leaked too.
Fifth, find the cause. Work out whether the key was in a hosted tool, a committed file or a CI setting, and close that gap so it does not happen again.
Sixth, write it up. Record what happened and update your practices. If personal data may have been involved, involve your legal advisers. This is general information and not legal advice.
Making the Next Leak Survivable
You cannot prevent every leak, especially from tools you did not build. What you can do is make leaks small, and the first way is to use short-lived secrets. A long-lived key that leaks in January still works in October, whereas a credential that expires on its own has a narrow window of use even if it is stolen. Where your platform supports it, prefer short-lived credentials over static keys. Some teams run a small gateway that holds the real provider key, so applications authenticate with an expiring token and never see the key itself. Where you must use a static key, rotate it on a schedule and whenever someone leaves or a tool is retired.
The second way is hard spend limits. Short-lived keys reduce the chance of a problem, and spend limits reduce its cost. According to the summaries in Kilowott’s post, OpenAI offers monthly limits at the organisation or project level with an option for a hard limit. Anthropic offers monthly limits per workspace, though not on the Default Workspace. Google announced project spend caps for the Gemini API in March 2026, which are described as experimental and can lag by around ten minutes. Provider details change often, so check each one’s current documentation.
Notice what is missing from that list. None of the sources describes a cap on a single key. The practical workaround is to give each tool its own project or workspace with its own cap, so one leaked key can only ever spend one budget.
The third way is to separate and scope your keys. Use one key per tool, per project and per environment, so that a staging key does not work in production and a coding assistant does not share a key with your customer-facing application. If every tool shares one master key, one breach exposes everything.
The fourth way is to detect problems early. Most of the damage in these incidents happened overnight, so set an alert at a level that would be unusual for you and well below your hard cap. An alert tells you something has gone wrong, while a hard limit stops it going further, so use both.
Questions to Ask Before You Store a Key With a Vendor
Any hosted tool that holds your keys inherits your risk. Before you hand one over, ask how keys are stored and encrypted and who inside the company can access them. Ask what happens to legacy systems and whether they are included in security reviews. Ask whether you can use scoped or short-lived credentials instead of a master key, how quickly you will be told if something goes wrong, and whether you can revoke a key from your side and see what it was used for. The OpenCode case is a reminder of why the legacy-system question matters, because a system being decommissioned is still a live system until it is switched off.
Where to Start This Week
If you only do a few things, begin by finding every place your AI provider keys are stored, including tools, code, CI settings and shared documents. Then set a hard monthly limit on every provider project or workspace, and move any tool out of a default workspace where limits are not available. Make sure each tool has its own key, and retire any that are shared. Finally, create a spend alert at a level that would be unusual for you, so you hear about a problem in hours and not weeks. Final Thoughts
It is tempting to respond to news like this by promising to be more careful. Care helps, but it is not a plan. Keys will leak from tools you did not build, systems you did not know existed and accounts you did not think about. The teams that stay calm when that happens made the leak small in advance, with short-lived credentials that expire, separate keys that contain the damage, caps that stop the bill and alerts that tell them quickly.
If you would like help putting that structure in place, [Kilowott](https://kilowott.com/) offers [Kilowott Intelligence](https://kilowott.com/services/kilowott-intelligence/) for reviewing how AI tools are connected and governed, and [automation](https://kilowott.com/services/automation/) for key rotation and spend monitoring. Their [web and e-commerce](https://kilowott.com/services/web-and-ecommerce/) team can also check the credentials behind your sites. You can browse their [case studies](https://kilowott.com/case-study/) or [get in touch.](https://kilowott.com/contact-us/)
Source: [Short-Lived Secrets and Spend Limits: How to Protect Your AI Keys After October’s Breaches](https://kilowott.com/protect-ai-api-keys/) by Kilowott.