PERMISSION/PROTOCOL

The Agent Authorization Gap

Your agents have access.
Do they have authority?

Access control tells you what an agent can touch. Authority tells you what the agent is allowed to do before the action happens.

AI agents are moving from suggestions to actions. They can deploy code, update records, send messages, change infrastructure, and touch customer systems. Once that happens, the important question is not only whether the agent has access. It is whether the action was authorized. Permission Protocol adds a policy decision before consequential agent actions and a receipt after approval.

Send me your agent workflowWatch the blocked deploy demo

Watch an agent-written PR get blocked until a human signs it.

01

Agent attempts action

An AI coding agent opens a PR that touches a protected production workflow.

02

Policy evaluates risk

Permission Protocol classifies the action as cleared, approval required, founder veto, or denied.

03

Signer decides

A human reviews the exact action, repo, PR, commit, and policy before signing.

04

Receipt proves authority

The approved action gets a public receipt showing who approved what, when, and under which policy.

05

GitHub proceeds

The required check turns green only after the approved receipt exists.

Access is not the same as authority.

Credentials let agents act. They do not prove the action was authorized.

Modern agents are handed credentials so they can do useful work: write to repos, send API calls, update databases. Those credentials answer one question, can this agent touch this resource?

But credentials say nothing about the action itself. An agent can have read/write access to a billing database and still make an unauthorized change. The access was valid. The authority was not.

The gap between access and authority is where incidents happen, audits fail, and liability lands on whoever was responsible for oversight.

The authority stack

  • Access controlWhat can this agent touch?
  • Policy decisionIs this action allowed under the rules?
  • Signer approvalWho approved the exact action?
  • ReceiptCan we prove what happened later?

Three decisions your agent system should make before execution.

Cleared

Low-risk action. The system can continue automatically.

Example

Agent updates documentation or opens a draft PR without touching sensitive paths.

Approval Required

Consequential action. A human signer must approve before execution.

Example

Agent modifies a deploy workflow, billing code, database migration, or customer-facing message.

Denied

Prohibited action. There is no approval button.

Example

Agent removes audit logging, weakens authentication, disables branch protection, or exports restricted customer data.

The output is not just approval. It is proof.

Receipts are useful during incidents, audits, sales reviews, and board conversations.

Knowing an agent did something is not enough. You need to be able to prove it was authorized, who signed it, under which policy, and exactly what was approved.

Permission Protocol receipts are public, verifiable, and tied to the exact action. They do not summarize what happened in general. They record the exact repo, PR, commit, signer, and policy at the moment of approval.

Six months after an incident, you can open the receipt and answer any question about who authorized the action. No reconstruction. No ambiguity.

Receipt fields

Receipt ID
pp_rcpt_7f3a91c4e2b8
Actor
deploy-bot / claude-code
Action
push to protected branch
Repo / PR
acme-corp/api · PR #441
Commit SHA
a3c8f2d1...
Policy decision
Approval Required → Approved
Signer
Sarah Kim
Timestamp
2026-05-18 18:04:11 UTC
Verification status
Verified
See a live receipt

Agent Authorization Gap Checklist

If an agent can do more than read and summarize, run this checklist.

  1. 1

    Can the agent affect customers, money, production systems, legal exposure, security posture, infrastructure, or external communications?

  2. 2

    Is there a policy decision before the action executes?

  3. 3

    Can low-risk actions clear automatically?

  4. 4

    Can consequential actions route to a human signer?

  5. 5

    Are prohibited actions denied with no override?

  6. 6

    Is approval tied to the exact action parameters, not a vague task description?

  7. 7

    Does the approval produce a receipt?

  8. 8

    Could you explain the action to a customer, auditor, board member, or regulator six months later?

Want me to map your agent workflow?

Send me one workflow your agent performs. I will mark where I would put clear, approval-required, founder-veto, and denied boundaries.

Send the workflow