Over the weekend, the AI coding tool OpenCode said attackers broke into an older system and affected 1.4% of users of OpenCode Console, an online platform where some users store the API keys they use to reach AI services. TechCrunch reported that developers posted spending alerts from OpenAI, Anthropic and Google overnight, with some individual accounts showing hundreds of dollars in unauthorized charges and a few above $1,000. Anthropic and Google blocked the keys they believed were exposed, and OpenAI said it worked with OpenCode to refund affected API customers. The open-source app and command-line tool were not affected, according to a co-founder. The incident is a useful prompt to check how you store and limit the keys your AI tools hold.

This guide is general good practice, not a description of what any one vendor did. It takes about 30 minutes for a personal setup.

Why an API key is worth protecting

An API key is a password that bills you. Anyone holding it can send requests, and the provider charges the account that owns it. Unlike a stolen login, a key does not trigger a second-factor prompt. Attackers who find one can also resell access or, as OpenCode speculated, use high-volume outputs for model distillation, although skeptics quoted by TechCrunch said that framing was unproven.

AI coding tools raise the stakes because they combine three things: they need keys for several providers, they run on your machine or a hosted console, and they act on files and terminals with real permissions. The OWASP Top 10 for LLM applications lists excessive agency and sensitive information disclosure among the main risks of such systems, which is the same family of problems.

Step 1: Inventory your keys

List every place a key might live: provider dashboards, hosted consoles of coding tools, .env files, shell profiles, CI settings and chat history. For each key, note what it can do, which provider issued it, and who or what uses it. Delete any that you cannot account for. Fewer keys means fewer things to lose.

Step 2: Use one key per tool and purpose

Create a separate key for each tool, project and environment, and name it clearly, for example “editor-agent-laptop”. When a breach happens, you can revoke just that key without breaking everything else. It also makes billing reports readable: you can see which tool ran up charges.

Avoid sharing a single master key across teammates. Individual keys let you tell who or what made a request.

Step 3: Restrict what each key can do

Most providers let you limit a key by project, workspace or permission. Where available:

  • Give the key access only to the models and endpoints the tool needs.
  • Use read-only or reduced scopes for experiments.
  • Restrict by allowed IP address or network if the provider supports it and your setup is stable.

This is the principle of least privilege: a key should be able to do only what its job requires, so a leak has a small blast radius.

Step 4: Cap spending and set alerts

A hard budget is the cheapest insurance against a leaked key. In each provider’s billing settings:

  1. Set a monthly spending limit well below what you would be comfortable losing.
  2. Add email or push alerts at several thresholds, such as 50% and 80% of the limit.
  3. Prefer prepaid credit for personal projects, because it caps the loss at the balance.

Developers in the OpenCode incident reported noticing the problem through spend alerts, which shows why they are worth setting.

Step 5: Keep keys out of code and chat

Never paste a key into source files, README examples, issue trackers or an AI chat. Instead:

  • Store keys in environment variables or a secrets manager, and load them at runtime.
  • Add .env and similar files to .gitignore before the first commit.
  • Use your operating system’s keychain or a team password manager for local storage.
  • Do not let an agent print environment variables into logs or transcripts.

If you use a hosted console that stores keys for you, ask whether it is necessary. Where a tool supports bring-your-own-key locally, a local environment variable keeps the secret off a shared service. As a co-founder noted, the exposed keys in this incident were confined to the Console, not the local tool.

Step 6: Turn on secret scanning

Secret scanning looks for credentials in repositories and alerts you when one is committed. GitHub’s documentation describes how its secret scanning works and which partner patterns it recognizes; many providers participate so that leaked keys can be revoked automatically. Enable it on every repository, including private ones, and add a pre-commit scanner so mistakes are caught before they leave your machine.

Step 7: Rotate on a schedule and after any scare

Rotate keys on a regular schedule, and immediately if you see unexplained usage, receive a breach notice, or share a laptop or screen recording that might have shown one. Rotation is quick if you did Step 2: create the new key, update the tool, revoke the old one, and check the usage log for requests you do not recognize.

Step 8: Limit what the agent itself can do

Keys are only part of the exposure. Run coding agents in a project directory without access to your home folder, require approval for commands that touch the network or delete files, and read the tool’s permission settings. Our explainer on prompt injection shows how untrusted text can steer an agent into misusing the access it already has.

What to watch next

  • Whether OpenCode publishes a post-incident report explaining how the older system was breached.
  • Provider features that make keys short-lived or tied to a device.
  • More coding tools moving key storage to local keychains.
  • Guidance on how defenders get access to models that do not refuse to analyze malware.

Key takeaways

  • An API key is a bearer credential: whoever holds it can spend your money.
  • Use a separate, narrowly scoped key per tool and project.
  • Set a hard spending cap and alerts at the provider.
  • Keep keys in environment variables or a secrets manager, never in code or chat.
  • Enable secret scanning and rotate keys after any suspicion.

Frequently asked questions

What should I do if I think a key leaked?

Revoke it in the provider dashboard first, then create a replacement, update your tools and review the usage log. Contact the provider if you see charges you did not make.

Are environment variables safe enough?

They are better than hard-coding a key, but they can still leak through logs or process listings. A secrets manager or system keychain adds protection.

Do I need this for a hobby project?

Yes. A budget cap and a separate key take minutes and limit the damage if a key ever appears in a public repository.