This matters because logs are where debugging habits and third-party tools often meet credentials. A shell trace, verbose package manager, failed deployment command, or action output can expose a token without changing the repository contents. GitHub Actions already masks many secrets, but masking is not a guarantee and only covers values GitHub recognizes in the current job.
What the preview scans
Who can enable it
The important limitations
Treat this as an extra detection layer, not as permission to print sensitive values. During the preview, workflow log scanning detects provider patterns only. It does not detect generic patterns, custom patterns, AI-detected secrets, or values that GitHub Actions masked in the log. Alerts from workflow logs also do not send notifications during the preview, so someone needs to check the repository's secret scanning alert list.
Fix the source of the leak
If an alert points to a real credential, rotate or revoke it first. Removing a line from the workflow or deleting the log does not make an exposed token safe. Then fix the workflow so the same output cannot happen again.
Start with the step named in the alert. Look for shell tracing, debug flags, verbose client output, error handlers that dump environment values, and scripts that echo request headers or full URLs. Pass only the inputs a command needs, keep token permissions narrow, and prefer short-lived credentials such as OIDC when the provider supports them.
A practical rollout plan
Enable the policy for a small group of repositories first, then review the alerts after new runs complete. Add a lightweight security check to your CI review checklist: can this step print a secret, does the action need this permission, and is the credential still long-lived? Once the workflow is clean, expand the policy and keep alert review assigned to a real team rather than assuming notifications will arrive.