GitHub Anthropic Key Scanning: Response Checks

The developer removes a key, pushes a clean commit and closes the task. The repository looks better, but the key may still work. That is the gap a credential response needs to close.

On 13 October 2026, GitHub expanded secret scanning with new Anthropic service and user API-key detectors, added to push protection by default. The update also added a Salesforce partner secret type and a Cloudsmith detector. For teams building AI integrations, this is a good point to check who receives an alert and who can act on the affected account.

Do that check before the next incident. A detector cannot nominate the person who owns an abandoned prototype or knows why a scheduled job still depends on its key.

Separate a blocked push from confirmed exposure

A push protection block gives the author a chance to repair the change before GitHub accepts it through that path. Ask whether the credential appeared anywhere else: another branch, a build log, a support ticket, a copied snippet or a previously accepted commit.

If it was committed, GitHub's remediation guidance says to consider it compromised. A private repository is still a distribution surface with users, integrations and clones. Do not assume a clean latest revision makes an old credential private again.

A local-only block also deserves a quick explanation. Was this a real credential, an inert example or a test fixture? Record the answer without copying the value into another issue. If it is real and its exposure history is uncertain, treat that uncertainty as part of the incident decision.

Establish the owner and remove the access

Use the issuer's account controls to identify the credential and revoke it. If service continuity requires a replacement, create it through the normal controlled process, place it in the appropriate secret store and update the known consumers promptly. Do not delay revocation of a confirmed exposed key while waiting for a convenient release window.

For a small team, the response record can be short:

Keep the investigation scoped to what the provider actually exposes. An absence of detailed per-key logs is a visibility limit, not evidence that the key was unused. Preserve available account activity and billing information before routine retention removes it.

Check the detector's actual coverage

The supported-pattern table is more useful than a general statement that “Anthropic is covered”. At the time of this update, the new service and user API-key patterns support push protection, but their table entries do not show validity checks. Do not wait for a validity badge to decide whether an exposed key needs attention.

GitHub also distinguishes user alerts from notifications sent directly to a partner provider. A provider notification is not a substitute for checking your own service state. Confirm revocation and recovery rather than assuming that a partner workflow completed everything for you.

Check the effective repository settings and entitlement. GitHub's secret scanning overview describes automatic public-repository scanning and the requirements for private organisation repositories. The existence of a supported pattern does not prove a particular private repository has the required protection enabled.

Repair the route that introduced the secret

Replace the committed value with a configuration reference and document where the legitimate secret belongs. Check example files, onboarding notes and local development instructions. If those still invite a developer to paste a credential into source code, the next leak is already being prepared.

Look at the build and support workflow too. A well-managed production secret can still appear in an exception message or a copied request. Prefer removing secret-bearing fields before logging over relying on a detector to recognise every future key format.

Use an inert fixture to exercise the team's notification and triage procedure. Do not intentionally publish a functioning API key to prove the detector works. Record which steps were rehearsed and which depend on the next real alert.

Close the incident with evidence

Verify that the replacement works through the intended service and that the old credential is revoked through the issuer's controls. Check whether other consumers were missed, and record any investigation limits. Then close the GitHub alert with a reason that reflects what was actually done.

Deleting a secret from source and closing an alert are separate actions; GitHub does not automatically close every alert because its value disappeared from the latest file. The useful completion record is that access was removed, dependent services recovered and the route that caused the leak was repaired.

For keeping the timeline and ownership clear, use the approach in our audit evidence guide. A few dated facts are more useful than a long incident report assembled from memory.

References

• GitHub Changelog: Secret scanning blocks Anthropic keys by default, adds Salesforce — 13 October 2026; checked 17 October 2026.
• GitHub Docs: Resolving alerts from secret scanning — checked 17 October 2026.
• GitHub Docs: Supported secret scanning patterns — checked 17 October 2026.
• GitHub Docs: Secret scanning — checked 17 October 2026.