01
Agent attempts action
An AI coding agent opens a PR that touches a protected production workflow.
The Agent Authorization Gap
Your agents have access.
Do they have authority?
Permissions define what an agent may do. For selected consequential actions, require a designated person to approve the exact proposal.
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's GitHub Deploy Gate example shows a decision tied to a commit and a signed approval receipt. Other workflows need their own integration and enforcement checks.
Watch an agent-written PR get blocked until a human signs it.
The GitHub Deploy Gate example requires the approval check to be enforced by repository rules. The receipt records approval; deployment success needs separate evidence.
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 records the decision
The approved action gets a public receipt showing who approved what, when, and under which policy.
05
Approval check passes
The approval check passes for the approved commit. GitHub still applies the repository's other required checks and rules.
Five controls to check before an agent acts
Identify the caller, limit permissions, decide when a human must approve, enforce the decision and retain evidence.
Authorization policies can limit operations, resources and context. A credential may allow an agent to update a billing record while denying access to another account. Start by checking those existing controls.
For an action that also requires human approval, the reviewer needs the exact proposal: which account, how much money, or which commit. A broad task instruction does not record a decision about those details.
Place the enforcement check before the protected operation. If another credential or execution path can bypass it, the approval screen alone cannot hold that action.
What each control answers
- IdentityWho is calling, and how was that identity authenticated?
- PermissionsWhich operation, resource and context does policy permit?
- Human approvalDid the designated reviewer approve these exact parameters?
- EnforcementWhat stops execution if that decision is missing or invalid?
- EvidenceWhat records support the decision and the separate execution result?
Start with the controls your framework provides
GitHub environment reviews can hold deployment jobs for approval or rejection. Check your plan, self-review restrictions and administrator bypass settings.
LangGraph interrupts pause a workflow for input and use checkpoints to resume it. Code before an interrupt runs again when that node resumes, so side-effect placement matters. Follow the runnable LangGraph approval tutorial to test pause, rejection and restart behavior with a mocked action.
Write down what remains unresolved in your workflow: approver identity, changed parameters, expired decisions, retries or independent evidence. The human-approval guide helps you choose where to enforce that decision.
Three decisions your agent system should make before execution.
Illustrative policy choices for your workflow. These examples do not imply every action has a working Permission Protocol integration.
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.
Keep decision evidence and execution evidence
A signed approval record and the downstream result answer different questions.
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.
In the GitHub example, the receipt records the repo, PR, commit, signer and policy decision. Verifying its signature checks that the covered fields match the issuer's signed record. Also verify that you trust that issuer and the recorded approver's authority.
The signature alone does not prove that the action ran successfully, that the policy was correct, or that every action was captured. Keep a separate execution result linked to the request. Local MCP Guard logs should not be described as independently signed receipts.
What makes an AI agent receipt verifiableIllustrative 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
- Illustration only
Agent Authorization Gap Checklist
If an agent can do more than read and summarize, run this checklist.
- 1
Can the agent affect customers, money, production systems, legal exposure, security posture, infrastructure, or external communications?
- 2
Is there a policy decision before the action executes?
- 3
Can low-risk actions clear automatically?
- 4
Can consequential actions route to a human signer?
- 5
Are prohibited actions denied with no override?
- 6
Is approval tied to the exact action parameters, not a vague task description?
- 7
Does the approval produce a receipt?
- 8
Could you explain the action to a customer, auditor, board member, or regulator six months later?
Put the answers into a workflow specification with the approval-design checklist and downloadable worksheet.
Want me to map your agent workflow?
Share one action your agent performs and the control you need. We can discuss the approval boundary and whether Permission Protocol fits. A conversation or early-access request does not activate an integration.
Send the workflowUpdated and sources checked .