GitHub Actions Secret Scanning for Test Logs

TL;DR GitHub's public preview scans eligible GitHub Enterprise Cloud repositories' Actions workflow logs for certain exposed credentials after a run completes. It is off by default, does not backfill earlier completed logs, and does not send notifications for these alerts during the preview. It is not a blanket check of Playwright traces, screenshots, or browser recordings. Keep sensitive data out of test output, assign someone to check alerts, and handle each evidence type separately.

A browser test fails in continuous integration (CI). The team opens the job log, downloads a trace, and sends a screenshot to an engineer. Those artifacts can make the failure easier to understand, but they also need different rules for access and retention. A control that checks one surface should not be mistaken for a review of all three.

On November 9, 2026, GitHub announced a public preview of secret scanning for Actions workflow logs. For QA teams, the useful question is not simply whether to switch it on. It is what the preview covers, who checks its findings, and what still needs a separate decision before a test artifact is shared.

This is source-backed analysis, not an executed experiment.

What the Preview Actually Checks

When an eligible workflow run completes, GitHub scans its logs for supported provider secret patterns. Findings appear in the repository's secret scanning alerts, with a link to the workflow log. GitHub says validity checks run for supported secret types and that alerts remain available even after logs are deleted.

The preview announcement sets out important limits:

• Availability: The preview is for enterprises on GitHub Enterprise Cloud with GitHub Secret Protection or GitHub Advanced Security, including eligible enterprises using GHE.com data residency.

• Setup: An enterprise owner opens enterprise settings, selects Policies and Advanced Security, and chooses Enabled in the All repositories dropdown. The policy is disabled by default and applies only to repositories with secret scanning enabled under the relevant licenses.

• Timing: Only runs completed after enablement are scanned. Existing logs are not backfilled.

• Coverage: The preview scans for provider patterns, not generic or custom patterns, AI-detected secrets, or values already masked by Actions.

• Alerts: During the preview, alerts for secrets in workflow logs do not generate notifications. Someone needs to check the repository's secret scanning alert list.

A finding is a signal to investigate, not proof that every secret in the run was detected. An empty alert list is not proof that the logs or other test artifacts are safe.

Log Scanning Is Not the Same as Masking

GitHub Actions automatically redacts GitHub secrets printed to workflow logs and certain other recognized sensitive information. GitHub also warns that redaction is not guaranteed because secret values can be transformed, and that the runner can only redact secrets used within the current job.

The new preview adds a separate, after-the-run detection step for the provider patterns within its scope. It does not make it safe to print credentials deliberately. Design test output so that secrets are not written in the first place, use GitHub's masking mechanisms where appropriate, and check the results under your team's security policy.

GitHub recommends deleting the affected log and rotating a secret if an unredacted secret reaches a workflow log. Follow your incident process for the order and evidence handling; do not paste the exposed value into a ticket or chat while asking for help.

Separate the Evidence Before You Share It

Playwright warns that traces and console logs can contain sensitive information, including test credentials and staging access tokens. GitHub describes the new preview as scanning workflow logs, not as scanning every attachment produced by a test run. Treat the following as separate surfaces:

These are handling recommendations, not claims that an artifact has been inspected or is automatically redacted. Your organization may require additional controls.

A Worked Example for a Failed Browser Test

Imagine an illustrative test that signs into a staging app with an approved synthetic account, changes a setting, and fails while checking the result. The CI run produces a workflow log, a Playwright trace, and a screenshot. No real test was run for this article.

1. Check the log separately. If your enterprise enabled the preview and the repository is eligible, check the repository's secret scanning alerts. A missing alert does not clear the other artifacts or unsupported secret types.

2. Review the trace and image. Consider the account data, URLs, request information, and visible page content they may contain. Review each artifact before sending it outside its intended audience.

3. Give the receiver only what they need. Describe the expected and observed result, the relevant test run, and the next question. Link to approved evidence instead of copying raw output into a broad channel. Preserve the first failure and its permitted evidence rather than relying only on a later retry.

4. If a credential is exposed, stop and escalate. Follow the security owner's procedure to revoke or rotate it and remove affected logs as appropriate. Correct the source of the output before rerunning a workflow that could print it again.

The goal is not to discard useful debugging evidence. It is to preserve enough context for the investigation without treating every artifact as equally safe to distribute.

A Small Ownership Card

In the team's test workflow or incident checklist, record the workflow and repository, the preview eligibility and policy owner, who checks the alert list, and how often. Name the access and retention owners for logs and for traces or reports, and the person who reviews screenshots or recordings. Record the approved synthetic account or dataset, the security escalation route for exposed credentials, and the approved destination for incident evidence.

Do not put credentials or sensitive customer content on the card. If a field is unknown, assign an owner to resolve it rather than treating the artifact as approved.

Prepare for More Automated Test Evidence

As teams use more automated browser runs, more debugging evidence may move between people and tools. Name the owner, access boundary, and retention decision for each evidence surface before a run fails.

If a solving agent is asked to investigate, it needs the ordered actions, expected and actual result, and the specific evidence it is permitted to inspect. Give it only approved, reviewed artifacts and keep the first failure linked to the run. An agent's answer is not a verified fix; a person or independent check must verify the outcome.

The preview is useful for a specific class of log exposure. It is not a replacement for deciding what a test should emit, who can read its artifacts, or how to respond when a credential escapes.

Capture a Deliberate Browser Path

For the hypothetical browser bug, use CSS Selector & XPath Finder by Samelogic to deliberately start a Bug Replay on an approved synthetic path. The extension's listing describes recording browser steps and screenshots; review the capture before sharing it so a receiving teammate can inspect the relevant path. This is a separate artifact from an Actions log. The recording does not prove that the CI evidence is safe or that the failure has been fixed. Explore CSS Selector & XPath Finder.