Push protection stops hardcoded secrets at the moment of the push, but by default anyone with write access can bypass it by giving a reason. Decide who may bypass, route requests to a reviewer with delegated bypass, and review the "I'll fix it later" cases, because those leave an open alert.
What it does
GitHub's documentation describes push protection as a preventive secret scanning feature. When it detects a potential secret it blocks the push and explains why, so the developer can remove it and try again.
It covers command line pushes, commits made in the GitHub UI, file uploads and REST API requests. Interactions with the GitHub MCP server are covered for public repositories only.
Two kinds
- For repositories: set at the repository, organization or enterprise level. It requires GitHub Secret Protection and is disabled by default.
- For users: tied to a personal account on GitHub.com, on by default, and stops you pushing secrets to public repositories.
User level bypasses do not create alerts unless repository level push protection is also on. So for any team that needs a record, turn on the repository level.
The default bypass
Anyone with write access can bypass by choosing a reason. The documentation lists three, and what each does to the alert:
- It's used in tests: the alert is closed as used in tests.
- It's a false positive: the alert is closed as a false positive.
- I'll fix it later: the alert stays open.
The third one is the honest one. Track it. The first two are self reported, so a real secret can be closed with a convenient label.
Delegated bypass
Administrators can grant two things:
- Bypass privileges: which let someone approve other contributors' bypass requests.
- Exemptions: which let trusted actors push without triggering the check.
A good setup is to send bypass requests to the security team or a small group of senior engineers. Exemptions should be rare, and reviewed like any other standing access.
A policy you can write down
- Enable repository level push protection for all repositories.
- Turn on delegated bypass, with a named reviewer group.
- Define what counts as a test credential. Example: it is a documented dummy value in a test directory.
- Review open alerts from "I'll fix it later" weekly.
- If a real secret was ever pushed, rotate it. Blocking later does not help once it is in history.
That last point is important. Push protection prevents new leaks. It does not clean history, as covered in push protection does not clean your git history. For depth, see the push protection deep dive.
Measure it
Count bypasses per month and the share of each reason. A rising "false positive" share suggests a noisy pattern to tune. A rising "I'll fix it later" count suggests a backlog or a habit problem.
The free Safeguard scan at gold.safeguard.sh/scan can complement this by checking your dependencies.
Quick check
Is push protection on by default for repositories?
No. Repository level push protection is disabled by default and needs GitHub Secret Protection.
Who can bypass it?
By default anyone with write access. Delegated bypass lets administrators change that.
Sources
Last reviewed: 19 October 2026.
