Permission Protocol
No agent-written code ships without a signature.
Block PRs from coding agents until a human signs the exact change.
Built for AI coding agents like Cursor, Claude Code, Codex, and other tools opening PRs against real repos.
GitHub required check
permission-protocol/approval pending
Display name: Permission Protocol
PR #184 modifies migrations/20260505_drop_users_email.sql
Agent-written SQL change. Human signature required before merge.
Human-signed receipt required
repo: acme/billing-api
approved_sha: 9f2c1a7
sql_hash: sha256:d46a7403...
signature: ed25519:8f2s...
After approval + CI greenauto-merge ready
First protected repo
Built for the first repo where agents touch production.
Start where the approval path is concrete: one repo, one protected branch, one risky production path, and one required check that cannot turn green without a receipt.
Agent-authored deploy workflow change
Agent-authored Terraform change
Agent-authored release branch merge
Install flow
From install to signed PR control.
01
Install the Permission Protocol GitHub App.
02
Select one repo to protect first.
03
Open a test PR or use an AI-authored PR.
04
Let the Permission Protocol required check block the risky change.
05
Have a human signer approve the exact action.
06
Inspect the signed approval receipt.
07
Let GitHub auto-merge after CI/CD and Permission Protocol are green.
What you'll see
A blocked PR, a signing step, and signed proof.
GitHub check pending
The Permission Protocol check stays pending or blocked when the permission-protocol/approval context needs approval.
PR comment with approval link
Reviewers get a clear comment that explains why the PR is blocked and where to approve.
Approval screen
A human reviews the repo, PR, commit, requested action, target, and policy before signing.
Receipt proof page
The approval creates a receipt showing who authorized what and when.
GitHub auto-merges
After approval, the Permission Protocol check turns green for that PR context. GitHub native auto-merge can ship once all required CI/CD checks are green.
Branch protection vs approval receipts
How is this different from GitHub branch protection?
GitHub branch protection is the lock. Permission Protocol is the signer and receipt layer. Branch protection can require reviews and status checks before merge. Permission Protocol uses those enforcement rails to require explicit human authorization for high-risk or AI-authored changes, then records who approved the action, what was approved, why approval was required, and the receipt that unlocked the check.
We are not replacing branch protection or GitHub auto-merge. We make branch protection carry an agent-specific authorization decision before GitHub is allowed to merge.
GitHub branch protection
Requires reviews and status checks before merge.
Permission Protocol
Uses required checks to enforce human-signed approval for high-risk or AI-authored changes.
GitHub branch protection
Controls whether a protected branch can accept a merge.
Permission Protocol
Records the specific action/request, signer, policy decision, and approval receipt.
GitHub branch protection
Depends on correct branch protection and bypass settings.
Permission Protocol
Adds the agent-action authorization layer on top of the enforcement rail.
Try safely first
Start with a demo repo or non-production repo.
Install GitHub App on one low-risk repo first. Open a test PR, verify that the check blocks, sign the approval, and inspect the receipt before enabling required checks on production branches.
Requirements
What enforcement depends on.
- A GitHub repo you can install the app on.
- Permission to install GitHub Apps for the org or account.
- Branch protection and required checks for enforcement.
- Repo settings that do not let the wrong people bypass required checks.
Trust boundary
What this does not do.
Permission Protocol is a GitHub approval and receipt workflow. It works best when teams configure branch protection and required checks correctly.
Production environments fail closed. No silent fail-open, ever.
It does not replace GitHub branch protection.
It does not prevent admins from bypassing protections if repo settings allow bypass.
It does not magically classify every possible production risk perfectly.
It provides approval workflow, required-check gating, and approval receipts.
FAQ
How this differs from branch protection.
Is this just GitHub branch protection?
No. GitHub branch protection enforces reviews and required checks. Permission Protocol uses required checks as the enforcement mechanism, but adds an authorization workflow and signed approval receipt for specific AI-authored or high-risk actions. Teams still need to configure branch protection correctly, and admins may be able to bypass depending on repo settings.
Is this just another approval button?
No. The value is approval tied to a specific action/request, signer identity, policy decision, and receipt outside the normal PR review thread.
Does this replace GitHub branch protection?
No. GitHub branch protection is the enforcement rail. Permission Protocol uses required checks inside that rail, so branch protection still needs to be configured correctly.
Can admins bypass it?
Admins may bypass depending on repo settings. Teams should configure GitHub branch protection, required checks, and bypass permissions to match their enforcement goals.
No receipt = no merge
Protect one GitHub repo before the next AI-authored production PR.
Start with one repo, one test PR, and one required GitHub check.