How do I rotate a leaked API key in five minutes?

August 26, 2026 · The Squiid team · 5 min read

Short answer: create a new key, deploy it everywhere the old one lives, then revoke the old one, in that order. Creating before revoking is what makes rotation a five minute job with no downtime instead of an outage. Deleting first and then discovering three deployments you forgot is how a five minute job becomes an hour.

Assume the key is compromised the moment it touches anything you do not control: a chat window, a screenshot, a public repository, a pasted log, a third party tool you connected once. Do not spend time deciding whether the exposure was serious. Rotation is cheap and certainty is not.

The procedure

1. Create the replacement. In the provider console, issue a new key with the narrowest scope the code actually needs. Do not reuse the old name so you can tell them apart in logs.
2. Update every location. Local env file, hosting environment variables for production and preview, CI or GitHub Actions secrets, any background worker or container, your password manager entry. Write the list down as you go; you will need it again.
3. Redeploy and verify. Trigger a deploy so running processes pick up the new value, then make one real request and confirm it succeeds. Environment variables do not change under a running process.
4. Revoke the old key. Only now. Watch for errors for a few minutes; anything that breaks is a location you missed, and you have just found it the easy way.
5. Check the usage log. Most providers show recent requests with timestamps and often IP addresses. Look for calls you cannot account for before the revocation.

Do them in blast radius order

If several keys were exposed at once, the sequence matters because you have limited attention in the first ten minutes.

• Anything that spends money. Model APIs, messaging, cloud accounts. This is the one that turns into a four figure number while you think about it.
• Anything that can act as you. Email and SMS keys let a stranger send from your domain or your number, which costs reputation as well as money.
• Anything that reads user data. A database service role key that bypasses row level security is every record you hold, and this one carries breach notification obligations in many jurisdictions.
• Everything else. Analytics, maps and search keys are mostly a quota problem.

Everywhere the old key is hiding

The reason rotation takes longer than it should is that nobody has a complete list. A realistic one:

• Local .env files, on every machine you have used, including the laptop you stopped using.
• Hosting environment variables, separately for production, preview and any other environment.
• CI secrets, and any deploy or migration workflow that carries its own copy.
• Background workers, cron runners and containers that were configured by hand.
• Your shell history and your password manager.
• Any MCP server, editor extension or third party integration you authorised.
• Git history, if it was ever committed. Revoking is the only real fix; rewriting history does not help once a repository has been cloned or mirrored.

Keep this list in RUNBOOK.md in the repository, updated whenever a service is added. It is the difference between five minutes and an afternoon.

Service specific traps

Database service role keys. Some platforms tie them to the project rather than making them individually revocable, so rotation means regenerating a project level secret that also invalidates other tokens. Check before you click, and expect to redeploy everything that connects.

Webhook signing secrets. These are keys too, and they usually live only in the receiving application. Rotating one without updating the receiver silently drops every incoming event, which fails quietly.

OAuth tokens and app credentials. Rotating a client secret can force every connected user to reauthorise. Plan the message you will send before you click.

Keys embedded in a mobile or desktop build. These cannot be rotated without shipping a release, which is the reason a secret should never be in a client binary in the first place.

A worked example

You pasted a stack trace into a chat to ask why a request was failing, and the trace included the Authorization header. It is a model provider key, so it spends money, which puts it first in the order above.

Minute one: open the provider console, create a new key, name it with today's date. Minute two: paste it into the hosting environment variables for production and preview, and into the CI secret. Minute three: update the local env file and the password manager entry. Minute four: trigger a redeploy and hit one endpoint that uses the key, confirming a real success rather than assuming. Minute five: revoke the old key, then sit and watch the error rate for two minutes.

If something breaks in that last two minutes, good. That is a copy of the key you did not know about, and you have found it with a clear error message and a fix you already have in your clipboard. Add the location to the runbook. Then open the usage log and scan the hours between the paste and the revocation for requests that were not yours. If you find any, you now have a cost question and possibly a disclosure question, and you should treat both as urgent rather than embarrassing.

After the rotation

Do three things while it is fresh. Note in the runbook where the key was found, so the same leak path gets closed. Add a secret scanner to your repository if you do not have one, since most Git hosts offer push protection that catches the obvious cases for free. And if the exposure involved user data, check whether you have a notification obligation, because that question has a deadline attached.

How to never need this

Rotation is a procedure for a bad shape: long-lived, broadly scoped credentials copied into many places. Three changes make the procedure rare.

Fewer keys. Every credential you do not hold is one you cannot leak. Narrower scope. A key that can only send email from one domain is a much smaller event than one that can also read your contacts. Shorter life. A credential that expires on its own has a bounded window even when you never notice the exposure.

This is the shape Squiid aims at. Squiid holds the upstream provider credentials and your project carries a single SQUIID_API_KEY, so the Supabase, Resend and Twilio secrets never exist on your machine at all. Rotation becomes one click in one dashboard, it does not touch the providers, and you do not visit six consoles or hunt for eight copies. Because usage runs against a prepaid balance, the worst case for a leaked Squiid key is bounded by the credits you funded rather than by your card limit, and the gateway log shows exactly which calls the leaked key made before you revoked it.