Skip to content
PERMISSION/PROTOCOL

Build or buy

You are hiring someone to build this.

Approval gates, step-up authorization, tamper-evident records, evidence for auditors. Here is what the hire builds on top of instead.

What the posting asks for

The job description, line by line.

These are the phrases hiring managers use for this role, paraphrased. Each one links to where this site already covers it.

The split

What Permission Protocol provides. What your hire still owns.

The hire is not replaced. The primitives are. The right column is real work, and it is the work only your organization can do.

What Permission Protocol provides

  • Gate enforcement at the MCP and CI/CD choke points: MCP Guard in the tool-call path, Deploy Gate as a required check on merge and deploy
  • Ed25519-signed receipts for each gated action, approve and deny alike, with the signer bound inside the signature
  • Public verification: each receipt verifies at /r/:id and against the published issuer key set, with no Permission Protocol software required
  • Fail-closed hold and kill switch: a held action waits, a frozen tenant denies with a signed receipt, and nothing executes on an error path
  • Control mappings to AIUC-1, the CSA Agentic Trust Framework, and NIST AI RMF, with the same three honest statuses on each
  • MCP Guard as open source under MIT: it runs in your environment, in the client's server path, with no dependency on our hosted service

What your hire still owns

  • Your gate policies: which actions are consequential, at what thresholds, and who may sign for each. The threshold logic lives in your wrapper at the choke point today; we record what crossed it
  • Your agent registry and identity: receipts bind the agent ID and run you supply, and your IdP stays the source of truth for who the humans are. Bring your registry
  • Your workflows and integrations: where the choke points sit in your stack, which channel your signers decide in, and what happens after a receipt is issued
  • Your risk program: the risk tiers, the control narrative, and the audit itself. We do not certify your controls. Your auditor does, with an artifact that verifies

Time to evidence

The clock starts when the first receipt exists, not when the hire starts.

An auditor does not ask when you staffed the project. They ask for the record of each gated action and the human who signed it. Compare the two paths to that first record.

Hire and build

  1. 1A hiring cycle for a senior engineer who has done this before
  2. 2A ramp onto your stack, your choke points, and your signers
  3. 3A first gate, then a signing surface, then a record format, then a verifier
  4. 4The first artifact an auditor can check without trusting the system that produced it

You know your own hiring cycle and ramp. Add them up before the first receipt exists.

Start on Permission Protocol

  1. 1One workflow. A clear scope. Pricing agreed before work begins. 30 days · one gate, built with your engineer.
  2. 2The choke point, the policy path, and the signers mapped in the first session
  3. 3Each in-scope action carries a signed receipt in your own ledger by the end
  4. 4Your hire, if you still make one, starts on policies and integrations instead of on primitives

The pilot is the 30 days. The hire is still yours to make; they start further up the stack.

The built-in dialog

Why not only the platform's built-in confirmation?

Every platform your agents touch is shipping its own confirmation dialog. Keep them: they are the routine lane, and policy clearing the routine is how the gate stays out of the way. What a dialog cannot do is stand in for decision proof on the consequential slice. It records a click inside one product, in that product's log, in that product's format, written by the same system that ran the action. The actor cannot be the notary.

Your auditor does not ask about one surface. They ask for one portable, verifiable record across all of them, for each gated action, with the signer named. Delegation proof is not decision proof: a token or a log showing the agent was allowed to act on someone's behalf is not a signed record that a named human approved this specific action. The receipt is that record, and it verifies outside every platform that produced the action, including outside ours.

The first 30 days

One gate, gated end to end, before the hire's first day.

The pilot is scoped to the one action your auditor will ask about first. It ends with each in-scope action carrying a signed receipt in your own ledger, and with your team knowing exactly which policies and integrations remain yours to build.

Bring your registry. Bring your IdP. Bring the gate policy you already drafted for the job description. The pilot fits around them.

Regulated and Enterprise

Design Partner Pilot

Go live on one gate

One workflow. A clear scope. Pricing agreed before work begins.

30 days · one gate

For a team whose AI agent takes a consequential action, and a security review, auditor or bank partner who will ask who approved it.

Scope

  • One gate: money out, agent code to prod, infra changes, PII or PHI export, or identity changes
  • One repository or MCP client, in your environment
  • Named signers and acceptance criteria agreed on day one

What you get

  • Integration built with your engineer; about 4 to 6 hours on their side
  • Live on the gate by day 30, with signed receipts your reviewer can verify independently
  • Security review pack: questionnaire answers, AIUC-1 and ATF control mapping, evidence export

Delivery & support

  • Shared Slack channel, same-day response, weekly working session
  • We join your customer's security review call
  • Full refund if the day-one acceptance criteria are missed

Paid implementation with agreed acceptance criteria. Nothing auto-renews: if you do not continue, the gate drops to Free and your receipts stay verifiable.

For the security engineer

Or skip the call and put a proxy in the path.

MCP Guard is the open-source half. Install it, start in observe mode so nothing is blocked, and each tool call starts leaving a receipt. Tighten policy tool by tool when the picture is clear.

Before you post the role

Fifteen minutes with an engineer who already built it, with your job description open.

Bring the posting. We will walk the split above against it, line by line, and tell you plainly where a hire is still the right answer.