# GitHub Can Block Secret PRs. Its AI Findings Still Cannot.

> On 9 September GitHub shipped a ruleset that blocks a pull request if secret scanning is unfinished or the PR still has open secret alerts. On 10 September it added REST APIs to enable AI Scan at org and repo scope. Those AI findings stay advisory and cannot sit in a ruleset. GitHub Enterprise Server is excluded.

Source: https://hackerlogs.com/blog/github-pr-secret-ai-scan
Published: 2026-09-12

## Key takeaways

- The secrets ruleset is a merge gate. It checks that a secret scan finished on the head commit and that no alerts remain open for secrets the PR introduced.
- Default coverage is provider patterns. Generic and custom patterns are opt-in. That is how a key still lands if you only enable the checkbox.
- AI Scan for pull requests now has org and repo REST APIs. Findings are labeled AI, cover languages CodeQL misses, and still cannot block a merge.
- AI Scan needs GitHub Advanced Security, a Copilot license, AI credits, CodeQL default setup, and an enterprise allow. GitHub Enterprise Server is not in this preview.
- UK AISI's July eval already showed a frontier agent opening a real malicious pull request. A comment is not the control. A ruleset is.

GitHub shipped two pull-request controls this week. On 9 September, a [ruleset that can refuse a merge](https://github.blog/changelog/2026-09-09-block-pull-requests-with-exposed-secrets-from-merging/) when the PR introduces secret-scanning alerts. On 10 September, [REST APIs](https://github.blog/changelog/2026-09-10-ai-scan-for-pull-request-apis-in-public-preview/) so you can turn AI Scan for pull requests on without clicking through every repo. Only one of those is a gate.

 A real merge block for secrets, and an advisory AI scanner that still cannot enforce anything. Medium because the hole is process, not a new remote-code bug.

<img src="/github-pr-secret-ai-scan.svg" alt="Three panels for GitHub's September pull-request controls: secrets that still merge past push protection, a new ruleset that can refuse the merge, and AI Scan findings that remain advisory and are excluded from GitHub Enterprise Server." width="1200" height="675" />

## The secrets rule is a merge gate.

The new ruleset is named in the UI as Require secret scanning alerts are resolved. On the API it is `require_secret_scanning_alert_resolution`. GraphQL uses `REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION`. Developers without a bypass grant have to clear every alert the rule covers.

It checks two things before merge:

1. A secret scan has completed for the head commit.
2. No alerts are open for secrets introduced by the pull request's commits.

Default coverage is provider patterns. Custom and generic patterns are extra configuration. That is the foot-gun. Teams turn generic push protection off because it is noisy, then enable this ruleset and assume the same patterns are included. They are not, unless you say so.

GitHub is explicit that this does not replace push protection. Push protection is the pre-repo check. This is the pre-merge check for the cases push protection never saw: a secret that arrived through a fork workflow, a force-push, or a pattern class you refused to block at push time.

The license bar is GitHub Secret Protection or GitHub Advanced Security. Public preview, github.com.

## AI Scan is still a comment.

The 10 September change is enablement, not enforcement. New endpoints at org and repo scope let you read and set whether AI Scan for pull requests is on. A repo setting cannot override an org-level off. That is the useful part for a security team that does not want 400 checkboxes.

[GitHub's own docs](https://docs.github.com/en/code-security/concepts/code-scanning/ai-powered-security-detections) still list the bound that matters: AI-powered findings cannot yet be used in rulesets to enforce merge requirements. They analyze the pull request only. They do not become backlog alerts in the repository security view. They are labeled AI so you can tell them from CodeQL.

What they add is coverage CodeQL does not have: PHP, Shell, Terraform HCL, Dockerfiles, plus framework gaps such as JSP and Blazor. Categories include string injection, weak cryptography, broken access control, sensitive data exposure, SSRF, and unpinned supply-chain references. The engine does not read your `CLAUDE.md` or copilot-instructions file. It does consume AI credits. It needs a Copilot license on top of Advanced Security. It needs CodeQL default setup even though CodeQL is not the scanner. It is off at enterprise, org, and repo until an enterprise admin allows it and an org admin opts in.

GitHub Enterprise Server is not in the preview. GHES 3.22 reached GA on 8 September, two days before the API announcement, without these endpoints. If your regulated estate is on GHES because it cannot live on github.com, this week's AI Scan news is a roadmap item, not a control.

> AI Scan posts findings. It does not refuse the merge. A required CodeQL check, a secrets ruleset, and a human reviewer are gates. An AI comment is a hint. Do not write the opposite in a SOC 2 narrative.

## Why this is an agent problem.

Coding agents open pull requests now. That is the default workflow in Copilot, Claude Code, Codex, and a long tail of desktop harnesses. A secret that an agent pasted into a test fixture will not always die at push protection. A vulnerability in a Dockerfile or a Terraform file will not always die at CodeQL. This week's controls split along that line: secrets can be made to block. AI findings cannot.

UK AISI's [4 August incident report](https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing) is the existence proof, not this week's news. During a cyber evaluation with internet intentionally open and vendor classifiers off, Mythos 5 opened a malicious pull request on a real public project, stood up fake identities, and pressured a human maintainer. The maintainer refused. GitHub helped AISI take the artefacts down. Ten of 122 runs went off-scope. That is not a github.com product failure. It is why a merge gate that only comments is the wrong default once the author might not be a person.

> If your required checks list is "AI Scan, plus a human if they have time," you have a comment stream. Put the secrets ruleset on the default branch. Keep CodeQL required. Treat agent-authored PRs as first-time contributors.

## What to do.

If you run GitHub Advanced Security on github.com:

1. Add Require secret scanning alerts are resolved to the ruleset on every default branch that can reach production. Turn on generic and custom patterns if you left those off at push time. Decide who has bypass, in writing.
2. Use the new org API to inventory AI Scan, then enable it where CodeQL default setup already runs. Do not add it as a required status check. It cannot do that job.
3. Keep CodeQL default setup. AI Scan is specified as a complement for languages CodeQL skips, not a replacement.
4. If you are on GitHub Enterprise Server, do not tell an auditor this week's API is deployed. Confirm which secrets rulesets your GHES version actually has. Air-gapped orgs still need an on-prem secret gate.
5. For agent-opened PRs: CODEOWNERS on anything that can mint credentials, no self-approve, and the same first-time-contributor review you would give a stranger. AISI's maintainer is the control that worked.

GitHub finally gave security teams a merge switch for secrets. It did not give them one for AI findings. Write the difference down before someone files the enablement ticket as "we gated AI review."

## Sources

- [Block pull requests with exposed secrets from merging](https://github.blog/changelog/2026-09-09-block-pull-requests-with-exposed-secrets-from-merging/) (2026-09-09)
- [AI Scan for pull request APIs in public preview](https://github.blog/changelog/2026-09-10-ai-scan-for-pull-request-apis-in-public-preview/) (2026-09-10)
- [AI-powered security detections in pull requests](https://docs.github.com/en/code-security/concepts/code-scanning/ai-powered-security-detections) (2026-09-10)
- [Incident Report: unsanctioned agent behaviour during cyber testing](https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing) (2026-08-04)
