GitHub has added Actions workflow logs to the places its secret scanning can check. In public preview, the service scans a completed workflow run and puts matches in the repository's existing secret-scanning alerts. The change gives maintainers another way to catch a credential that a build or test printed to a log, but it is limited by who can enable it, which workflow runs are checked and which secret patterns GitHub recognizes.
How does workflow-log scanning work?
After a workflow run completes, GitHub checks its logs for supported provider patterns. A finding appears with the repository's other secret-scanning alerts and links back to the relevant Actions log. GitHub says supported secret types can receive validity checks. Those checks are not available for every secret type, so a match should still be handled as a potential exposure and investigated using the provider and repository's normal response process.
The alert can remain available after the underlying log is deleted. GitHub's documentation also says a single alert can refer to several locations when the same value appears in multiple runs or jobs; the alert links to each workflow file and log line, without showing an inline preview of the log text. That makes the alert a pointer for investigation rather than a replacement for inspecting the run and determining which credential, if any, needs to be revoked.
Who can enable it?
The public preview is available to enterprises using GitHub Enterprise Cloud with GitHub Secret Protection or GitHub Advanced Security, including Enterprise Cloud data-residency customers. An enterprise owner enables the policy in the enterprise's Advanced Security settings. It is disabled by default, and it applies only to repositories where secret scanning is enabled under the relevant license. The announcement describes an enterprise policy, rather than a per-repository switch that any maintainer can turn on for a personal project.
GitHub already runs secret scanning automatically for public repositories, but that general availability does not mean this new workflow-log preview is enabled for every public repository. The preview's enterprise access requirement and policy controls still apply. Teams should check their enterprise eligibility and confirm the policy is enabled before relying on it as a layer in their build pipeline.
What does the preview not scan?
Only workflow runs that finish after the policy is enabled are scanned; existing logs are not backfilled. Current coverage is restricted to provider patterns. GitHub says it does not detect generic patterns, custom patterns or AI-detected secrets in workflow logs, and it excludes values that Actions has already masked. During the preview, alerts from these logs also do not send notifications. Maintainers need to visit the repository's secret-scanning alert list to review them.
Those gaps matter because workflow logs are only one place a value can leak. A custom token format, an unfamiliar credential, or a value removed by masking may not become an alert through this feature. Log scanning therefore complements repository and workflow hygiene; it does not make it safe to print credentials, store secrets in source code or skip ordinary credential rotation after a confirmed exposure.
How to protect your app when using an AI coding agent
For makers, the update is most useful as a backstop for automation that runs code and handles credentials. The practical checklist is to confirm enterprise eligibility, enable the policy, keep secrets out of console output, and check the alert page during preview. GitHub has made log scanning one more detection surface; its current limitations mean teams still need to control what their workflows print and respond quickly when a real secret is exposed.