GitHub Broadens AI Scan for Pull Requests: Audit Proxy Code Safely

GitHub announced on September 16, 2026 that AI Scan for pull requests can find security vulnerabilities in eligible repositories even when CodeQL default setup is not enabled. Previously, AI Scan for pull requests ran only where CodeQL default setup was configured.

The change does not turn scanning on automatically. Code scanning and AI Scan must still be enabled at the repository, organization or enterprise level, and the existing permission hierarchy still applies. GitHub says there is no new setup step: organizations that already enabled AI Scan can see it run more broadly across eligible repositories. The capability remains in public preview for organization-owned and personal repositories on github.com for GitHub Advanced Security customers; GitHub Enterprise Server is not included in this release.

For proxy-client, gateway and browser-automation repositories, the practical question is not whether “AI found everything.” It is whether the broader coverage reaches the intended pull requests, produces useful evidence, and fits a layered review process without exposing credentials or creating false confidence.

Inventory newly eligible repositories

Identify repositories where AI Scan was enabled but CodeQL default setup was absent. Prioritize code that handles:

• proxy URL and credential parsing;
• HTTP 407 and origin 401 separation;
• redirect and header forwarding policy;
• TLS verification, SNI and certificate options;
• retry, rotation and direct-fallback logic;
• browser context, cookie and storage isolation;
• log redaction and diagnostic export;
• gateway configuration and deployment workflows.

Record the repository owner, language, deployment target, AI Scan enablement level and existing security controls. An archived repository can still matter if it publishes a reusable package or workflow.

Use the enterprise security-enforcement audit to keep configuration ownership consistent. The proxy credential encoding guide helps locate sensitive construction paths that deserve explicit tests.

Verify enablement instead of assuming coverage

Select a non-production pull request in each repository class and confirm:

1. AI Scan is permitted by the repository, organization and enterprise hierarchy.
2. The scan actually runs on the pull request.
3. Its result is visible to the expected reviewers.
4. Required checks and merge policy treat the result as documented.
5. A disabled or ineligible repository is reported as a coverage gap, not silently counted as clean.

Capture repository alias, pull-request ID, commit hash, scan start and completion time, result category and triage owner. Do not copy source fragments containing secrets into a general analytics system.

Use controlled proxy-security fixtures

Test detection and triage with synthetic examples, never live credentials. Useful owned fixtures include:

• a proxy URL accidentally written to a log without redaction;
• origin authorization forwarded to an unapproved redirect host;
• TLS certificate verification disabled on one branch;
• a retry path that falls back to a direct connection;
• a cookie jar reused across unrelated trust domains;
• a command invocation that exposes a synthetic password in process arguments.

The objective is to prove workflow behavior, not to assume the scanner will detect every implementation of every flaw. Keep fixtures private, clearly marked and non-deployable. Remove or neutralize them after the test.

Separate AI Scan from deterministic controls

AI-assisted findings should complement, not replace:

• compiler and type checks;
• unit and integration tests;
• dependency and secret scanning;
• CodeQL or other static analysis where configured;
• branch protection and required review;
• runtime redaction and egress controls;
• explicit proxy acceptance tests.

A clean AI Scan result is not proof that credentials are safe, certificate checks are enabled or traffic cannot bypass the proxy. Some properties require a controlled runtime test. Use the proxy bypass audit for fail-closed routing and the HTTPS proxy TLS audit for certificate and tunnel boundaries.

Build a finding-triage contract

Define who reviews findings, the response deadline, severity criteria, dismissal reasons and escalation route. The repository owner should not dismiss an alert merely because a test passes; determine whether the alert describes a reachable path, a defense-in-depth gap or a false positive.

For every finding, record:

repository_alias
commit_hash
finding_category
affected_component
review_owner
decision
evidence_reference
fix_commit
retest_status

Never paste raw proxy passwords, session cookies, private keys or customer data into the record. Use redacted code references and access-controlled evidence.

Roll out with measurable gates

Start with a small set of representative repositories. Establish a baseline for scan completion, time to result, useful-finding rate, false-positive rate and median time to triage. Expand only after owners can handle the alert volume.

Suggested gates include:

• every targeted pull request shows an attributable scan outcome;
• no repository is counted as covered when it is disabled or ineligible;
• critical findings block merge under the documented policy;
• synthetic fixtures produce the expected review workflow;
• ordinary proxy builds and tests continue to complete;
• dismissals include evidence and an accountable reviewer;
• repaired findings are rescanned before release.

Because the feature is in public preview, keep a rollback plan and monitor behavior changes. Do not weaken deterministic checks to compensate for preview instability.

Audit checklist

• Eligible proxy-related repositories are inventoried.
• Enablement is verified at repository, organization and enterprise levels.
• Pull-request scan execution is confirmed, not inferred.
• Synthetic fixtures contain no real credentials.
• Findings have owners and response objectives.
• Secret, dependency and deterministic code scanning remain active.
• Runtime proxy bypass and TLS controls are tested separately.
• Coverage gaps are visible and cannot appear as clean results.
• Dismissals require evidence and review.
• Fixed code is rescanned before release.
• Public-preview limitations and GitHub Enterprise Server exclusion are documented.

FAQ

Does AI Scan now work without enabling code scanning?

No. GitHub states that code scanning and AI Scan must still be enabled at the appropriate repository, organization or enterprise level.

Is CodeQL default setup no longer useful?

The update removes it as a prerequisite for AI Scan on eligible pull requests. It does not say that CodeQL or deterministic analysis should be removed.

Is the feature available on GitHub Enterprise Server?

Not for this release. GitHub describes the public preview as available on github.com for eligible organization-owned and personal repositories with GitHub Advanced Security.

Can a clean scan replace a proxy acceptance test?

No. Route behavior, direct fallback, regional selection, authentication and TLS outcomes need controlled runtime evidence.

Compliance note

Scan only repositories and pull requests you are authorized to access. Protect source code, credentials, personal data and vulnerability details according to organizational policy. Do not use findings or proxy infrastructure to exploit third-party systems, bypass access controls or conceal unauthorized activity.