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. 18 weeks · fixed scope, one gate, founder-run
  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 eight weeks. 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 eight weeks

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

Validate and roll out

$50,000

8 weeks · fixed scope

For a team ready to take one agreed workflow through evaluation, a controlled rollout and an operational handoff.

Scope

  • One agreed workflow
  • One repository and selected environment
  • Approval policy and evidence requirements defined together

What you get

  • Everything in the two-week evaluation
  • Controlled live use after acceptance
  • Operational evidence review and handoff

Delivery & support

  • Founder-led delivery over eight weeks
  • Final acceptance report and continuation decision

Start here, or extend the $10K evaluation for $40K and six more weeks. Total: $50K over eight weeks.

Scope the full pilot

Need help choosing a workflow? Find your first gate.

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 the founder, 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.