One in three pull requests on GitHub now involves an AI agent. That figure was fewer than one in 10 a year ago. If this rate continues, most code pushed to the platform within the next two years will be written by an agent. Much of it may never be read by a human.
When developers and agents move faster, security must keep pace. The goal is preventing leaks before they occur and making the response to exposures less dependent on manual human effort.
Developers are not becoming more careless; they are being outpaced. The tools that allow developers to create more software must also take on more of the work of protecting it.
This article presents nine quarters of data behind that claim. It also introduces a fine-tuned classifier built with Microsoft Applied Sciences to extend push protection to unstructured secrets. The model assesses a whole set of candidate secrets in less than two milliseconds and could more than double the number of secrets that are prevented.
Outpaced, not careless
A new secret appears in publicly visible code about once every two seconds, doubling yearly for the past three years. Public discourse is quick to jump to the idea that AI made developers careless.
Between Q2 2024 and Q2 2026, screened pushes grew 2.84 times while pushes carrying credentials grew 2.59 times. Across nine complete quarters of data, there was no statistically detectable trend regarding per-push prevalence. At the same time, data suggests that, more than ever, developers understand the risk of accidental exposures and are less willing to accept that risk. Over the same period, the share of push-path blocks overridden by developers fell linearly from 6.63% to 3.93%. These figures challenge the common claim that agents are causing developers to become more careless.
At a fixed rate, doubling activity doubles expected exposures. If each exposure requires the same human response, the workload doubles too. The mean time to manually revoke a secret hovers around 40 days; roughly one in five took more than 90 days. Software creation is accelerating while exposed credentials can remain usable for weeks or months, because human remediation cannot scale at the same pace as development.
Telling developers to be more careful cannot, on its own, solve that problem. As the amount of code grows, the system must prevent more exposures and reduce human effort required by those that remain, if software development is to remain sustainable.
Prevention scales with compute
The greatest impact has come from connecting detection to systems that can act. GitHub’s catalog covers more than 150 technical partners through the secret scanning partnership program. Through this program, the platform works with participating secret issuers to build out detectors and report public exposures so they can respond.
In Q2 2026, public scanning successfully reported an average of 26 credential matches a second, including repeat observations. Once notified, a large number of these partners immediately revoke the token: OpenAI API keys, Google Cloud account credentials, Slack webhooks, Hugging Face user tokens, SendGrid keys, etc. The owner may still need to replace the token, but revocation can happen without waiting for a developer to find and process a GitHub alert.
Push protection intervenes earlier. It stops recognizable credentials before it enters repository history, giving the developer or agent a chance to correct the change before there is an exposure to investigate. The platform works with technical partners to increase precision rates of their detectors as much as possible, until confident enough to push-protect these secrets for the developer community by default.
Thanks to the efforts of partners, in the past month, a secret was blocked by push protection at least once every second. When it comes to issuer-bound credentials, GitHub blocks more secrets than those which slip.
Remediation scales with people
When including additional secret types, push protection stops about 30% of newly detected secrets before they enter repository history. The remaining 70% are found after the credential is, unfortunately, already lost.
- Prevention scales with compute, but remediation still scales with people.
- Refusing a push costs compute; cleaning up a secret already lost to visible history costs a developer’s time and attention.
- As the amount of code grows, the system must prevent more exposures and reduce the human effort required by those that remain, or else the volume of vulnerabilities introduced will become untenable.
Telling developers to be more careful cannot solve this imbalance. Recognizing more of these secrets, earlier in development flows, is work the platform must take on.
Solving the four-body problem
Before a secret crosses the push boundary, the cost of stopping it is small, and the decision is binary: block or allow. After it crosses, the same string can authenticate to a real system, and the cost is unbounded.
In many cases, the only detection clue may be the surrounding code and world context. A provider-issued token may have a recognizable prefix. An internal database password may be completely unstructured, with no identifying pattern at all. The platform was already using context to find these secrets post-push; the problem was balancing that context-aware judgement with other factors.
This is referred to as the four-body problem for secret protection: precision, latency, throughput, and cost are coupled constraints. Prevention must be worth a developer’s time. A finding suitable for later review may not justify blocking a push. A false positive interrupts a developer and makes the next block harder to trust. A check that is too slow, expensive, or difficult to scale limits how often it can run.
Protection at the push in under 2 ms
The new ModernBERT classifier assesses candidate secrets in context, without generating code or prose. It is more precise than existing LLM-based pipelines, and it is incredibly fast, evaluating candidate batches in under two milliseconds. It is also extremely cost efficient, enough to run at scale.
