Permission Protocol vs GitHub Environment Approvals

Keep your approvals. We make them evidence.

This page is not a pitch to rip out GitHub environment approvals. They are good, they are free, and they live exactly where your team already works. If you have them configured, keep them. Permission Protocol runs alongside them and converts the approvals you already collect into signed, portable evidence.

What environment approvals get right

Environment approvals are a native feature of GitHub Actions. No third-party tools, no extra accounts. Create an environment, add required reviewers, and GitHub pauses the workflow job until a designated reviewer approves from the UI or the mobile app. Deployment history and reviewer decisions sit next to your code, with no context switching and no learning curve.

For a human-scale pipeline, where a developer opens a PR, a teammate reviews it, and a person decides when to ship, this is often exactly the right amount of control. We will say it plainly: we do not ask you to remove it, and Permission Protocol does not replace it.

The three gaps natives cannot close

1. Provenance: native approvals do not know agents exist

An environment approval records that a human clicked approve. It carries nothing about which agent acted, under which session, or which human principal delegated the work. When the question arrives, "list every AI-originated production change last quarter and show the accountable human for each", native approval data cannot answer it. The fields do not exist.

Permission Protocol records the acting agent and session, the named human signer, the policy, and the exact payload in one signed record, so provenance is part of the approval instead of a forensic reconstruction after the fact.

2. Volume: reviewer models assume human-scale change

Required reviewers work when a team ships a handful of changes a day. Agents multiply change volume beyond human review capacity. At that rate, a blanket approval requirement collapses into one of two failure modes: rubber-stamping, where approval means someone cleared a queue, or gate removal, where the friction wins and the control quietly disappears.

The stable model is risk-tiered policy. Routine changes auto-approve under policy and still mint a policy-signed receipt. Consequential changes escalate to a named human. The gate survives agent-scale volume because it only spends human attention where attention matters.

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

The native approval trail lives in the platform's database: siloed per tool, retained on the platform's schedule, not cryptographically bound to the action payload, and not portable across GitHub, GitLab, and agent runtimes. Proving an approval later means live API access, retention windows that cooperate, and an auditor willing to trust the pipeline that produced the export.

A Permission Protocol receipt is the customer's artifact. It is an Ed25519-signed document scoped to the exact commit, environment, signer, policy, and timestamp, verifiable offline with the public key, independent of any platform's retention policy.

Side by side

Works together, not instead

Permission Protocol runs alongside branch protection and environment approvals. The Deploy Gate is a required status check inside GitHub's own enforcement rail, and the approvals your reviewers already grant become inputs: each decision is converted into a signed receipt recording who approved what, under which policy, for which exact change. Reviewers keep working in GitHub. Compliance gets an artifact it can verify without GitHub.

Nothing about your existing configuration has to change. Keep the approvals. Add the evidence layer.

Also see: Permission Protocol vs Branch Protection Rules, the same three gaps at the merge layer.