GitHub said on November 9, 2026 that secret scanning can now look inside GitHub Actions workflow logs, adding them to the places it already watches, such as code, issues, wikis, discussions and pull requests. The feature is in public preview for enterprises on GitHub Enterprise Cloud.
Build logs are an easy place for credentials to slip out. A debug print, a verbose tool or a failed command can write a token into a log that many people can read. Scanning those logs closes a gap that teams have often had to cover with their own scripts or manual reviews.
What Changed
Once a workflow run finishes, GitHub checks its logs against the patterns of supported secret providers. Any match shows up in the repository's normal secret scanning alert list, next to findings from code and other content.
Each alert links back to the workflow log where the secret was found. Validity checks run for secret types that support them, so you can see whether a leaked token still works. Alerts also stay in place after the logs themselves are deleted, which keeps the record for follow-up work.
Who Can Use It
The preview is limited to enterprises on GitHub Enterprise Cloud that hold GitHub Secret Protection or GitHub Advanced Security licenses. Enterprises using data residency on GHE.com are included.
The setting is off by default. An enterprise owner turns it on in the enterprise settings under Policies and then Advanced Security, by choosing Enabled for all repositories. It then applies only to repositories that already have secret scanning switched on under those licenses.
Preview Limits to Know
GitHub lists several gaps in this first version. Plan around them before you rely on the feature:
- Only runs that finish after the feature is enabled are scanned; older logs are not checked.
- Generic patterns, custom patterns and AI-detected secrets are not covered yet.
- Values that Actions already masks in the log are not reported.
- Alerts from workflow logs do not send notifications during the preview, so someone has to review the alert list directly.
The missing notifications are the most important point for day-to-day use. If nobody opens the alert list, a leaked key can sit there unnoticed, so add a regular review to your security routine.
What It Means for Developers
Secrets in logs usually come from habits rather than attacks. Common causes include echoing environment variables while debugging, running tools in verbose mode, or passing a token on a command line that gets printed. This feature will catch some of those mistakes, but it is a safety net, not a fix.
Keep using Actions secrets and masking for every sensitive value, and avoid printing configuration in build steps. Since custom patterns are not scanned in the preview, internal tokens with your own formats still need other controls. Prefer short-lived credentials such as OpenID Connect tokens to cloud providers, so a leaked value expires quickly.
This change fits a wider push by GitHub to harden Actions. Recent examples include workflow lockfiles reaching general availability and the plan to block pull_request_target by default on December 2. Together they push teams toward safer pipeline defaults.
How to Turn It On
If your enterprise qualifies, ask an enterprise owner to enable the Actions workflow log policy under Advanced Security. Confirm that secret scanning is active on the repositories you care about, because the policy does nothing where it is off.
After enabling it, trigger a few normal workflow runs and check the alert list to see how findings appear. When a real secret turns up, revoke and rotate it first, then remove the log and fix the step that printed it.
Conclusion
Scanning Actions workflow logs gives GitHub Enterprise Cloud customers a new way to spot credentials that leak during builds. The preview has clear limits, including no backfill and no notifications, so teams should pair it with careful log hygiene and regular alert reviews.
Sources
See my articles more often when you search Google.
