Review the controls behind the evidence.

What your integration sends us: The Deploy Gate action sends repository name, pull request number, commit SHAs, environment, capability, and the list of changed file paths. It does not send diffs or file contents. The GitHub App webhook adds the pull request title and author username. To render the signer's Decision Brief, our enrichment service then fetches a bounded excerpt of the change from GitHub: up to 10 files, at most 2,000 characters of patch per file and 8,000 in total, plus the pull request description.

What we store: Decision records and signed receipts, permanently: they are the audit evidence. The Decision Brief excerpt described above, including those bounded diff snippets and the pull request description, is stored with the deploy request today. On the direct API lane, the action's parameters are stored as part of the receipt's request snapshot. We have adopted a payload minimization policy (hashes plus capped excerpts instead of stored payloads); this page will be updated when that change ships.

What public receipt pages expose: Decision metadata, timestamps, policy and risk labels, the signer's GitHub identity, and a short AI-written description of the change. Never raw diffs, action parameters, secrets, or source code. A receipt link is a capability: anyone holding the exact link can view that receipt, so share it as deliberately as the change itself.

What we never have: Your repository beyond the bounded excerpt above. Your secrets: API keys we issue are stored as scrypt hashes, and credentials you store with us are encrypted at the application layer before they reach the database. Your production databases and infrastructure.

In transit: HTTPS everywhere. TLS termination is provided by our hosting platforms (Render for the application, Vercel for this site).

At rest: the database is Render-managed PostgreSQL; disk encryption at rest is a Render platform control, per Render's security documentation.

Application layer: connector credentials and stored secrets are encrypted with AES-256-GCM before they reach the database. We do not publish cipher or protocol versions we have not verified ourselves.

Receipts are signed with Ed25519 over a canonicalized field set that includes the decision, the request snapshot hash, the policy version, and, since receipt v2, the decider's identity, credential lane, and production-or-demo scope. The exact signed bytes are stored with each receipt, so any later edit to a signed field is detected at verification and the receipt is withheld.

Signing keys are held as environment secrets on the hosting platform: never in the database, never client-side. Only public keys are stored and served. Demo receipts are signed with a separate demo key and carry the demo scope inside the signed bytes, so a demo receipt can never pass as production evidence.

A key registry tracks active, rotated, and revoked status. Rotation today is a documented manual procedure; automated rotation and customer-held keys are on the enterprise roadmap.

Policy (adopted 2026-08-25): signed receipts are append-only and kept indefinitely: they are the evidence. Decision Brief payload excerpts: 90 days. Demo receipts: 90 days. Internal job and model-call logs: 180 days.

Status: automated enforcement of these windows is being built now. Until it ships, we honor written deletion requests within 30 days. Closing a workspace immediately revokes its API keys.

Customer sign-in: GitHub OAuth. No passwords are stored. Sign-in inherits the MFA you enforce on your GitHub account; there is no separate Permission Protocol MFA today.

Who can approve: Approvals are restricted to workspace owners and admins, or an API key explicitly scoped for approvals on that workspace. The default quorum is one named signer, configurable per environment. A signer who denied cannot also approve, and deny is terminal.

What proves an approval: The signer's authenticated session, resolved to their workspace membership, with their identity, credential lane, and attribution confidence bound inside the receipt's Ed25519 signature. Step-up at the moment of signing is on for every workspace: approving a production request requires a passkey assertion on a single-use, two-minute challenge bound to that exact request. Pilots and new workspaces are passkey-only; workspaces that predate it may use a forced re-login until their 30-day transition window closes. The proof given is recorded in the signed receipt.

API keys: Per-workspace keys with explicit scopes, stored as scrypt hashes, shown once at creation, revocable at any time. Read scopes and approval scopes are separate: only an approval-scoped key can move a request toward a signed receipt.

Our own access: Permission Protocol is founder-operated; production access is limited to the founder. SAML SSO and SCIM for customers are on the enterprise roadmap, without a committed date.

Failure mode: the deploy-gate action fails closed by default, and for production environments it refuses fail-open even when a workflow requests it.

Availability: published status page above. An SLA is formalized with the annual contract.

We welcome good-faith security research. Report privately to [email protected]; please do not open public issues for vulnerabilities.

Safe harbor: we will not pursue or support legal action against good-faith research that respects user privacy, avoids service disruption and data destruction, and gives us reasonable time to remediate before disclosure. No formal bounty program exists today; with permission, we credit reporters in release notes.

Every receipt page runs full verification on view: the Ed25519 signature over the stored canonical bytes, key status, and expiry. A receipt whose contents do not match its signature is withheld: the page shows an explicit unverified state and never renders it as an authorization. A signed denial shows an authentic signature and a denied decision; authenticity and outcome are separate axes.

You do not have to trust our verdict. Anyone can verify a receipt independently, with no account: every receipt page links its signed artifact (the exact signed bytes and the full Ed25519 signature, at /r/:id.json) and the published issuer key set (/.well-known/permission-protocol/keys.json). Recompute the SHA-256 of the payload bytes, compare it to the artifact's hash, and verify the signature against the published key: a standard Ed25519 check with no Permission Protocol software required.

If you would rather not write that check yourself, the open source verifier CLI (Apache-2.0, a single file with no dependencies beyond Node's standard library) runs the same procedure and prints the decider, the commit, and the verdict:

The example receipt is real: it is the signed record of the merge that shipped this page's verification section. Substitute any public receipt URL.

For CI and audit flows, the tenant-authenticated artifact export covers exported receipts. The receipt format is a versioned, open specification: a receipt verifies forever under the rules it was signed with.

A receipt the hosted service issues has one format whichever surface produced the action. The CI/CD lane (Deploy Gate, on merge and deploy) and the execute API lane (agent and tool calls submitted to the router) sign the same field set with the same issuer key set, and each receipt verifies by the same procedure. The signed evidence comes first; the receipt is the artifact that carries it.

Verification does not depend on the surface, and it does not depend on Permission Protocol being reachable when you verify. The public artifact at /r/:id.json carries the exact signed bytes and the full signature, and the issuer keys are published at /.well-known/permission-protocol/keys.json. Fetch both once and keep them with your evidence: the check is SHA-256 over the payload bytes, then a standard Ed25519 verification of the signature over that digest, with no Permission Protocol software or service in the loop. Receipts also verify online at /r/:id and through the public API.

MCP Guard signs the receipts it emits locally, with a per-install development key, and writes them to its own append-only file. Those records are not yet issued by the hosted service or covered by its published key set.

Rod's agent is an AI twin with Rod's face and voice that takes discovery calls at /talk. It says so in its first sentence, a splash says so before the call starts, and a label stays on screen beside the video for the whole call. The page does not allow the video to go fullscreen, so the label cannot be dismissed. The label is not a setting. There is no undisclosed mode.

Every action it takes goes through the same execute API our customers use, under a policy that clears three operations on its own: sending a public document, booking time with Rod, and writing a note to our CRM. Each of those still produces a signed receipt; policy cleared it, and the receipt says so. Anything outside that exact list holds for a human.

Rod signs the rest: any pilot terms, any answer to a security questionnaire item, any recap email, and the kill switch demo. The agent narrates the wait, the prospect sees the receipt, and a decline is a decline. There is no override on the agent's side.

A real receipt from the agent's first recorded call will be linked here.

Talk to the agent