One in three pull requests on GitHub involves an AI agent. A year ago it was fewer than one in ten. At this pace, most code pushed to GitHub could be agent-written within two years. Much of it may never be fully read by a human.

GitHub's purpose-built secret detection model, released October 7, accepts that premise. Faster code creation demands equally fast protection. Detection moves from matching token-shaped strings to reading code context and finding passwords.

The problem: outpaced, not careless

Start by clearing a common misconception. "AI made developers careless" reads differently in GitHub's nine quarters of data.

Public-push wire:
- New secrets surface in visible code about every two seconds
- Doubling yearly for three years

But per-push carelessness did not rise:
- Screened pushes 2.84x vs credential-carrying pushes 2.59x (Q2 2024 → Q2 2026)
- Per-push prevalence trend: no statistically detectable change
- Push-protection overrides forced through by devs: 6.63% → 3.93% (linear fall)

Developers did not get sloppier. Volume outran people. Flat rate times double the volume means double the exposures, with manual response unchanged. Mean time to manually revoke a secret sits near 40 days, and one in five takes over 90. Exposed credentials pile up usable for weeks.

GitHub's existing work matters here. With 150+ technology partners it builds detectors jointly and reports public exposures so issuers like OpenAI, Google Cloud, Slack, Hugging Face, and SendGrid can revoke immediately. In Q2 2026 it reported 26 matches a second on average. Push protection stopped recognizable credentials before history, blocking at least one a second last month. Still, only about 30% of newly detected secrets get stopped pre-history. The other 70% are found after the credential is already lost. Prevention scales with compute. Cleanup still scales with people.

The new model: read context, judge in under 2 ms

Built with Microsoft Applied Sciences, the fine-tuned classifier judges whether a value is secret from surrounding code. It generates neither code nor prose.

Input: a value inside a DB URL, a Kubernetes Secret manifest, a Dockerfile
Judgment: placeholders like changeme pass, real-looking passwords block
Speed: candidate batches assessed in under 2 ms (push critical-path grade)
Cost: far cheaper than LLM pipelines → runnable at scale
Expectation: more than double the preventable secrets

GitHub calls this the "four-body problem." Precision, latency, throughput, and cost are coupled constraints. Blocking a push is binary: one false positive erodes trust in the next block. Too slow or too pricey and it cannot run often. A 2 ms classifier is the claimed key.

It lands in three places:

1. Scan alerts (live now): AI-detection customers auto-upgraded to the new model
   → Included with GHSP/GHAS, no extra charge
   → GHES 3.23 public preview brings it to Server (incl. air-gapped)

2. Push protection (private preview): checks unstructured credentials at push time
   → Needs Enterprise Cloud/Teams + purchased GHSP/GHAS, admin-enabled
   → Checks consume credits even without a block; org-billed (EMU exception)

3. Copilot /security-review (private preview soon): checks before commit/push/PR review
   → Usable without GHSP; AI Credits billed to the Copilot account
   → Off by default, opt-in required. Agents must not enable it alone.

Billing and access: read before enabling

GitHub deliberately pre-announced the pricing. New opt-in checks consume GitHub AI Credits.

Included (no extra charge): AI-detected scan alerts, old and new model
Credit-consuming (coming weeks): AI push-protection checks, security-review secret checks
SKU: Secret Protection AI Credits (see AI usage insights)

Budgets: Billing and licensing → Budgets and alerts
  → SKU-level budget → Advanced Security → Secret Protection AI Credits
Catch: alerts alone never stop usage
  → Enable "Stop usage when budget limit is reached" for a real cap

Already in the push-protection private preview? Continued use after billing starts consumes credits. Disable it first if you do not want that. Org and enterprise admins can switch the capabilities off by policy. Eligibility, pricing, and budgets first, enablement second.

CodeBridge Mini Lab: put secret checks into PR validation

Gating AI-written code before merge is today's work.

1. Enable push protection (where your plan qualifies):
   - Decide the level: repo, org, or enterprise
   - Require bypass reasons; confirm bypass alerts land in the Security tab

2. Run /security-review (Copilot CLI/App):
   - Review active changes before push, fix confirmed items with proper auth
   - Remember it is read-only; re-run after fixes

3. Record two numbers separately:
   - False positives: blocked but not secret (developer-trust metric)
   - Real saves: genuine exposures stopped (security-effect metric)

Never blend the two. Rising false positives train developers to bypass habitually, and that opens the next leak. Attach this gate to the Copilot flow from the vibe-coding post and AI coding and secret checks become one pipeline.

Conclusion: match creation speed with protection speed

One line to summarize.

Tools that let people create more software must take on more of protecting it.

Context-aware detection running at push time in 2 ms moves protection from human attention to platform compute. But the new checks cost credits and start off. Check eligibility, budgets, and policy first, then enable, and track false positives apart from real saves. That is the realistic order for keeping secrets in the AI-coding era.

Further reading

References

Go deeper with a course

If you want to implement and test real projects in Agent and Plan modes and attach security gates, the beyond-autocomplete Copilot path connects directly to this post's PR-validation story.