Push protection stops a push that contains a hardcoded credential before it reaches the repository, shows you why, and lets you remove the secret and retry. It prevents a leak rather than alerting afterward. There are two kinds, repository level and user level, and they behave differently.
What GitHub says it does
GitHub's documentation describes push protection as secret scanning that blocks hardcoded credentials, such as secrets or tokens, before they land. It applies to command line pushes, commits made in the GitHub UI, file uploads, REST API requests and GitHub MCP server interactions (public repositories only).
When a push is blocked, GitHub stops it and shows a message explaining the reason. You review the flagged code, remove the sensitive information and try again.
Two types
Repository push protection is enabled at the repository, organisation or enterprise level. It needs GitHub Secret Protection and stays off until someone with the right role turns it on.
User push protection is tied to your account, available only on GitHub.com, and on by default. It stops you from pushing secrets to public repositories.
So a developer pushing to a company private repository is not covered by user protection. The company must turn on repository protection. Check what your plan includes, since availability depends on your GitHub setup.
Bypasses
By default anyone with write access can bypass repository push protection by choosing a reason: it is used in tests, it is a false positive, or I will fix it later. The first two create closed alerts and the third creates an open alert. Each bypass is logged in the audit log, and owners and security managers receive an email.
Administrators can also set delegated bypass, where specific people approve bypass requests or are exempt. User bypass of your own pushes to public repositories creates no alert unless repository protection is also enabled.
What it will not catch
A scanner matches known patterns. A custom internal token, a password in a config comment or a key in a screenshot may slip through. Push protection is one layer.
A layered approach
- On the laptop. Keep secrets out of project directories. Use a secret manager or environment injection. See keeping MCP secrets out of Git.
- At push. Turn on push protection at organisation level.
- In the pipeline. Add a gate that fails on findings. The demo below shows a pull request gate.
- After a leak. Treat any pushed secret as exposed. Rotate it first, then clean history.
Click through it at your own pace, or open it full screen.
Quick check
Does user push protection cover my company's private repositories?
No. Per GitHub it stops you pushing secrets to public repositories. Private repositories need repository level protection.
Sources
Last reviewed: 19 October 2026.
