How to rotate a leaked API key

To rotate a leaked API key, revoke the exposed key first so it stops working, then issue a new one, update every consumer that used it, audit provider logs for abuse during the exposure window, and scrub the value from git history. A key that has touched git history is compromised forever, so rotation is mandatory, not optional, no matter how long ago it leaked or whether you have seen any abuse yet.

TL;DR:

• Revoke first, issue second. The leaked key must be dead before you do anything else; a new key alongside a still-valid old key fixes nothing.
• A key in git history is compromised forever. History is permanent and copyable across clones, forks, and caches, so assume the value is in hostile hands.
• Work in order: revoke, issue, update consumers, audit for abuse, scrub history.
• If the key reached GitHub, follow the leak runbook in committed a secret to GitHub and gate future commits with a secret scanner.

Why is rotation mandatory and not optional?

Once a key is exposed, the only thing that contains it is killing the key. Automated scrapers watch public GitHub events and grab fresh credentials within seconds of a push, so the value can be in use before you notice. Making the repo private, deleting the commit, or force-pushing a rewritten history all leave the real credential live. The leaked string is no longer a secret; only a freshly issued key is.

This is why git history matters so much. A history rewrite is hygiene, not containment: the original value still lives in every existing clone, in collaborators’ machines, in pull-request views, in CI build logs, and in the provider-side caches that survive a force-push. You cannot prove who copied it, so you must assume someone did. That assumption is the whole reason rotation is non-negotiable. This guide is part of our DevSecOps guides for AI workloads hub.

What is the general key rotation procedure?

Follow these steps in order. Do not start with the history rewrite.

1. Identify the key and its scope. Note which provider issued it, what it unlocks, and every place it is configured. This decides how urgently and widely you must act.
2. Revoke or deactivate the leaked key at the provider. This is the containment step. The exposed key must stop authenticating before you continue. If your provider allows two active keys, you can issue the replacement first and overlap to avoid downtime, but the old key still must be revoked in this step.
3. Issue a new key. Generate a replacement, scoped as narrowly as the workload allows. Copy it once into your secret manager; never paste it back into source.
4. Update every consumer. Roll the new value into deployment environments, CI/CD secrets, serverless config, and local .env files for each service that used the old key. Redeploy so nothing still references the dead credential.
5. Audit usage for abuse. Inspect the provider’s usage, billing, and audit logs for the window between the leak and the revocation. Unfamiliar IPs, regions, spend, or models mean the leak was exploited; treat that as a separate incident.
6. Scrub the value from git history. Remove it from working files into an environment variable first, then purge it from history with git filter-repo or the BFG Repo-Cleaner per the GitHub guidance on removing sensitive data, and force-push.
7. Verify. Re-scan the repository and history with a scanner, and confirm only the new key authenticates.

Where do I revoke and rotate each provider’s key?

The table below points to each provider’s own documentation for revoking and reissuing a credential. Per each provider’s documentation, follow the documented path in their console rather than any third-party UI walkthrough, because the interface changes often.

Provider	Where to revoke and rotate	Notes
OpenAI	API keys page in the platform dashboard (platform.openai.com/api-keys)	Revoke the leaked key, then create a new secret key. Keys are shown once at creation, so store the new value immediately. Scope to a project where possible.
Anthropic	Claude Console, per Anthropic API documentation	Manage keys in the Console: disable or delete the exposed key, then generate a replacement. Workspace-scoped keys limit the blast radius.
AWS	IAM access keys, per AWS IAM access keys documentation	Deactivate then delete the leaked access key; create a new pair. A user can hold two keys, enabling overlap during rotation. Audit usage with CloudTrail. Prefer IAM roles over long-lived keys.
GitHub	Personal access tokens settings, per GitHub token documentation	Delete the exposed token and create a new one. Prefer fine-grained tokens with a short expiry and least-privilege scopes over classic tokens.
Stripe	API keys in the Developers dashboard, per Stripe API keys documentation	Use Rotate key: it revokes the old secret key and issues a replacement, with an optional expiry window so you can migrate consumers before the old key dies.

How does overlapping keys avoid downtime?

Some providers let two keys be active at once. AWS allows two access keys per user, and Stripe’s rotate flow can keep the old key alive on a short expiry. Issue the new key, deploy it everywhere, confirm traffic flows on the new value, then revoke the old one. This gives zero-downtime rotation. Where only one key can exist, accept a brief outage during the swap; a few seconds of downtime beats a live leaked credential.

What if the key was used by AI agents or automations?

Trace every automation that held the key: scheduled jobs, webhooks, agent tool configs, and third-party integrations. Each is a consumer that breaks the moment you revoke, so update them in step 4. Scoping agent credentials tightly in the first place, as covered in least privilege for AI agents, keeps this list short and the damage small.

How do I make sure the leaked key never works again?

Confirm three things: the old key is dead, the new key is everywhere, and the value is gone from history. Try an API call with the old key and expect an authentication failure. Re-scan the repository and its full history with a tool such as gitleaks and confirm zero findings. Then watch the provider’s usage dashboard for a few days for any attempt to use the revoked value, which would signal an attacker still trying.

How do I stop the next leak?

Shift detection left so a key is blocked before it ever reaches a remote. Add a scanner as a pre-commit hook and a required CI check so a flagged credential fails locally and never merges. For how those tools differ, see gitleaks vs TruffleHog. Pair scanning with short-lived, least-privilege credentials so that even a leaked token expires quickly and unlocks little. Return to the DevSecOps guides hub for the full set of related controls, and browse the tools directory for scanners that fit your stack.