# GitHub Secret Scanning June 2026: Push Protection Gets Wider > Source: > Published: 2026-06-18 02:11:09+00:00 GitHub updated its secret scanning system on June 17 with new partner integrations, expanded push protection defaults, and validity checks that tell you whether a leaked credential is still active. On the surface, it looks like routine maintenance. Look at the context and it is more pointed: 29 million hardcoded credentials leaked to public GitHub in 2025, AI coding tools are generating secrets-touching code faster than most teams audit it, and the gap between what GitHub protects by default and what your team actually has enabled has been wide for too long. ## New Push Protection Defaults The biggest practical change in this release is that more token types are now blocked by push protection by default. The June update adds patterns for Cloudsmith, Meraki, Elastic, Slack, Supabase, DataDog, and VolcEngine to the growing list of detectors that fire at push time, before credentials reach the remote. This matters because push protection is opt-in at the repo level but the specific patterns it covers keep expanding. If you enabled push protection months ago and have not checked back, you are now getting coverage you did not configure. That is generally good, but it also means your team may hit unexpected commit blocks, particularly if anyone has Supabase connection strings, Elastic API keys, or Slack bot tokens in config files that get accidentally staged. The Supabase and Elastic additions are the ones most likely to surface in active developer workflows. Both are staples of modern app infrastructure, and their credentials frequently appear in local config files that find their way into commits. ## Validity Checks: The Feature Most Teams Have Not Enabled Validity checks tell you whether a detected secret is still active or has already been revoked. GitHub verifies this by contacting the issuing service. The June update extends validity checks to the new partner integrations, Cloudsmith and Meraki, but the more important point is that most teams are not using validity checks at all. [GitGuardian 2026 State of Secrets Sprawl report](https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/) found that 64% of valid secrets from 2022 are still not revoked today. That is not a scanning problem, it is a triage problem. When a security team faces a backlog of 200+ secret alerts across dozens of repos, the instinct is to defer rather than work through the pile. Validity checks change the calculus: filter to active secrets, remediate those first, and deprioritize tokens that were already rotated. Validity checks are not on by default. You enable them at the repo level via Settings, Code security, Secret scanning, Validity checks. Once enabled, you can trigger on-demand checks for individual alerts, useful when auditing secrets discovered in historical commits. ## New Partners and Detectors GitHub added two new partners to its [secret scanning partner program](https://github.blog/changelog/2026-06-17-secret-scanning-updates-june-2026/): Cloudsmith and Meraki. Partner program status means that when these tokens are detected in public repositories, GitHub automatically notifies the issuer. For Cloudsmith, a private package registry used heavily in enterprise and DevOps pipelines, this closes a gap that left leaked registry credentials discoverable but unreported. The update also adds user-secret detectors for Elastic, Slack, Supabase, DataDog, and VolcEngine. User secrets generate internal alerts you manage directly. They do not trigger automatic issuer notification the way partner secrets do. GitLab token coverage was significantly expanded, which matters for teams running hybrid GitHub and GitLab setups or mid-migration between platforms. ## Why AI Coding Tools Make This More Urgent GitHub secret scanning updates have accelerated across 2026, and the reason is not hard to find. AI coding agents have made the credential leak problem structurally worse. GitGuardian documented that commits co-authored by AI tools leaked secrets at roughly double the GitHub-wide baseline. The culprit is not any one tool, it is the pace. AI agents write config-touching code faster than human review cycles can catch it. The governance checkpoints that naturally slow down human coding do not exist at agent speed. The numbers tell the story: 29 million new hardcoded secrets hit public GitHub in 2025, a 34% year-over-year increase. AI-service credential leaks specifically surged 81%. And 24,008 unique secrets were found in MCP configuration files alone, a category that barely existed two years ago. GitHub has been building a layered response. Push protection catches secrets at commit time. The [GitHub MCP Server integration](https://github.blog/changelog/2026-05-05-secret-scanning-with-github-mcp-server-is-now-generally-available/), launched in preview in March 2026 and generally available in May, scans for secrets inside AI coding agent workflows before a commit is even formed. The June update adds more patterns to the first layer and sharpens the triage tooling. It is not a single fix. It is a multi-layer problem requiring a multi-layer response. ## What to Do Now Three steps worth taking today: **Verify push protection is enabled.** Go to Settings, Code security, Secret scanning, Push protection. The new patterns are automatically included if the feature is on. Push protection is free for all repositories including public ones.**Enable validity checks.** Go to Settings, Code security, Secret scanning, Validity checks. This is not on by default. Enabling it immediately upgrades your alert triage.**Audit open secret alerts.** Go to Security, Secret scanning alerts. Once validity checks are enabled, filter by active status. If you have active Supabase, Elastic, Slack, or DataDog credentials in your backlog, those are now higher priority. For teams using AI coding agents, the [GitHub MCP Server integration](https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection) is worth adding to your workflow. It surfaces secret detection inside the agent loop before code is committed, which is the right layer to catch this class of error. GitHub push to expand push protection defaults is the right instinct. Waiting for teams to opt into security features does not scale. The question for your team is whether your current settings have kept pace with how fast the threat surface has grown.