Leaked AI API Key? What to Do in the First Hour

Revoke the key at the provider — OpenAI, Anthropic, or Google — not in whatever tool stored it. Deleting a key in a third-party tool's dashboard doesn't revoke it, and a budget set inside that tool can't cap traffic that bypasses it. Then: create a replacement key per tool, update every app and script that used the old one, review your provider billing for usage you didn't run, and set a provider-side spend cap. Finally, check that your own site isn't serving keys to anyone who asks for a dotfile.

That last part isn't hypothetical. In October 2026, OpenCode reported that a breach of its Console "may have exposed" provider keys saved by 1.4% of Console users (OpenCode on X; The Hacker News). And the same month, one developer logged 108 requests in a single minute against his production server, all probing for files like /.env.anthropic and /.claude/settings.json (@chiefofautism on X). Two different leak paths, one response playbook.

Two ways your AI API key leaks

| | Path 1: a vendor gets breached | Path 2: your own deploy serves it | |---|---|---| | What happens | A hosted tool that stored your OpenAI/Anthropic/Google key is compromised, and saved keys may be exposed | Your .env*, .claude/, .aws/, or .git/ files ship in a build and are reachable on the live site | | Who finds it | The vendor notifies you (or the news does) | A machine-speed scanner probing common paths — you may never get a notice | | Example | OpenCode Console, October 2026 (see below) | Bots requesting /.env.anthropic, /.env.openai, /.claude/settings.json | | First-hour response | Identical (below) | Identical (below) — plus fix the deployment | | Prevention | Fewer places holding your key; provider-side caps | Build hygiene; deny rules; deploy checks |

The response is the same because the failure is the same: a key that was supposed to be private is now treated as public. Act as if someone has it, because someone may.

The first-hour response checklist

Work through these in order. Steps 2–5 are the ones that actually stop the bleeding.

1. Confirm scope. Which keys were in the affected tool or workspace? For the OpenCode incident, affected Console users received an email with the subject "Action Required: Potential provider key breach" — and per OpenCode, anyone who didn't get one wasn't affected (The Hacker News). For your own exposure, the 5-minute check below tells you which files were reachable.

2. Revoke the key at the provider. This is the step people get wrong. Deleting the key in the tool that stored it (or relying on that tool's budget) does nothing to a copied key — The Hacker News notes explicitly that deleting a key in OpenCode Console does not revoke it, and a Console budget cannot cap use of the key elsewhere. Each provider has its own process: - OpenAI: revoke and rotate keys, and set spend limits with hard enforcement (key safety best practices; spend limits). OpenAI's production guidance is to create the replacement first, migrate, then revoke the old key (production best practices). - Anthropic: if you suspect a key is compromised, delete it and create a new one (suspected compromised key); keep separate keys per use and set spend limits via the Billing page (key best practices); rate and spend limits are documented at platform.claude.com. - Google: for Gemini API keys, disable or delete the compromised key and use key restrictions (Gemini API key docs). Google Cloud also offers spend cap budgets, which automatically pause usage of eligible services — including the Gemini API — once gross, estimated costs exceed your budget amount for the month (budgets and spend caps). The caps have real limits: one budget covers a single project and a single eligible service, the period runs monthly from the 1st, enforcement isn't instant, and overages up to the cap are still billed. Separately, alerts-only budgets notify at the thresholds you configure (Google Cloud defaults to 50%, 90%, and 100%; see budget alerts) but don't stop traffic. For Google Cloud API keys, restrict, rotate, and delete them (Cloud API key docs); you can also cap API usage via quotas.

Note the honest limits here: OpenAI's docs say spend alerts alone don't stop traffic — to cut off spend after tracked spend reaches a configured amount, you enforce a hard spend limit (which returns 429). Google Cloud is the same split: alerts-only budgets notify, spend cap budgets enforce. Either way, only the enforcement layer actually stops a leaked key.

1. Create a replacement key per tool, and update everything that used the old one. Every app, script, cron job, and CI secret. One key per tool from here on — it shrinks the blast radius of the next leak and makes the source of any future usage traceable (The Hacker News).

1. Review provider usage and billing for requests you didn't make. For the OpenCode incident, The Hacker News advises going back to at least October 16, 2026 (the night the intruder reached a legacy system). Look for models you don't use, volumes you can't explain, and requests outside your app's normal pattern.

1. Set a provider-side spend limit or alert. Caps configured inside a third-party tool can't see traffic that bypasses that tool. The cap belongs at the provider, where every request arrives. (OpenAI: spend limits. Anthropic: Billing page limits. Google: spend caps and quotas.)

1. Write down where every key lives. A key inventory — which key, which tool, which provider project, where it's stored — turns the next rotation from an archaeology project into a ten-minute task. If you run agents that hold credentials, this is the same discipline as tool governance (governing which MCP tools agents can use).

1. If the key was ever in a deployed artifact or a public repo, treat it as leaked even without a breach notice. Git history counts. Built frontend bundles count. India's CERT-In puts it plainly in Advisory CIAD-2026-0049: after "any credential exposure or confirmed access, treat the environment as compromised until forensically cleared. Retest after remediation."

Ask about Governed AI Ops — key inventory, per-agent keys, provider-side caps, and a deploy gate that keeps secrets out of shipped artifacts: tacavar.com/governed-ai-ops/.

What happened at OpenCode (and what it didn't say)

The facts, from OpenCode's own post and The Hacker News's write-up:

• On the night of October 16, 2026, an intruder reached a legacy system in OpenCode's infrastructure. OpenCode described the incident as related to "a large scale distillation attack" (OpenCode on X).
• Provider keys saved in OpenCode Console workspaces may have been exposed for 1.4% of Console users — specifically users who had linked an outside provider. OpenCode notified affected users by email on the morning of October 17.
• Per The Hacker News, anyone who didn't receive the "Action Required: Potential provider key breach" email was not affected, and the keys at risk were the ones saved in Console — the CLI and desktop apps keep keys on the user's machine.
• User reports of financial loss circulating alongside the story are attributed by The Hacker News to individual users; OpenCode has not confirmed theft.

That's the whole claim set. No actor has been named, no theft confirmed, and this post makes no speculation beyond the sources above.

The other leak: bots are probing for `/.env.anthropic` and `/.claude/settings.json`

Vendors are only half the story. The other way AI keys leak is through your own deploy: config files that were never meant to ship ending up reachable on your production site, where anything on the internet can just ask for them.

One developer's production log, posted October 20, 2026: 108 requests in one minute, all hitting paths like /.env.anthropic, /.env.openai, and /.claude/settings.json (@chiefofautism on X). A follow-up summary of his log screenshots, posted by another account, adds that the 108 requests covered 108 unique paths in about 3.2 seconds, also listing /.aws/credentials and /.git/config, and that the IP was banned on the second request (@0xwolverines on X — attributed, since it summarizes rather than shows the original log). One server, one night. No conclusions about how common this is — but the probing pattern is clear.

What these files are, briefly:

• **.env / .env.anthropic / .env.openai** — dotfiles holding environment variables, very often including API keys for AI providers. Naming them per provider is a convenience habit that also tells a scanner exactly which key you're holding.
• **.claude/settings.json** — Claude Code's project settings file. It's configuration for your local agent, not something a web server should ever serve; if it's in your web root and the server follows symlinks or the build copies it, it's one request away from public.
• **.aws/credentials, .git/config** — older leaks, still probed. Wherever AI keys exist, the classic paths get checked too.

CERT-In's Advisory CIAD-2026-0049 names the root weakness conventionally: "Credentials and keys exposed in source code, public repository history, configuration files, client applications and public web content." Its countermeasures section says to "Detect attacks at machine speed. Apply rate-based and per-second API anomaly detection. Alert on enumeration bursts…" — which is exactly the shape of a 108-requests-in-a-minute probe. This is a machine-speed scanner, possibly agent-driven; agents are louder than humans, and rate-based detection is what catches them.

If the idea of agents leaking data unsettles you, note this is the credentials version of a broader problem — the data-egress version looks different (how agents leak data through Slack), but the governance fix rhymes.

The 5-minute exposure check

Run this against your own site now. These commands are safe — they check one URL each on your site and print the HTTP status only.

Step 1 — ask your own server for the files. Expect 404 or 403 on every line. **Any 200 means rotate that key now, then fix the deploy.**

``bash for p in /.env /.env.anthropic /.env.openai /.claude/settings.json /.aws/credentials /.git/config; do printf '%s ' "$p" curl -s -o /dev/null -w '%{http_code}\n' "https://yoursite.com$p" done ``

Step 2 — check the build context. Your .dockerignore (or deploy excludes) must cover .env*, .claude/, .aws/, and .git/. If your build copies the whole project directory, these files ride along.

Step 3 — search the built output for key-shaped strings. List file names only — never print the matches, and never paste matches anywhere:

``bash grep -rlE '(sk-[A-Za-z0-9]{20}|AIza[A-Za-z0-9_-]{30})' dist/ build/ .next/ 2>/dev/null ``

The -l flag prints file names only. A broader repo-and-bundle secrets audit is Step 2 of our vibe-coded production hardening checklist — that checklist covers the repo and frontend bundle; this post's concern is the dotfiles and agent config it doesn't cover.

Step 4 — check whether you've already been probed. Grep your web server's access logs for those paths:

``bash grep -E '/\.env|/\.claude|/\.aws|/\.git' /var/log/nginx/access.log | head -20 ``

Step 5 — make it a CI gate. Add a post-deploy step that curls the same paths against production and fails the build on any 200. A check that only runs when someone remembers is a check that doesn't run.

Block fast probes

Detection and blocking at the edge, generic across nginx/Caddy/Cloudflare:

• Deny dotfiles at the edge or web server — a rule rejecting any URI path starting with /. — but keep /.well-known/ allowed (ACME certificate challenges and other standards live there).
• Trap rule: ban an IP on its first dotfile probe. No legitimate client requests /.env.anthropic. One strike is generous.
• Alert on enumeration bursts: unique-paths-per-minute is the signature. This is CERT-In's "rate-based and per-second API anomaly detection" — machine-speed probing needs machine-speed detection, the same containment principle behind agent firewalls in production.

No exploit steps here on purpose: the defensive layer is one deny rule and one alert, and neither requires understanding the scanner any more deeply than "it asks for files that shouldn't exist."

Store keys so one leak can't run up a bill

The checklist above is response. This is posture, and it's shorter:

• One key per tool or agent. Blast radius and traceability, as above.
• Least privilege. Use project-scoped or restricted keys wherever the provider supports them (OpenAI project keys, Anthropic workspace keys, Google key restrictions — see each provider's docs linked in step 2).
• Caps and alerts at the provider, not only inside tools. And know which is which: OpenAI and Anthropic both offer provider-side spend limits (Anthropic sets them on the Billing page, though Custom-tier orgs are uncapped), and Google Cloud spend cap budgets pause eligible services — including the Gemini API — once the cap is hit. Alerts-only budgets notify; spend caps and quotas stop traffic. For agent payment budgets enforced outside the model entirely, see x402 agent payments and spend controls.
• A secrets manager, not dotfiles in the web root. If a key must be available at runtime, it should come from a secret store at boot — never from a file the web server could serve.
• A rotation runbook. The key inventory from step 6 plus this checklist, written down before you need it. Tool governance — deciding which agents and tools get credentials at all — is the upstream question (MCP tool governance in production).

Where this becomes a standing function

Every individual practice above — key inventory, per-agent keys, provider caps, a deploy-artifact gate, anomaly-based bans — is a one-time fix that decays without an owner. Run together and maintained, they're a standing operating function rather than a project.

That's the territory of Governed AI Ops. If you'd rather this be someone's job than everyone's hope, ask about Governed AI Ops. And if you want to know what your site is serving right now, run a free scan first.

FAQ

Does deleting my API key in the tool that stored it revoke it? No. Deleting a key in a third-party tool's dashboard removes it from that tool, not from the provider. Revoke at the provider — The Hacker News notes this explicitly for OpenCode Console, where deleting the key in Console does not revoke it.

What should I do in the first hour after an AI API key leaks? Confirm scope, revoke the key at the provider (OpenAI, Anthropic, or Google), create a per-tool replacement and update every consumer, review billing back to the exposure date, set a provider-side spend limit, write down where every key lives, and treat any key that was in a deploy or public repo as leaked.

Will a tool's budget limit stop someone using my stolen key? No. A third-party tool's budget only sees traffic through its own gateway. Use of the raw key against the provider bypasses it entirely. The cap has to sit at the provider.

**How do I check whether my site exposes .env or .claude/settings.json?** Request those paths with curl and check the status code: curl -s -o /dev/null -w '%{http_code}\n' https://yoursite.com/.env. Expect 404 or 403. Any 200 means rotate the key in that file now.

**Why are bots requesting /.env.anthropic and /.claude/settings.json?** They're looking for AI provider keys and agent configuration left in web-servable paths. One developer logged 108 such requests in a minute against his production server in October 2026. That's one server, not a prevalence figure — but the pattern is clear enough to defend against.

Should every AI tool or agent get its own API key? Yes. Separate keys per use is The Hacker News's guidance from the OpenCode incident: a smaller blast radius when something leaks, and usage you can attribute to a specific tool.

Was I affected by the OpenCode breach? Per OpenCode, affected Console users were emailed ("Action Required: Potential provider key breach") and anyone who didn't get an email wasn't affected. Per The Hacker News, the keys at risk were those saved in Console workspaces; the CLI and desktop apps keep keys on your machine. If you did get the email, run the first-hour checklist above — and note that deleting the key in Console isn't enough.

Out of scope

This post is operational guidance, not legal or compliance advice, and not a review of OpenCode or any vendor. It contains no attack tooling and no instructions for probing anyone else's sites — run the checks against your own infrastructure only.