Bypassed protection
Understand provider evidence, review a bypass and manage expected exceptions.
Provenance records protection bypasses on Business and Enterprise. A bypass describes how code reached a protected branch; the verdict describes whether the code that landed was verified.
What counts as a bypass
| Kind | What happened |
|---|---|
| Merged with failing checks | A pull request merged while Prodgator Policies was failing or pending. |
| Direct push | Code reached a protected branch without a pull request that explains its landing. |
| Force push | A push rewrote protected branch history. |
| Admin override | Provider evidence says a protection rule was bypassed, including other required checks or reviews. |
| Protected branch deleted | A protected branch was deleted. It has a Provenance record, audit entry and notification, but no new run because nothing landed. |
One change can have several bypass kinds. Unknown or incomplete provider answers are kept as uncertainty, rather than treated as proof of a direct push.
Provider coverage
| Provider | What Prodgator reads | Limits and permissions |
|---|---|---|
| GitHub | Push events, commit-to-pull-request links, branch rules and classic protection. The push's force flag identifies history rewrites. Rule suites can confirm an override and its actor, even when Prodgator Policies passed. | No new permission is needed. The GitHub App already has Administration: Read for rule suites. Rule suites do not cover classic branch-protection overrides; those can leave direct-push or force-push evidence without a confirmed override actor. Unavailable evidence is not confirmation. |
| GitLab | Push hooks, protected branches and commit-to-merge-request links. Ancestry identifies history rewrites. | No new permission is needed. The APIs used do not report an admin override. A permitted direct push to a protected branch is still recorded as a direct push, without provider confirmation of an override. |
| Bitbucket Cloud | , branch restrictions, commit-to-pull-request links and the push's force flag. | Repositories: Admin is needed to read restrictions. Reconnect older connections in Organization > Integrations to grant it. Pending commit indexing is unknown, not proof of no pull request. The APIs do not report who used Merge anyway past other checks. |
| Azure Repos | , blocking branch policies, pull request queries and ancestry. Pull request completion can report and its reason; a direct push past a required pull request policy provides override evidence. | No new permission is needed. Same-patch verification is unavailable, so identity needs other evidence. The Azure audit log is not read; its extra audit scope is not requested. Missing policy or ancestry facts stay unknown. |
GitLab can omit the push hook when more than three branches are pushed at once. A push that GitLab does not report can be absent from Provenance.
Prodgator fetches more commits when a provider truncates a push payload. If it cannot establish the complete change, verification can remain unknown. GitLab and Bitbucket can identify the merger of a pull request with a failing gate without confirming that person as a provider override actor.
Badges and filters
Runs, deployments and pull requests can link to the change through Bypassed protection, Unverified change, Expected bypass or Bypass reviewed badges. List badges mark the affected commits; they do not claim every later descendant bypassed protection.
On Pipelines and Failures, open Filters > Protection and choose Bypassed protection, Unverified change or Expected bypass. Select a badge to inspect the evidence in Provenance.
A deployment's own Bypassed gate result means it proceeded without deployment approval. That is a separate event from branch protection bypasses. See bypassed deployments.
Acknowledge a change
An Org admin can open the change and choose Acknowledge, select Reviewed, Reverted or Expected bypass, and add an optional note. This records who reviewed it and why, and closes its open review state. It does not erase the bypass or turn unchecked content into verified content.
The acknowledgement stays in the timeline and audit log. Members who can read the audit log can follow Audit event to Organization > Audit Log.
Expected bypasses
Org admins only can view and manage Expected bypasses in Gates > Defaults (). Use an entry for a known exception, such as a release bot on a specific repository and branch.
Each entry names a provider, actor, repository pattern and branch pattern, with an optional note. Repository and branch patterns accept and . Use the provider account name or supported stable identity, not a display name. GitHub, GitLab and Bitbucket account names match without regard to case; Azure account names match exactly. Bitbucket account UUIDs and Azure identity IDs are also supported. Repository matching ignores case; branch matching is case-sensitive.
All recorded bypass actors on a change must match expected entries for the whole change to be expected. Matching keeps the evidence and marks the bypass as expected; it does not verify the code. Keep entries narrow and remove exceptions when they are no longer needed. Removing an entry does not reopen changes already marked expected.
Automatic close on revert
Automatically close on revert is on by default in Gates > Defaults (). Any organization member on a plan with Provenance can read the switch. Release managers and Org admins, through , can change it.
On GitHub and GitLab, a later verified change can automatically close an earlier unverified change when Prodgator can prove its changed paths are restored to their earlier state on the same branch. A revert commit message alone is not proof. Missing evidence, partial reverts and deleted protected branches do not qualify. The timeline records the closing change, and the audit log records the acknowledgement; automatic close sends no new notification.
Bitbucket and Azure Repos require manual acknowledgement after a revert. Their path lists can omit mode-only changes, so automatic close is disabled for those providers. Review the provider diff, then have an Org admin acknowledge the change as Reverted.
Who is notified
Bypass notifications go to active Org admins and members granted or , including the Compliance and Security roles. They never go to the whole organization. Expected bypasses are kept in the record without a new bypass alert.