API Key Committed to Git: What to Do Next
Respond to a committed API key by revoking or rotating it, checking use and cleaning history without confusing file deletion with containment.
The essentials
- Deleting the file from the latest commit does not invalidate the key or remove earlier copies.
- Revoke or rotate the exposed credential first, then investigate where it was used and coordinate any repository-history cleanup.
On this page
Deleting the file from the latest commit does not invalidate the key or remove earlier copies. Revoke or rotate the exposed credential first, then investigate where it was used and coordinate any repository-history cleanup.
Contain the credential
Identify the provider, account and permissions attached to the key. Use the provider's supported revocation or rotation process. Update legitimate applications through your secret-management workflow and verify that the old credential no longer works.
GitHub's sensitive-data removal guide puts revocation or rotation ahead of history rewriting. That sequence addresses the usable credential even when copies already exist elsewhere.
Do not paste the key into an issue, chat or screenshot while asking for help. Refer to a redacted identifier.
Check the exposure window
Record when the key entered the repository and when it was invalidated. Review the provider's usage or audit logs for unexpected activity during that period, where available.
Check CI logs, build artifacts, pull-request diffs and shared archives. A private repository limits some exposure paths but does not make a committed credential safe to retain.
If the key grants access to more secrets, review whether those credentials also need rotation based on evidence of access and your incident procedure.
Clean the repository deliberately
History rewriting changes commit identities and can disrupt collaborators. Coordinate it rather than force-pushing a cleanup over other people's work without warning.
Follow GitHub's documented procedure for the affected content and references. Deleting a branch or adding a file to .gitignore does not remove existing historical content.
Even after repository cleanup, clones and downloaded copies may remain. That is why invalidating the credential is the primary containment action.
Prevent the same path
Move the configuration to an appropriate secret store or local ignored environment file. Commit a template containing variable names and harmless placeholders, not real values.
Enable secret detection or push protection where available. Review generated configuration files before committing them, particularly when an AI coding assistant created examples using a real environment.
Keep build-time and browser-delivered configuration distinct: a value bundled into client code cannot be treated as a server secret.
Verify recovery
Run a legitimate application operation with the replacement credential. Confirm the old credential fails through the provider's safe verification method. Check that the cleaned repository still builds and collaborators know how to resynchronize.
Document the cause and prevention change without retaining the secret itself.
The AI coding tools guide discusses development workflows. This incident checklist provides a concrete review standard for generated configuration and automated commits.
Related troubleshooting
This guide draws on the linked documentation. Examples are illustrative unless explicitly identified as measured results.
Practical guides published by Lucivo, developed with AI assistance and references to official documentation. Examples are illustrative unless a guide explicitly documents a hands-on test. Check the linked sources for current product details.
Related articles
AI Streaming Arrives All at Once Behind NGINX
API Timeout: Is It Safe to Retry?
API Works in curl but Fails in the Browser
The Weekly Breakdown
High signal AI & software stories.
Direct to your inbox. No hype.
Independent analysis of AI models, developer tools, and computing architectures. Delivered every Sunday morning. 100% free.