Secret-scanning merge gate: what to check before an agent-authored PR merges

A merge-stage addition to push protection

On September 9, 2026, GitHub announced a ruleset option called "Require secret scanning alerts are resolved" to block pull requests that introduce exposed secrets from merging. The current documentation still labels it public preview and subject to change. This is an older announcement, checked against the documentation on October 5, not a new release today. [1][2]

For a team accepting coding-agent pull requests, the useful decision is whether to add this merge check alongside push protection. GitHub describes it as an additional layer for cases push protection cannot catch or is not configured to catch. It applies to pull requests generally; the author being an agent does not give the rule broader secret coverage. [1][2]

What the gate actually checks

The rule can block a merge for either of two reasons: a secret scan has not completed for the pull request's head commit, or a commit in the pull request introduced an open alert matching a secret type selected in the ruleset. Both conditions must be cleared. Closing the alerts does not clear a pending head scan, and a scan of an earlier head is not the required scan of the current one. [2][5]

The announcement says provider patterns are the default; custom and generic patterns can also be selected. The exact rule documentation excludes AI-detected secrets, even though the broader secret-scanning service supports AI detection of unstructured secrets such as passwords. Do not assume that every alert the scanner can produce is a merge-blocking alert. [1][2][7]

Check the repository and the rule before relying on it

These are documentation-based checks for your repository, not results from a tested configuration:

• Confirm feature eligibility and prerequisites. The protected repository must have GitHub Secret Protection or GitHub Advanced Security enabled, plus secret scanning. Free automatic scanning of public repositories and general ruleset availability do not, by themselves, establish access to this specific preview rule. [2][4][7]
• Inspect the branch targets and enforcement status. The rule is for branch-targeted rulesets; a Disabled ruleset is not enforced. Confirm that the intended destination branch is included and the ruleset is Active. [2][4]
• Review the selected provider, custom or generic secret types against what the project uses. Do not count AI-detected secrets as covered by this merge rule. [2]
• Check who can bypass the ruleset, including relevant roles, teams and GitHub Apps. For an agent workflow, review the identity that can perform the merge rather than assuming the PR's author is the only actor that matters. GitHub's announcement explicitly qualifies developers without bypass permissions. [1][4]

A closed alert is a workflow state, not revocation

Repository push-protection bypasses illustrate the distinction. GitHub documents a closed alert for the reasons "It's used in tests" and "It's a false positive", but an open alert for "I'll fix it later". Because the merge rule checks open alerts, an already-closed alert does not satisfy that blocking condition. That is an inference from the documented conditions, not a tested bypass-and-merge result; the head scan and other rules can still block. Do not promise that the merge gate catches every bypassed push. [2][3]

When an exposed credential causes a block, GitHub says to consider committed secrets compromised and rotate the affected credential. Removing the token from code does not automatically close its alert. After fixing the exposure, close each blocking alert and wait for a completed scan of the current PR head. Closing an alert does not revoke the credential or undo its earlier exposure. Assign an owner for credential remediation as well as alert closure, so clearing the merge block does not become a substitute for fixing the leak. [5][7]

What a cleared gate still cannot tell you

A completed scan with no blocking alert is not proof that a pull request contains no secrets. GitHub documents a concrete gap: paired credentials, such as an access-key ID and its secret, do not generate an alert when the pair is split across different files. The merge rule also excludes AI-detected secrets and depends on the selected pattern categories. [2][6]

The recommendation is therefore bounded: add the merge rule where its prerequisites and selected coverage fit, retain push protection, and review bypass and dismissal responsibilities before treating a cleared gate as permission to merge. This briefing uses GitHub's own documentation, not an independent effectiveness test. It does not establish availability for your account, a minimum GitHub Enterprise Server version, or enforcement in your repository. [1][2][3][4]