API key leaked: what to do, in order, before you touch the code

What to do first when an API key leaks

A leaked API key keeps working for anyone who copied it until the provider refuses it, whatever you change in your own code. So the job, in order: put a new key somewhere it cannot leak, switch your app to it, revoke the old key, prove the old key fails, look for what was done with it, and only then clean up the code and the git history. GitHub's guidance on leaked credentials starts the same way: revoke or rotate the secret first, because a revoked credential can no longer be used, and that may be all you need.

If you only have a minute, open the provider's dashboard, find the key and revoke it. Your app may break until a new key is in place. If the usage page shows calls you did not make, that trade is worth it. Supabase's rotation guide agrees: if someone is actively using the leaked key, retire it right away, even if parts of your app stop working until you replace it.

Why deleting the key from your code does not un-leak it

Removing the line and pushing a new commit feels like the fix. It only changes the newest version of one file. The key itself, the string, is now in places you do not control:

The order: rotate, revoke, then fix the code

Rotating means creating a replacement and switching your app to it. Revoking means telling the provider to reject the old key. OpenAI's documentation describes this sequence for rotating a key: issue a replacement, update the workload, verify that it works, and revoke the previous key. After a leak you run the same steps with the waiting cut to minutes.

1. 1

   Decide: revoke now, or rotate first

   Open the provider's usage page. If you see calls, charges or objects you did not make, revoke the key immediately and accept the downtime. If not, rotating first keeps your app running, as long as the next steps take minutes, not days.

2. 2

   Create the new key where it cannot leak

   Store it as a server secret: your host's environment settings for server code, an Edge Function secret or a secret manager. Never in a variable starting with VITE_ or NEXT_PUBLIC_: the build copies those into the JavaScript every visitor downloads. If the old key leaked through your frontend, the new one must not take the same path. Supabase puts it bluntly: fix the root cause before you rotate, or the new key leaks the same way.

3. 3

   Deploy and verify

   Redeploy, then confirm the app works with the new key. Stripe, for example, shows request logs for each key, so you can watch the new key take traffic before you kill the old one.

4. 4

   Revoke the old key

   Delete, deactivate or expire it at the provider. Some dashboards offer a grace period in which both keys work: when you rotate a Stripe key, the old one can keep working for up to 7 days. After a leak, set the expiration to Now.

5. 5

   Prove the old key is dead

   Send one request with the old key and check that it fails. Keep the response and the time: if anyone asks when the key stopped working, you have the answer.

6. 6

   Then fix the code and the history

   Remove the key from the code, move the call to a server if it ran in the browser, delete old deployments that still serve it, and decide whether the git history needs rewriting. GitHub's view is that once the credential is revoked or rotated, rewriting history may not be warranted.

To test the old key from your terminal, read it without echoing it, so it stays out of your shell history, then call an endpoint that only reads:

read -rs OLD_KEY   # paste your own old key, then press Enter

# OpenAI: lists models, runs nothing
curl -s -o /dev/null -w "%{http_code}\n" https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OLD_KEY"

# Anthropic: lists models, runs nothing
curl -s -o /dev/null -w "%{http_code}\n" https://api.anthropic.com/v1/models \
  -H "x-api-key: $OLD_KEY" -H "anthropic-version: 2023-06-01"

# Stripe: reads the balance, changes nothing
curl -s -o /dev/null -w "%{http_code}\n" https://api.stripe.com/v1/balance \
  -u "$OLD_KEY:"

unset OLD_KEY

Check for abuse: usage, billing and logs

Write down two times: when the key was first exposed (the commit, the deploy, the moment you pasted it somewhere) and when you revoked it. Everything in between is the window to review. Start with what the key could reach: AWS's advice for an exposed access key is to work out which resources those credentials can access, since an IAM user's key carries that user's permissions, while a root user key has full access to every resource in the account.

If the key was committed, git can tell you when it first appeared. Search for a fragment of the key rather than the whole string:

# Use 8 or more characters from the middle of the key:
# prefixes such as sk- are shared by every key of that provider
git log --all --reverse -S "PART_OF_THE_KEY" --format="%h %ad %an %s" --date=iso | head -n 1

If you find abuse, write to the provider's support with the key's name or ID (never the key itself), the time window and what you saw. Then deal with what the key could reach. A Supabase service role key skips every row level security policy, so a leak there is a data incident: the service role key guide covers what to check in the database.

Per-provider steps for the keys that leak most

When the key was in your frontend bundle

One way a key leaks from an app built with an AI coding agent is a provider call made from the browser, with the key in a VITE_ or NEXT_PUBLIC_ variable. It works on the first try and ships the key to every visitor. OpenAI's documentation is explicit: keep secret keys out of browser code, mobile apps, source control, logs and customer-facing responses.

// Before: runs in the browser, so the key ships to every visitor
const res = await fetch("https://api.openai.com/v1/responses", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${import.meta.env.VITE_OPENAI_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ model: "your-model", input: prompt }),
});

// After: app/api/ai/route.ts runs on the server, the key stays there
import { getUser } from "@/lib/auth"; // your own session check

export async function POST(req: Request) {
  const user = await getUser(req);
  if (!user) return new Response("Sign in first", { status: 401 });

  const { prompt } = await req.json();
  const res = await fetch("https://api.openai.com/v1/responses", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ model: process.env.OPENAI_MODEL, input: String(prompt).slice(0, 4000) }),
  });
  return new Response(res.body, { status: res.status });
}

// In the browser, call your own route instead:
// await fetch("/api/ai", { method: "POST", body: JSON.stringify({ prompt }) });

Moving the call is half the fix. A server route that anyone can call without signing in, with no rate limit, is the same leak one step removed: strangers spend your credits through it instead of with your key. The unprotected AI endpoint guide covers what that route needs.

Not every key in a bundle is a leak. Stripe's publishable key (pk_) and Supabase's publishable or anon key are made for browsers; the risk there sits in your server code and your row level security, not in the key. Our guide to API keys exposed in the frontend sorts the public keys from the secret ones. And if the key leaked because your host served your .env file, every key in that file needs rotating, not only the one you noticed: see exposed .env files.

How to stop the next leak

• Call paid APIs from a server function that checks the user is signed in. The browser gets only keys built to be public.
• Keep secrets in your host's environment settings or a secret manager, and add .env to .gitignore before the first commit.
• Leave GitHub push protection on. Push protection for users is on by default and stops you pushing supported secrets to public repositories; turn it on for the repository as well, so a bypass creates an alert.
• Run a secret scanner such as Gitleaks in CI, as Anthropic recommends, so a key in a pull request is caught before it merges.
• Use one key per app and per environment. Anthropic suggests separate keys for development, testing and production, so a leak means disabling one use, not all of them.
• Cap the spend: a hard spend limit on each OpenAI project, a deliberate auto-reload threshold on Anthropic credits, a budget alert on every cloud account.
• Prefer restricted and short-lived credentials: Stripe restricted keys with an access policy, AWS IAM roles that issue temporary credentials instead of long-lived access keys, OpenAI service account keys with an expiration.
• Before each launch, look at what your live app serves, not only at your repository.

That last point is where repository scanners stop. They find the keys you committed; they do not show what your deployed app hands to every visitor, which is where a key in a VITE_ variable ends up. When Keybrum attacks an app, it reads the JavaScript the live site serves, looks for keys such as OpenAI, Stripe, a Supabase service role key or a private key, and, where the provider allows it, tests the key with a read-only call. For an OpenAI or Stripe key, the finding says whether the key still works, not only that it was found.