Signal / 009 — GitHub maps the repositories its AI scanner can see

SYSVOID SIGNAL // 07 OCTOBER 2026

Security controls fail quietly when nobody can tell where they are switched on. GitHub’s latest security-overview update aims at that exact blind spot: administrators can now see which repositories have AI Scan for pull requests enabled—and which ones do not.

A coverage map for AI scanning

In its October 6 announcement, GitHub says organization and enterprise administrators can view enabled and not-enabled repository counts in the security overview. Individual repository rows show the effective setting, while new filters let teams isolate either state. Coverage CSV exports also gain a dedicated AI Scan column.

This is management visibility, not evidence that a repository is clean. It answers a narrower—but useful—question: is the pull-request scanner actually deployed everywhere the security policy expects it to be?

More secrets enter the net

A separate October 5 update adds detection for Lovable API keys, Pydantic Logfire tokens, Pydantic AI Gateway keys, and two Supabase token types. GitHub distinguishes partner secrets—which may be reported to the issuing provider when exposed in a public repository—from user secrets that generate alerts in public or private repositories.

The edge-case verdict

Opinion: the dashboard change is less dramatic than a new scanner, but it solves the rollout problem. A security feature enabled on 97 percent of repositories still leaves an interesting three percent for an attacker. Exportable coverage makes that gap measurable; the added detectors make the net a little wider.

Teams should treat the new view as an inventory check, then keep ordinary review, testing, least-privilege credentials, and fast rotation in the loop. Automation can spot exposed edges. It cannot decide how much trust the system deserved in the first place.

AI-assisted summary, reviewed against GitHub’s linked primary announcements. Escape the default. Built for the edge cases.