Rotating a leaked key

Rotation is boring until it is urgent. A token in a public gist, a CI log, a screenshot, or an AI chat transcript is already a credential leak — even if nobody has abused it yet. The goal is to cut off the old secret quickly, verify nothing still depends on it, and update your local vault without spreading the new key the same way.

1. Contain and classify

Note where the leak happened (repo commit, paste service, ticket, local file). If the material is public or synced to a cloud index, assume the secret is known. Revoke or rotate at the provider before cleaning up git history — history rewriting does not invalidate a key that was already scraped.

2. Issue a replacement at the provider

In your provider dashboard, create a new API key or rotate the existing credential according to their workflow. Where the product supports dual-active keys briefly, use that window; otherwise accept a short outage for the affected service. Apply least privilege: if the leaked key had write access you no longer need, tighten scopes on the replacement.

3. Revoke the old key

Delete or disable the compromised token immediately after the replacement works in a smoke test. Providers often show last-used timestamps — check whether the old key saw traffic after the leak time.

4. Update local storage safely

Avoid echoing the new secret in your shell history. With Latchkey, add or overwrite using an env var on the same line:

LATCHKEY_VALUE=sk-new... npx latchkey add OPENAI_API_KEY
npx latchkey list

Remove the old value from any plaintext .env files, docker compose overrides, CI variables, and password managers that still reference the leaked token. If the leak was in git, rotate first, then remove the secret from tracked files and add patterns to your scanner — see .env file risks.

5. Trace dependents

• CI jobs and deployment platforms using the old variable name.
• Teammates' laptops (communicate the rotation; do not Slack the new key).
• Long-running agents or daemons started before rotation — restart them.
• MCP servers or scripts that cached env at startup.

6. Review access logs

Check provider usage for anomalies around the leak window: new IP addresses, spike in spend, or unfamiliar models. If your org requires it, file an internal incident note with timeline and actions — you do not need to publish details publicly.

7. Prevent the same leak

Move runtime injection to a vault (latchkey run), keep repos free of secrets, enable pre-commit or offline scans where appropriate, and treat model chats as untrusted storage. Optional one-time leak scan checkout on the site runs locally and does not upload your repository contents to us.

Security reports for Latchkey itself: Yusuf@yusuf-choudhury.com (no real keys in email, please).