Deleting an exposed API key does not revoke its access

Someone spots a credential in a source file. The line is deleted, a clean commit is pushed, and the team marks the problem fixed.

The file changed. The credential may still grant access.

Removing an exposed copy and invalidating its access are separate jobs. A useful incident record should make both visible.

Detection is getting more capable

In an October 7 post on secret protection, GitHub describes expanding detection for less structured secrets as software production accelerates. The important operating point does not depend on a particular scanner’s performance: an alert begins a response; it does not establish that access has been removed.

GitHub’s repository-cleanup guidance says exposed credentials should be revoked or rotated as a first step. Its remediation guidance also distinguishes remediation from simply removing the secret from code.

A source-code cleanup cannot substitute for the provider-side access change.

Identify what the credential can do

Consider a hypothetical integration that creates tasks in a team’s project system. A token appears in a copied setup example.

The response needs an authorized technical owner who can identify the issuing service, permissions, affected applications, and available access history. Refer to the credential by an identifier or safe label in the incident record. Do not spread the token itself through screenshots, chat, or support notes.

Follow the provider’s revocation or rotation procedure promptly. Do not leave an exposed credential active while polishing a repository cleanup. Coordinate dependent application updates with the responsible operator, and make any interruption visible.

The order and mechanics depend on the provider and incident. A confirmed active compromise may require immediate containment that interrupts the integration. A replacement plan should not become an excuse to keep compromised access available.

Keep separate evidence for access and operation

There are two different finish lines:

Finish line	Evidence to seek
Exposed access is invalidated	Provider-side revocation or replacement status, plus an appropriate authorized verification
The legitimate workflow is restored	The application uses the approved replacement and completes a bounded test

Use a safe, limited test appropriate to the service. Never exercise an exposed credential against data or systems outside your authority. A provider’s administrative record may be the right evidence for revocation; the new integration needs its own functional verification.

Clean up without losing the incident

Inspect where the exposed value traveled: the working file, repository history, build output, logs, documentation, or other copies within the response’s authorized scope. Avoid reproducing the value while searching or reporting.

GitHub warns that rewriting repository history has side effects and cannot remove copies from other people’s clones. Treat history removal as a coordinated technical decision, not an automatic next command. Revocation and the investigation remain important even if a displayed copy disappears.

Review the provider’s available access records for the relevant exposure period. Absence of suspicious activity in a limited log is not proof that no access occurred. Record the coverage and what remains unknown.

Rehearse the response with a test credential

Do not deliberately publish a real production credential to test your process. Use a controlled test environment and a disposable credential under the provider’s rules, or a tabletop exercise with no live secret at all.

Ask who receives the alert, who can invalidate access, how the dependent workflow is identified, and what evidence closes the incident. If everyone knows how to delete a line but nobody can name the service owner, you have found the first repair.

For the broader recovery question, read Can you restore the system you just decided to own?. Here, restored operation must come with demonstrated removal of the exposed access.

Source and scope

GitHub secret-protection update, October 7, 2026; repository cleanup and leaked-secret remediation, checked October 16. This is a general operating overview. Follow the issuing provider’s procedure and the responsible security team’s incident plan for a real exposure. No actual Xovion credential incident is described.