Permission Protocol vs GitHub Branch Protection Rules

Keep your approvals. We make them evidence.

If your main branch does not have branch protection enabled, close this page and fix that first. Branch protection is one of the most valuable controls available to an engineering team, it is free, and it lives in the workflow your reviewers already use. We do not ask you to remove it, weaken it, or route around it. Permission Protocol runs alongside it and turns the approvals it already collects into signed, portable evidence.

What branch protection gets right

Required pull request reviews, required status checks, stale review dismissal, signed commits, restricted pushes, linear history: together these define what code can reach a protected branch, and they are enforced by the platform itself. That enforcement rail is exactly where a gate belongs.

For human-scale change volume, where reviewers know the author and consider each diff, this model works. The gaps appear when the author is an agent and the volume is not human-scale anymore.

The three gaps natives cannot close

1. Provenance: native approvals do not know agents exist

A required review records that a human clicked approve on a diff. It carries nothing about which agent authored the change, under which session, or which human principal delegated the task. The question "list every AI-originated production change last quarter and show the accountable human for each" is unanswerable from native review data. The fields were never captured.

Permission Protocol binds the acting agent and session, the named signer, the policy, and the exact commit into one signed record, so accountability is written down at approval time, not reconstructed in an incident review.

2. Volume: reviewer models assume human-scale change

Required-reviewer rules assume a human reads each change. Agents multiply change volume beyond human review capacity, and a blanket review requirement collapses into rubber-stamping or gets removed as friction. Either way the control stops controlling.

The stable model is risk-tiered policy. Routine changes clear automatically under policy and still mint a policy-signed receipt. Consequential changes hold for a named human. The gate never becomes the bottleneck, and it survives.

3. Evidence: platform logs live on the platform's terms

Review approvals live in GitHub's database: siloed in one tool, retained on the platform's schedule, not cryptographically bound to the exact payload that shipped, and not portable across GitHub, GitLab, and agent runtimes. They are records you can look at, not artifacts you can hand to an auditor.

A Permission Protocol receipt is the customer's artifact: Ed25519-signed, scoped to the exact commit SHA and environment, recording signer, policy, and timestamp, verifiable offline with the public key years later.

Side by side

Works together, not instead

Permission Protocol is a required status check inside branch protection, not a replacement for it. Branch protection stays the lock. The reviews and checks you already require become inputs, and each approval is converted into a signed receipt recording who authorized what, under which policy, for which exact change. Your reviewers keep their workflow. Your compliance owner gets an artifact that does not depend on any platform's retention policy.

The install is additive: nothing about your existing branch protection configuration changes.

Also see: Permission Protocol vs GitHub Environment Approvals, the same three gaps at the deployment layer.