API Key Rotation Best Practices: How to Rotate and Verify Key Cleanup

Why Is API Key Rotation Critical After a Leak?

API key rotation after a leak is critical because exposed credentials remain exploitable indefinitely until revoked. Git commit history preserves leaked keys even after they are deleted from the current codebase. Automated bots scrape public repositories for credential patterns and exploit discovered keys within minutes for cryptocurrency mining, data exfiltration, and unauthorized service access.

A key committed to git exists in the repository's history permanently. Running git rm or deleting the file removes the key from the working tree but not from prior commits. Anyone with repository access can retrieve the key using git log -p. Public repositories expose this history to every user on the internet.

The window between exposure and exploitation is measured in minutes. AWS keys published to GitHub have been used to spin up cryptocurrency mining instances within 15 minutes. OpenAI keys are exploited for inference cost abuse, generating bills that exceed thousands of dollars. GitHub tokens grant access to private repositories, organization settings, and CI/CD workflows.

Rotation is the only effective response. Preventing API key leaks reduces the frequency of required rotations, but every team needs a practiced rotation procedure for the cases where prevention fails.

How Often Should You Rotate API Keys?

API keys should be rotated immediately after any suspected compromise, when team members with key access leave the organization, and on a regular schedule of 90 days for production keys. Keys committed to version control — even to a private repository for a few minutes — should be rotated immediately because git history preserves the exposure permanently.

Scheduled rotation limits the window of exposure for keys that may have been compromised without detection. A 90-day rotation cycle means that even an undetected leak has a bounded exploitation window. Shorter cycles (30 days) are appropriate for high-value keys that access financial data or production databases.

Event-driven rotation triggers include: a key appearing in scanner results, a team member departure, a security audit finding, a CI/CD log exposing credentials, or a third-party breach notification. Vibe Owl detects keys in code through five pattern detectors: OpenAI keys at 95% confidence, AWS keys at 90%, GitHub tokens at 95%, private key blocks at 100%, and generic secret assignments at 70%.

What Are the Steps to Rotate an OpenAI API Key?

Rotating an OpenAI API key requires logging into the OpenAI dashboard, revoking the compromised key, generating a new key, updating the .env file and any deployment configurations with the new value, redeploying affected services, and verifying the old key returns authentication errors. Vibe Owl provides this procedure as a built-in playbook.

The Vibe Owl: Open Key Rotation Playbooks command displays three provider-specific guides accessible directly in VS Code. The OpenAI playbook covers the dashboard navigation path, the key generation process, and the specific files that typically reference OpenAI keys in common frameworks.

The Vibe Owl: Update Rotation Checklist command tracks completed steps within the playbook. Each rotation step can be marked as done, providing a verifiable audit trail that the rotation was completed thoroughly rather than partially.

How Do You Rotate GitHub Tokens and AWS Access Keys?

GitHub token rotation requires revoking the exposed token in Developer Settings, generating a new fine-grained personal access token with minimum required permissions, and updating CI/CD secrets and local configurations. AWS access key rotation requires creating a new key in IAM, updating all referencing services, deactivating the old key, and monitoring CloudTrail for failed authentication.

GitHub tokens cover five formats: ghp_ (personal access), gho_ (OAuth), ghu_ (user-to-server), ghs_ (server-to-server), and ghr_ (refresh). Each format requires a different revocation path. Fine-grained tokens with repository-scoped permissions limit blast radius compared to classic tokens with broad organization access.

AWS key rotation follows a two-key strategy: create the new key first, update all systems, verify the new key works, then deactivate and delete the old key. The deactivation step (before deletion) provides a safety window to reactivate if a system was missed during the update. CloudTrail logs reveal any unauthorized usage during the exposure window.

How Do You Verify a Leaked Key Has Been Fully Removed?

Verifying complete key removal requires scanning the current codebase, git commit history, staged changes, and environment files. The Vibe Owl: Run Post-Rotation Rescan command chains workspace scanning, git history scanning across the last 80 commits, and staged diff preview to confirm the old key no longer appears anywhere in the repository.

Git history scanning is the critical step most developers skip. Scanning git history for leaked secrets searches the last N commits (default 80, configurable up to 500) using git log -p. The scanner parses diff hunks to extract the exact file and line number for each finding, deduplicates across commits, and caches results.

The post-rotation rescan chains three operations: workspace scan (current files), git history scan (prior commits), and staged diff preview (pending changes). All three must return clean results to confirm the old key is fully removed. A finding in git history means the key is still accessible to anyone who clones the repository.

Environment file auditing complements the rescan. The env file safety system checks that the new key is properly defined in .env, documented in .env.example with a redacted placeholder, and that no hardcoded references remain in source files.

How Do You Build a Sustainable Key Rotation Workflow?

A sustainable key rotation workflow combines automated detection through live scanning and git hooks, guided rotation through step-by-step playbooks, tracked progress through rotation checklists, and verified cleanup through post-rotation rescans. The complete workflow runs inside VS Code without requiring external dashboards or manual checklist documents.

The detection layer catches keys before they persist. Live scanning flags keys on file open and save. Git hooks block commits containing detected credentials. The preflight check consolidates all findings before push. These three layers reduce the frequency of required rotations by preventing most leaks entirely.

When rotation is needed, the playbook provides the procedure. The checklist tracks completion. The post-rotation rescan verifies cleanup. The 10 Commandments for Vibe Coders establish the principle: never hardcode secrets, always rotate immediately on detection, and verify removal across the full repository history.