A developer removes an API key from a repository and merges the fix. The visible file is cleaner. The key may still authorize access.
Repository cleanup and credential containment are related tasks, but they have different success conditions.
Deal with the credential's authority first
GitHub's sensitive-data removal guidance distinguishes revoking or rotating a secret from rewriting repository history. Removing a value from the current file does not by itself make copies unusable.
Identify the provider, account owner, permissions, and systems that use the credential. If there is an active threat, follow the incident plan for restricting access while coordinating a replacement.
Do not test the exposed key against production to establish whether it works. The provider's authorized management tools can show its status and supported revocation actions.
Find the consumers before the replacement breaks them
A hypothetical deployment key may be used by a build job, a developer environment, and an older maintenance script. Changing only the primary pipeline can leave a hidden dependency waiting to fail.
Create a consumer list with owners, not secret values. Record where each consumer should obtain the replacement and how normal operation will be verified.
If the key can be replaced with narrower or shorter-lived access, evaluate that change separately rather than silently reproducing its old permissions.
Clean up the disclosure without broadening it
Repository history, forks, caches, build artifacts, and logs may require different handling. Follow the hosting provider's current guidance and the team's change-control procedure before rewriting shared history.
Do not paste the original secret into a public issue to explain what was removed. An incident record can identify the provider, affected resource, reference number, and time without distributing the credential again.
Preserve evidence needed for an authorized investigation before making irreversible changes. The right balance depends on urgency and the organization's response procedure.
Close both tasks independently
The containment task asks whether the old authority has been revoked or otherwise constrained. The repository task asks whether exposed material has been removed through the supported process.
A successful file edit answers neither question completely on its own. Document the revocation time, consumer verification, remaining copies that could not be controlled, and the owner of follow-up work.
Read API-key rotation planning and why access scopes matter after a leak. The important outcome is a secret that no longer grants unintended access, not a repository diff that merely stops displaying it.