GitHub’s software-production data describes a scaling mismatch. One in three pull requests now involves an AI agent, compared with fewer than one in ten a year earlier. Public pushes increased from 202 million in the second quarter of 2024 to 574 million in the same quarter of 2026. Even if the chance of a secret appearing in each push remains stable, a much larger number of pushes creates a much larger response burden.[1]
That distinction matters. The headline problem is not evidence that developers suddenly became reckless. GitHub says it found no statistically detectable trend in per-push secret prevalence across nine quarters, while the share of push-protection blocks overridden by developers fell. The system is producing more code than manual security work can comfortably absorb.[1]
The scale mismatch
| Measure | Value | Context |
|---|---|---|
| Pull requests involving an AI agent | One in three | GitHub’s current reported share; fewer than one in ten a year earlier.Source 1 |
| Public pushes | 202M to 574M | A 2.84-fold increase from Q2 2024 to Q2 2026.Source 1 |
| Push blocks overridden | 6.63% to 3.93% | A 2.70 percentage-point fall over the measured period.Source 1 |
| Mean manual revocation time | About 40 days | Roughly one in five exposed secrets took more than 90 days.Source 1 |
| New classifier latency | Under two milliseconds | GitHub says it can assess candidate batches in the push path.Source 1 |
Volume can rise without prevalence rising
The increase from 202 million to 574 million pushes is approximately 184%. If the per-push exposure rate were unchanged, expected exposures would rise by the same proportion. This is why a prevalence chart can look stable while security teams feel overwhelmed: the denominator has expanded.
The same reasoning applies beyond secrets. More generated code can mean more dependencies, configuration changes and pull requests to review. A per-change error rate does not need to worsen for the absolute number of problems to rise sharply. Security capacity must be planned against software throughput, not only defect rates.
Prevent before exposure or remediate after exposure
| Stage | What the system can do | Human work that remains |
|---|---|---|
| Inside the coding agent | Scan pending changes before commit or pull request | Interpret findings and remove or replace the valueSource 2 |
| At push | Block a high-confidence credential from entering repository history | Approve a valid bypass or correct the pushSource 1 |
| After push | Detect and notify the issuer or repository owner | Revoke, rotate, assess access and clean historySource 1 |
| After use | Investigate what the credential accessed | Incident response, recovery and disclosureSource 1 |
The classifier is useful because it is narrow
GitHub’s new model is not a general coding assistant. It classifies candidate secrets using surrounding code context and is designed to run in less than two milliseconds. That narrow function matters because a push-path control must balance precision, latency, throughput and cost. A chat model that gives a thoughtful answer after several seconds is not automatically suitable for blocking millions of code changes.[1]
GitHub says adding the classifier could more than double the number of secrets it prevents. That is a vendor projection, not a guarantee for every repository. The operational test should track false blocks, bypasses, credentials prevented, credentials found later and how quickly exposed values are revoked. The October 7 announcement places its use in push protection in private preview, with broader availability planned later that month; the post-push detection rollout is separate.
Security must move closer to generation
The GitHub MCP Server can let an AI coding agent invoke secret scanning before commit or pull request, using the same customisation and bypass behaviour already configured for the repository or organisation. That moves a check into the agent’s working loop rather than waiting for a later scan.[2]
The more autonomous the coding workflow becomes, the more important this placement is. A person may never read every generated line before it reaches a branch. Controls that inspect the actual change, stop high-confidence problems and return structured locations to the agent can scale with the code-production system. Human reviewers then concentrate on judgement, exceptions and remediation rather than trying to inspect everything manually.
The right objective is not to slow AI coding until people can review every token. It is to make protection scale with creation: deterministic checks where possible, fast narrow models in the critical path, clear bypass accountability and automated revocation links. Otherwise, software output grows at machine speed while the most expensive part of security still waits in a human queue.
Sources & further reading
- Secret protection must scale with software The GitHub Blog · 7 Oct 2026 · Accessed 9 Oct 2026
- Secret scanning with GitHub MCP Server is now generally available GitHub Changelog · 5 May 2026 · Accessed 9 Oct 2026
- GitHub Code Quality is now generally available GitHub Changelog · 20 Jul 2026 · Accessed 9 Oct 2026