Leaked OpenAI or Anthropic API Key? What to Do in the First Hour

Short answer: revoke the key in the provider's console first. Removing it from a commit, a .env file or a third-party tool leaves it valid for anyone who already copied it. Then issue a new key for each app that needs one, check usage for the leak window, set a spend limit that blocks requests, and only after that clean up git history and other copies.

This guide covers what to do with a leaked API key from OpenAI, Anthropic or Google Gemini. Every console path and quote below was checked against the cited source on October 20, 2026. The trigger for writing it was the OpenCode Console breach, disclosed on October 17, 2026: provider keys that users had saved in the tool may have been exposed, and several users reported drained balances.

A note on words. Revoke here means making the key unusable at the provider: OpenAI and Anthropic call this deleting the key, Google calls it disabling or deleting. Remove means deleting your copy of the key from a file, a repository or a tool. Only revoking stops abuse.

What should you do first when an API key leaks?

Short answer: revoke the old key at the provider, then replace it, then measure the damage, then cap spending, then clean up. Any other order leaves the key usable while you investigate.

  1. Revoke the key at the provider. Use the provider's console, because the tool or repository where the key leaked has no say over whether it still works.

  2. Create replacement keys, one per app or environment. If one shared key powered five services, issue five keys so the next incident can be contained to one of them.

  3. Deploy the new keys and confirm each service works.

  4. Review usage for the leak window and save what you find: requests, models, cost per key.

  5. Set a hard spend limit, if you do not have one. Alerts only notify you.

  6. Contact provider support if you see charges you did not make.

  7. Remove the key from every place it was copied to: git history, CI variables, chat logs, third-party tools.

The OWASP Secrets Management Cheat Sheet also starts with revocation, then rotation, then removing copies:

"Keys that were exposed should undergo immediate revocation."

How fast leaked keys get used is well documented for cloud credentials. In a 2023 honeypot by Palo Alto Networks Unit 42, an attacker found and used AWS keys pushed to GitHub within five minutes. Those were AWS keys, and while preparing this guide we found no comparable primary measurement for OpenAI or Anthropic keys in public sources. Assume the clock starts at the moment of exposure.

How do you revoke a leaked OpenAI API key?

Short answer: delete the key on the API keys page of the OpenAI platform (platform.openai.com/api-keys). For project keys, open organization settings, select the project and go to API Keys. Then review usage and contact OpenAI support.

Under the heading "Revoke an exposed API key", OpenAI's help center lists three steps:

"1. Delete the affected key through the API key dashboard. 2. Review your API usage for unexpected activity and keep the details. 3. Contact OpenAI Support."

During an incident, three details matter:

  • Find the right key. OpenAI projects have two kinds of keys: user keys and service account keys. Service account keys belong to the project, so removing a person from the organization does not revoke them. Check both lists.

  • Check whether OpenAI already disabled it. According to OpenAI, "when OpenAI detects an API key on the public internet, or leaked inside an app in an app store, the API key is disabled immediately." That covers public leaks. A key stolen from a vendor's database does not show up in public scanning, so revoke it yourself.

  • Restrict new long-lived keys. In the API key governance settings, admins can allow only service account keys, only user-owned project keys, or disable new key creation. These settings apply only to new keys, so existing keys still have to be revoked one by one.

How do you revoke a leaked Anthropic API key?

Short answer: go to platform.claude.com/settings/keys, open the menu next to the key and select "Delete API key". To switch a key off through automation, the Admin API can set its status to inactive.

The Anthropic help center describes the console path:

"If you suspect that your API key may be compromised, we recommend revoking the key immediately ... going to the API keys page (platform.claude.com/settings/keys), clicking the menu (i.e. the three horizontal dots) next to the key in question, and selecting 'Delete API key.'"

When you do not know which key leaked, two Anthropic features help:

  • Workspaces. Keys can be scoped to a single workspace. Archiving a workspace archives every API key created for it within seconds. Anthropic warns that this cannot be undone, so treat it as an emergency switch for a whole team or product.

  • Service accounts. Anthropic documents that a service account key keeps working even after the user who created it is removed. If the leak came from someone's laptop, offboarding that person does not cover these keys. Check the service accounts list separately.

In the OpenCode Console breach, Anthropic also acted on its side. Lydia Hallie from Anthropic wrote on October 17: "We've been working with OpenCode on yesterday's breach and have revoked Claude API keys we believe were affected" (post on X). She advised anyone who had saved a key in OpenCode to create a new one.

How do you handle a leaked Gemini API key?

Short answer: generate a new key, deploy it, then disable the leaked key in the Google Cloud console and audit usage. Google orders the steps this way to avoid downtime. If the key is being abused right now, disable it first.

The Gemini API documentation gives this checklist:

"1. Generate a new key ... 2. Update your application ... 3. Disable or delete the compromised key: Disable the leaked key in the Cloud console once the new key is verified. Do not delete the old key until the new key is fully active to avoid application downtime. 4. Audit usage."

Gemini keys differ from OpenAI and Anthropic keys in three ways:

  • GitHub does not block them on push. In GitHub's list of supported secret patterns, google_gemini_api_key has user alerts only, with no partner reporting and no push protection. Standard Gemini keys share the format of other Google API keys, and GitHub's google_api_key pattern is reported to Google, but it has no push protection either. A Gemini key can reach a public repository without being stopped at push time.

  • Old Google Cloud API keys can be Gemini keys. Truffle Security reported in February 2026 that enabling the Gemini API on a Google Cloud project can give existing API keys in that project access to Gemini endpoints. A Maps or Firebase key embedded in a web page years ago could then call Gemini. Google now rejects unrestricted standard keys on the Gemini API, but a restricted key whose allowed APIs include Gemini still works, so check the restrictions on old keys.

  • Google blocks known leaked keys. Requests with such a key fail with "Your API key was reported as leaked. Please use another API key." Since May 28, 2026, new keys created in Google AI Studio are authorization keys, which Google describes as having "fast-acting leaked key enforcement."

Restrict every key you keep: in AI Studio, add a restriction to the Gemini API only. In the Cloud console, restrictions are under APIs & Services, Credentials.

Know where every copy of a key lives. A key that sits in a dozen .env files, chat threads and CI variables can take hours to rotate. Ennote keeps passwords, environment variables and API keys in one place with role-based access, so replacing a key means updating it in one place. Every access to a secret in Ennote is written to an audit log, with retention depending on the plan. The Developer plan is free.

Should you revoke now or create the new key first?

Short answer: if there are signs of abuse, or the key was public, revoke now and accept a short outage. If the exposure is contained, for example a key that appeared in a private log, create and deploy the replacement first, then revoke within minutes.

OpenAI and Anthropic say revoke immediately. Google says replace first, then disable. The right order depends on the situation:

Situation

Order

Why

Key is in a public repo, a client-side bundle or a breached third-party tool

Revoke first, then replace

Every minute of exposure can be billed to you

Usage graph shows requests you did not make

Revoke first, then replace

Abuse is already happening

Key appeared in a private log or internal chat, no unusual usage

Replace first, revoke right after deploy

Low exposure; downtime costs more

Key is shared by many services and you do not know all of them

Revoke first

Waiting until you find every consumer can take hours



The last row needs preparation. If you cannot list every service that uses a key, that list is the first thing to fix after the incident. Anthropic recommends separate keys per environment and use case, so that you can "quickly disable just that use case."

How do you find out what the leaked key cost you?

Short answer: open the provider's usage page for the period since the key leaked, filter by key or project where possible, and export what you see before you talk to support.

Provider

Where to look

Useful detail

OpenAI

platform.openai.com/usage

Keys created before December 20, 2023 may show usage as "Untracked" unless tracking was enabled

Anthropic

platform.claude.com/usage, /cost and /logs

The Usage and Cost Admin API filters by API key, workspace and model; it is not available for individual accounts

Google

Cloud Billing reports for the project

Google notes that actual costs can take more than 24 hours to appear



What to save for support: the key name or ID (never the key itself), when it was created, when it leaked, when you revoked it, and the requests or costs you do not recognize.

Report unrecognized charges to the provider's support with that evidence. Any refund is the provider's decision. After the OpenCode Console breach, users publicly reported unauthorized charges from under 200 to about 1,700 dollars per account (Dealroom, Hacker News).

How do you cap spending before the next leak?

Short answer: set a hard limit. On OpenAI that is "Enforce a hard limit" in organization or project limits. On Anthropic it is a spend limit on the Billing page. On Google Cloud it is a spend cap budget, which is separate from a regular budget.

An alert is easy to mistake for a cap. OpenAI's documentation says it directly: "Spend alerts do not enforce a cap." Google's regular budgets are alerts-only too.

Provider

Setting that blocks requests

What happens at the limit

Caveat

OpenAI

Settings, Organization, Limits: Edit spend limit, Enforce a hard limit; also per project

HTTP 429 organization_spend_limit_exceeded or project_spend_limit_exceeded

"Enforcement is not instantaneous," so spend can slightly exceed the limit

Anthropic

platform.claude.com/settings/billing, Spend limits

HTTP 400 invalid_request_error, "You have reached your specified API usage limits"

You cannot set a spend limit on the default workspace

Google Cloud

Spend cap budget for the Gemini API or Vertex AI

New usage for that service in that project is paused

One project and one service per cap; enforcement is not instantaneous and overage stays your responsibility



You still have to revoke the leaked key. The limit caps what the next leak can cost before anyone notices it.

Does the provider revoke a leaked key automatically?

Short answer: sometimes. OpenAI and Anthropic disable keys they detect in public places, including through GitHub's secret scanning partner program. Gemini keys are not blocked on push. A key stolen from a private system, such as a vendor's database, is not found by public scanning, so you revoke it yourself.

Where the key leaked

OpenAI

Anthropic

Google Gemini

Public GitHub repo

Partner pattern; OpenAI disables publicly exposed keys

Partner pattern; Anthropic deactivates the key and emails the user

No Gemini-specific partner pattern; standard keys match the Google API key pattern, which is reported to Google

Push to GitHub

Push protection blocks openai_api_key

Push protection blocks Anthropic keys, including the newer service and user key types since October 13, 2026

No push protection for Gemini or Google API keys

Breached third-party tool or private server

You revoke

You revoke (Anthropic revoked affected keys after the OpenCode breach)

You revoke



For the public-repo case, Anthropic's help center is explicit:

"To prevent potential abuse, Anthropic automatically deactivates the exposed API key."

Automatic revocation is a safety net with gaps. The provider makes the call. GitHub's partner program documentation says partners decide "whether they should revoke the secret, issue a new secret, or contact you directly". In September 2026, Truffle Security reported that 543,699 credentials exposed in public GitHub repos were still live when tested in July 2026.

Is deleting the commit enough?

Short answer: no. Revoke the key first. A rewritten history still leaves the key in clones, forks, cached commit views and pull requests.

GitHub's guide to removing sensitive data starts with revocation:

"if the sensitive data you need to remove is a secret ... then as a first step you need to revoke and/or rotate that secret. Once the secret is revoked or rotated, it can no longer be used for access, and that may be sufficient to solve your problem."

After rewriting history, commits can still be reached "in any clones or forks of your repository," directly via SHA-1 in cached views on GitHub, and through pull requests that reference them. If you still want the history clean, GitHub recommends git-filter-repo with the sensitive data removal option:

# Requires git-filter-repo 2.47 or later. Rewrites history: coordinate with your team first.

git filter-repo --sensitive-data-removal --replace-text expressions.txt

expressions.txt lists the strings to replace, one per line. After a force push, everyone with a local clone has to re-clone or rebase, or the key comes back with their next push.

Why are third-party AI tools a leak path?

Short answer: any tool that stores your provider key becomes another place it can leak from. Removing the key from that tool deletes the tool's copy; the key stays valid until you revoke it at the provider.

The OpenCode Console stored workspace keys so team members could use models without seeing the keys. OpenCode's email to affected users was quoted on Hacker News. It says attackers accessed "a legacy system that we were in the process of decommissioning". It also says that "third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed." OpenCode asked users to "revoke and replace those keys through the relevant provider's dashboard."

The same applies to any tool that asks for your provider key:

  • Revoke at the source when the tool reports an incident, even if you already removed the key from its settings.

  • Give each tool its own key. A key used only by one tool can be revoked without touching your production services, and its usage graph shows exactly what that tool did.

Anthropic lists third-party tools among the most frequent causes of key leaks, and OpenAI's help center advises caution "with third-party libraries, frameworks, and tools that request access to your API key."

How do you stop the next key from leaking?

Short answer: one key per app and environment, no keys in client-side code or committed files, short-lived credentials where the provider supports them, and a single store for secrets with access control and an audit log.

  • One key per app, per environment, per tool. Revocation then breaks one thing, and usage per key tells you where abuse came from.

  • No keys in browsers or mobile apps. A VITE_ or NEXT_PUBLIC_ variable ends up in the JavaScript bundle. Call the provider from your server.

  • No keys in committed files. Keep .env out of git. Push protection for users is on by default and blocks pushes of supported secrets to public repositories. Push protection for a repository, which also covers private repositories, requires GitHub Secret Protection and stays off until an admin enables it.

  • Shorter lifetimes. OpenAI supports expiring project keys and workload identity federation instead of long-lived keys. Anthropic suggests rotating keys every 90 days.

  • Hard spend limits on every organization and project.

  • One place where secrets live. Keys copied between laptops, chats and CI variables are hard to rotate because nobody knows every copy. A secret manager with role-based access, version history and an audit log turns rotation into one change in one place.

Before you close the incident, check four things:

  1. The old key is deleted or disabled in the provider console.

  2. Every service runs on its own new key.

  3. A hard spend limit is set.

  4. No copy of the old key is left in git, CI variables, chats or tools.

For the habits that cause these leaks in the first place, see 5 risky ways your team shares secrets. For long-lived tokens in pipelines, see Personal access tokens, headless CI/CD and the 30-day hard limit. To hand a new key to a contractor, use a one-time link instead of a chat message.

Sources

Put your API keys where you can rotate them. Ennote stores passwords, API keys and environment variables with role-based access, version history and an audit log of every access, and syncs them to Kubernetes. Start for free on the Developer plan.