An exposed token needs more than repository cleanup

Removing a token from a page does not withdraw the authority it grants. Once a reusable credential has been exposed, cleanup and revocation are separate tasks. The person who discovers it may be able to trigger containment, while the credential owner remains responsible for investigating use and restoring legitimate access.

Looking back from November 2026, GitHub's 29 April 2025 announcement made its exposed personal access token revocation API generally available. It allowed reporting of exposed classic and fine-grained PATs, including tokens belonging to someone else. Valid submitted tokens were automatically revoked, with owner notification and an audit event. This was a containment mechanism, not merely a request to remove a secret from a repository.

GitHub had separately announced an organization secret risk assessment on 1 April. Discovery and response belong together, but they are different stages. Finding an exposed credential does not demonstrate that its access has ended or that nobody used it before discovery.

The reporter has a narrower job

A person who finds a credential should avoid testing it against real resources to establish what it can do. That would create another use of the secret and could alter evidence. The useful report identifies where and when the exposure was observed, with enough context for the owner to investigate without spreading the token further.

Preserve evidence in a restricted incident record. A public issue containing the full value would reproduce the exposure. Screenshots, logs and copied messages can also become additional secret stores. Record the discovery context and protect any necessary original evidence according to the incident process, rather than treating every collaboration tool as an appropriate destination.

The reporter cannot replace the owner's investigation. They may not know which jobs rely on the token, what access it had or which logs are available. Keep that uncertainty explicit. Containment should not turn into an unsupported declaration that the credential was unused or that the associated account is otherwise safe.

The current REST reference describes the reporting endpoint and says revoked credentials cannot be reactivated. It is mutable documentation consulted in November 2026; its current list of credential types should not be read back into the PAT scope of the April announcement. This article describes responsibilities, not an instruction to operate the endpoint or submit any real credential.

The owner must reconnect access to purpose

After revocation, the owner needs to establish which legitimate tasks depended on the credential. An illustrative deployment job may fail because its previous token can no longer authenticate. That failure is operationally important, but it does not mean the old credential should have remained usable after confirmed exposure.

Replacement should start with the task, rather than automatically copying the old permissions. Identify which repository or service needs access and whether the task requires reading, writing or publishing. Issue an appropriate replacement through the organization's normal process, distribute it through the intended secret store and remove stale references to the old value.

Then verify the legitimate operation through its ordinary path. A new secret saved in settings is not evidence that the job can use it successfully. Equally, a successful job does not prove that every old copy has disappeared. The response needs both restored operation and a continuing search for the original exposure path.

Review the available activity around the exposure window. Revocation stops future acceptance of that credential; it does not undo changes already made using it. If evidence suggests unauthorized modifications, those require their own investigation and recovery. Avoid claiming that token replacement alone restores the integrity of repositories, releases or other affected resources.

Availability is a real counterargument

The strongest objection is that aggressive revocation can interrupt important work. A token may support a release, an integration or an operational task whose owner is not immediately available. Interrupting it can have business consequences, especially when a team has not documented its credentials.

That concern should shape incident preparation and restoration, rather than become a reason to preserve an exposed credential indefinitely. Keep an owner map, a replacement procedure and a way to prioritize affected services. Where the exposure is uncertain, use the incident process to assess the evidence promptly. Do not confuse an unverified suspicion with an established compromise.

Preserving evidence also matters. Deleting the public occurrence may be necessary to limit further distribution, but erasing the only record of its location and timing can make the investigation harder. Capture the needed context securely while containment proceeds. The sequence should fit the incident's urgency; evidence handling must not become a blanket delay on withdrawing confirmed exposed access.

The right response balances prompt containment with accountable recovery. It does not promise uninterrupted service during an incident. It gives the owner a concrete way to explain what stopped, what was replaced, what remains uncertain and which operations have been restored.

Close the exposure path as well as the token

For custom software development, include credential ownership and replacement in the handover. A secret should have a purpose and a responsible person before an incident reveals its undocumented dependencies. Keep reporting, containment and restoration distinct enough that each can be verified.

This problem is separate from choosing browser sessions or JWTs, and from an incident involving copied session cookies. Here the credential is an exposed GitHub PAT, with a provider-managed revocation path. Repository cleanup reduces distribution; revocation withdraws authority; investigation and replacement address what happened and what legitimate work must continue.