Author: Nadali. Prepared with AI assistance.
What GitHub announced
On November 9, 2026, GitHub opened public preview of secret scanning in Actions workflow logs. Secrets include keys and other credentials that can appear in an automated process’s output. For a business with a custom website or integrations, the practical question is simple: who will see a detected leak?
According to GitHub’s documentation, these findings do not generate notifications during preview. Someone needs to review the repository’s secret scanning alerts. Receiving no email does not establish that there is no problem.
Who can access it
The announcement limits preview access to GitHub Enterprise Cloud enterprises with GitHub Secret Protection or GitHub Advanced Security, including those with data residency on GHE.com. The feature is off by default; an enterprise owner enables it, and scanning covers only repositories with secret scanning enabled under the relevant licences.
This is not an availability announcement for all Free or Team accounts. If a contractor handles development, ask who owns the repository and whether its environment meets the conditions. Buying a broader plan solely because of this announcement would require a separate assessment of needs and costs.
What the scan leaves out
The documentation specifies that logs are scanned for workflow runs that complete after the feature is enabled; earlier logs are not backfilled. Only provider patterns are supported. This mode does not detect generic patterns, custom patterns, AI-detected secrets or values already masked by Actions.
The wider capabilities of secret scanning should therefore not automatically be attributed to log scanning. An empty findings list is not a complete security audit.
What to agree with the technical owner
Nadali’s suggested review process:
- Select one important workflow, such as deploying the website or synchronising a catalogue. Record its name, repository and owner without including actual credentials.
- Check eligibility and whether the feature is enabled. Having a licence alone does not establish that logs are being scanned.
- Agree who reviews findings after completed runs and when. Name a backup owner so the check does not depend on one person.
- Separate old logs from new ones. The technical specialist needs a separate plan for older logs rather than marking them as checked after enabling preview.
- For a confirmed leak, agree on prompt rotation or revocation of the compromised credential and checks of dependent services. GitHub recommends updating services that used the old token and checking security logs. An authorised administrator should carry out these actions.
Illustrative example: a contractor enables scanning, but nobody reads the results because the team expects emails. The useful outcome for the business owner is a named reviewer and a record of the check, rather than just an enabled setting. This is an editorial illustration, not an incident we discovered.
Do not send actual secrets in emails, tasks or AI chats. Nadali read the sources on November 11, 2026, but did not test preview access in an account or inspect readers’ systems. Preview conditions may change.
Cover: an original conceptual AI illustration for this article, not a GitHub interface or evidence of a detected leak.
