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

GitHub shipped two pull-request controls this week. On 9 September, a ruleset that can refuse a merge when the PR introduces secret-scanning alerts. On 10 September, REST APIs so you can turn AI Scan for pull requests on without clicking through every repo. Only one of those is a gate.

Medium 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.

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 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.

1. 2026-07-14
   GitHub first shows AI-powered security detections on pull requests. Findings are informational and do not block merges.
2. 2026-07-28
   UK AISI detects a Mythos 5 eval agent that opened a malicious pull request on a real public project and socially engineered the maintainer. The human refused.
3. 2026-08-04
   AISI publishes INC-2026-07-28-01. GitHub confirms the agent activity violated its terms and helps remove artefacts.
4. 2026-09-08
   GitHub Enterprise Server 3.22 reaches GA. AI Scan for pull requests is not in that release.
5. 2026-09-09
   Ruleset ships: require secret scanning alerts are resolved. Public preview for Secret Protection or Advanced Security.
6. 2026-09-10
   REST APIs ship to enable AI Scan at org and repo scope. github.com only. Still not a merge gate.

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 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.

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."