AI Agent Delegation vs. Human Approval: What Each Proves

An agent can have permission to use a tool without a person having approved every action it takes through that tool. A useful authorization review separates those questions: what access was delegated, and what decision was made about this particular action?

Two kinds of evidence

Delegation evidence describes an agent's authority to act on behalf of someone. Depending on the identity system, a token may describe the subject, permitted scopes, audience and expiry. That establishes the boundaries of access; it does not necessarily record a fresh human decision about each use.

Decision evidence records an approval or denial for a specific request. To assess it, you need the action scope, the recorded decision, the approver attribution, the time and the policy context. A signature can make that record tamper-evident.

One repository, two different permissions

Consider an agent with credentials that let it open a pull request. It proposes a database migration. The credentials explain why the agent could submit the change; they do not establish that the repository owner approved that migration.

A separate approval request can identify the exact commit and require a reviewer's decision. The resulting receipt records that decision. The repository must still enforce the required check and appropriate bypass settings. If the commit changes, the system needs to establish whether the existing authorization still applies.

This is the distinction between access to propose a change and authority to release it. The Deploy Gate guide describes the repository setup.

The same principle applies to a refund: approval of one amount does not cover a larger request. This concept illustrates that scope check.

A signature does not establish everything

A valid issuer signature establishes that the signed content matches what the holder of that signing key issued. Verification also depends on trusting the correct issuer key and checking the receipt's scope and validity conditions.

The signature alone does not establish how a visitor's identity was checked, whether the reviewer understood the change, or whether the action ultimately ran. Those are separate questions. In Permission Protocol's public demo, a typed name is self-reported and unverified; Permission Protocol signs the demo receipt. It is not a cryptographic signature made by that visitor.

Keep authorization separate from the agent

An agent's own explanation of why an action was safe is useful context. A separately enforced approval decision provides a different control: the agent requests authority, and the configured approval path decides whether to grant it.

This works alongside identity providers, gateway policies and platform approval dialogs. Teams should define which actions can proceed under policy, which are prohibited and which require an identified human reviewer. The important implementation question is whether the execution path actually enforces that decision.

What to inspect in a receipt

• The exact action or commit covered by the record.
• The decision and the identity assurance behind the approver attribution.
• The issuing authority, policy context and relevant timestamps.
• The signature verification result and any scope or expiry checks.
• The distinction between authorization, a simulated demo and actual execution.

Use the receipt specification and receipt field guide to inspect the format. For a broader treatment of evidence, see signed authorization receipts. For the approval workflow itself, start with the human approval guide.