Question 1

Won't approvers just click "approve" without reading?

Accepted Answer

Some will, and a control that assumes otherwise is already broken. Warning fatigue is well documented: Sunshine et al. (USENIX Security 2009) and Akhawe and Felt (USENIX Security 2013) both showed that people click through security prompts they see too often. Permission Protocol is built around that finding. Policy clears the routine, so a signer only ever sees the consequential, which keeps the prompt count low. Every approval binds a named signer to the exact payload digest, so a careless approval is still an attributable decision with a name on it, not an anonymous click. The control does not make people careful. It makes every approval attributable.

Question 2

We already built approval gates in-house. Why add this?

Accepted Answer

Keep them. An in-house gate proves a gate ran. What it usually cannot produce is a portable, signed record that an auditor can verify without trusting the system that produced it, years later, after the engineers who built the gate have moved on. Permission Protocol issues that record: a receipt binding the signer of record, the exact payload digest, the policy that applied, and the timestamp, signed by an issuer key and verifiable outside our platform. If your gate already produces that, you do not need us. If it produces a log line, we are the difference between a log and evidence.

Question 3

How does a receipt map to SOX ITGC and SOC 2 CC8.1?

Accepted Answer

Both frameworks ask the same question about change management: was this change authorized by the right person before it took effect, and can you prove it? A receipt carries what that evidence request expects: the signer of record, the exact commit or payload digest, the policy that applied, the time of the decision, and an issuer signature showing none of it changed afterward. It is designed to be handed to an auditor as change-authorization evidence and verified independently of Permission Protocol. We do not certify your controls; your auditor does. We give them an artifact that verifies.

Question 4

Isn't this just maker-checker?

Accepted Answer

Yes, and we say so. Four-eyes approval is decades old. PSD2 dynamic linking binds an authorization to the exact amount and payee. Supply-chain attestation formats like in-toto already sign statements about what was built, by whom. Permission Protocol applies those ideas to agent actions: a named human signs the exact action an agent wants to take, policy clears the routine, and every decision leaves a portable receipt. The novelty is where the control sits and what the artifact proves, not the cryptography.

Question 5

What happens if Permission Protocol is unavailable?

Accepted Answer

Gated paths fail closed. On GitHub, the required check cannot report success without a receipt, so a protected PR stays blocked until we are back; nothing merges unsigned. MCP Guard runs in your environment with no dependency on our hosted service, so an outage on our side changes nothing there: routine calls pass under your local policy and consequential calls hold for your signer exactly as they always do. Current status is on the page linked in the footer.

Question 6

Does this replace branch protection or code review?

Accepted Answer

No. Branch protection is the enforcement rail and reviews prove a human looked at the code; keep both. Permission Protocol adds a required check inside that rail and records what GitHub's native data cannot: which agent authored the change, in which run, a signer of record for the production action itself, and a signed receipt binding signer, commit, policy, and timestamp. The receipt is yours and verifies outside any one platform. Your approvals stay. They become evidence.

Question 7

What exactly gets blocked?

Accepted Answer

On GitHub, the required status check stays failed when a PR touches configured production paths and no matching human-signed receipt exists; everything else passes under policy. On MCP, calls your policy marks consequential hold for a human in the local approval UI; calls marked reversible hold for a countdown you set and release if no one objects; routine calls pass.

Question 8

Can an agent bypass it?

Accepted Answer

Receipts from our hosted service are signed by an issuer key the agent never holds. An admin with sufficient privileges can remove the gate. Permission Protocol cannot stop that, and does not pretend to. It records that the gate changed, when, and by whom. Removing the gate is itself a recorded change in GitHub's audit log, with who and when, and a change that merged without a receipt has no receipt to show an auditor. Bypassing the control becomes a recorded decision instead of a quiet one.

Question 9

Do I need to use AI coding agents for this to be useful?

Accepted Answer

No. It protects any high-risk PR or deploy flow. It matters most where coding agents can author or modify production changes, because that is where "who signed for it" has no native answer.

Your agents are shipping. Who signed for it?

The question no one can answer today

Cleared or signed, every action leaves a receipt.

One gate, wherever the agent acts.

MCP tool call

Merge

Deploy

Two doors in. One receipt layer.

MCP Guard

Deploy Gate

No signature. No production SQL.

Common questions

Won't approvers just click "approve" without reading?

We already built approval gates in-house. Why add this?

How does a receipt map to SOX ITGC and SOC 2 CC8.1?

Isn't this just maker-checker?

What happens if Permission Protocol is unavailable?

Does this replace branch protection or code review?

What exactly gets blocked?

Can an agent bypass it?

Do I need to use AI coding agents for this to be useful?

When the regulator asks who authorized the action, can the firm answer?

Explicit approval

Tamper-evident receipts

Calibrated by risk tier

Start free, or start a pilot.

Free for developers

Design-partner pilot from $50K