Skip to content
Agent Permission Protocol (APP): Execution-Time Authority for AI Agents
v0.4.0

Agent Permission Protocol (APP)

The Agent Permission Protocol (APP) is a protocol that requires explicit, cryptographically verifiable permission policies to gate agent execution at runtime.

As AI systems increasingly act through autonomous agents—invoking tools, modifying systems, and triggering irreversible outcomes—existing governance, policy, and access-control models have proven insufficient. In most architectures today, authority is inferred from access rather than explicitly validated at the moment an action executes.

APP exists to address this structural gap.

At a glance

The Agent Permission Protocol (APP) answers one question: Who authorized this action — and under what constraints — at the moment it executed?

APP defines a permission object that must be validated at execution time, so authority is explicit, bounded, and verifiable.

TL;DR

  • APP is a public protocol for execution-time authority in agentic systems.
  • It requires an explicit permission policy to be validated immediately before an action executes.
  • Permissions are scoped, time-bounded, and revocable.
  • Enforcement is independent of model reasoning or tool exposure.
  • Stewardship and versioning are maintained by Crittora.

Key facts

  • APP is a minimal public specification for execution-time authority in agentic systems.
  • Authority is represented as a cryptographically verifiable permission policy.
  • Permissions are scoped, time-bounded, and revocable.
  • Enforcement is independent of model reasoning.
  • Stewardship and versioning are maintained by Crittora.

Implementer assets

APP v0.4.0 includes non-normative assets for implementers:

  • JSON Schemas for permission policies, approval challenges, and approval receipts.
  • YAML examples for payment approval, external email approval, derived policies, challenges, and receipts.
  • Approval receipt conformance vectors for allow and fail-closed cases.
  • A verifier algorithm page and integration guide for agent runtimes, gateways, orchestrators, and MCP-style tool systems.
  • CI validation for schema structure, YAML examples, conformance vectors, and the strict MkDocs build.

Problem statement

Agentic systems introduce a failure mode that is not caused by model behavior, but by authorization design.

In common implementations:

  • Authority is granted implicitly through credentials, roles, or tool exposure
  • Permissions are treated as static configuration rather than runtime-validated objects
  • Execution proceeds even when scope, duration, or consequence is ambiguous
  • Exceptions accumulate without enforced revocation

As a result, systems may appear compliant while authority silently expands over time.

This failure mode is difficult to detect, difficult to audit, and difficult to reverse.

Any agent system that permits external action or tool invocation without presenting a verifiable permission policy at execution time is operating with ambient authority.

Core principle

Authority must be explicit, bounded, and verified at execution time.

Capability alone is not authorization.
Access alone is not intent.
Policy alone does not enforce invariants.

The Agent Permission Protocol formalizes authority as a first-class object that must be validated immediately before an agent action is permitted to execute.
Authority is enforced using cryptographically verifiable permission policies, not model compliance or implicit tool access.

What APP defines

The Agent Permission Protocol specifies:

  • Explicit authority grants for agent actions
  • Scope constraints that limit what may be attempted
  • Time bounds that restrict how long authority remains valid
  • Predicate conditions that must be satisfied at execution
  • Revocation semantics that fail closed
  • Audit-safe validation independent of model reasoning

APP is concerned with whether an action may be attempted at all, not with how the action is carried out.

Non-goals

APP does not attempt to:

  • Define model alignment or safety techniques
  • Replace identity or access management systems
  • Provide agent orchestration frameworks
  • Evaluate intent, reasoning quality, or output correctness
  • Encode business logic or workflow design

The protocol is intentionally minimal. Its purpose is to define an invariant enforcement layer for agent authority.

Why a protocol

Frameworks describe behavior.
Policies document intent.
Protocols define invariants.

APP enforces a separation between intelligence (what an agent proposes) and authority (what an agent is permitted to execute), enforced outside the model.

Agentic systems operate at machine speed, across systems, and without continuous human oversight. In such environments, authority must be governed by rules that are deterministic, enforceable, composable, and independent of model behavior.

APP exists to provide that invariant layer.

Protocol diagrams

The diagrams below summarize the current v0.4.0 public draft and align with the canonical whitepaper.

Execution flow

flowchart LR
  intent["Task / intent"]
  issue["Issue permission policy<br/>issuer"]
  seal["Seal policy<br/>sign then encrypt"]
  present["Present sealed policy<br/>presenter"]
  verify["Verify policy<br/>verifier"]
  valid{"Policy valid?"}
  resolve["Resolve policy capabilities"]
  surface["Construct execution capability surface"]
  execute["Execute within authorized scope<br/>executor"]
  audit["Emit audit record"]
  deny["Deny execution<br/>fail closed"]

  intent --> issue --> seal --> present --> verify --> valid
  valid -->|Yes| resolve --> surface --> execute --> audit
  valid -->|No| deny

Figure 1. No agent action or tool invocation is permitted unless a sealed permission policy is presented and verified before execution.

Separation of intelligence and authority

flowchart LR
  subgraph model["Model / intelligence"]
    prompt["Prompt / context<br/>non-authoritative"]
    propose["Model proposes action"]
    prompt --> propose
  end

  subgraph authority["Authority / execution"]
    verify["Verify permission policy"]
    valid{"Policy valid?"}
    resolve["Resolve policy capabilities"]
    surface["Construct execution capability surface"]
    execute["Execute within scope"]
    deny["Deny execution<br/>fail closed"]

    verify --> valid
    valid -->|Yes| resolve --> surface --> execute
    valid -->|No| deny
  end

  propose -->|"sealed permission policy required"| verify

Figure 2. The model may propose actions, but authority is enforced outside the model through policy verification and capability-derived execution control.

Verifier pipeline

flowchart TD
  step1["1. Decrypt permission policy"]
  step2["2. Verify cryptographic signature"]
  step3["3. Parse policy and validate required fields"]
  step4["4. Validate policy_version, issued_at, not_before, and expires_at"]
  step5["5. Enforce replay protection when present"]
  step6["6. Enforce audience binding"]
  step7["7. Check revocation per revocation_mode (§7.5)"]
  step8["8. Verify derivation_chain when policy is derived (§7.4)"]
  step9["9. Validate approval receipt when approval gate applies (§7.6)"]
  step10["10. Resolve policy capabilities using verifier registry"]
  step11["11. Construct execution capability surface"]
  step12["12. Apply runtime limits per typed primitives (§6.1)"]
  step13["13. Begin execution"]
  deny["Any failure -> deny execution"]

  step1 --> step2 --> step3 --> step4 --> step5 --> step6 --> step7 --> step8 --> step9 --> step10 --> step11 --> step12 --> step13
  step1 -. failure .-> deny
  step2 -. failure .-> deny
  step3 -. failure .-> deny
  step4 -. failure .-> deny
  step5 -. failure .-> deny
  step6 -. failure .-> deny
  step7 -. failure .-> deny
  step8 -. failure .-> deny
  step9 -. failure .-> deny
  step10 -. failure .-> deny
  step11 -. failure .-> deny
  step12 -. failure .-> deny

Figure 3. Validation is deterministic and fail-closed. Revocation, derivation chain, approval receipt validation, capability resolution, and execution surface construction occur before execution begins. The pipeline is 13 ordered steps in v0.4.0.

Sequence diagram

sequenceDiagram
  participant I as Issuer
  participant P as Presenter
  participant V as Verifier
  participant E as Executor
  participant T as Tool

  I->>I: Create permission policy
  I->>I: Sign then encrypt
  I->>P: Deliver sealed permission policy
  P->>V: Present sealed permission policy
  V->>V: Decrypt and verify signature
  V->>V: Validate fields, time bounds, audience, replay, limits
  V->>V: Check revocation per revocation_mode (§7.5)
  V->>V: Verify derivation_chain when policy is derived (§7.4)
  V->>V: Validate approval receipt when approval gate applies (§7.6)
  V->>V: Resolve capabilities
  V->>E: Construct execution capability surface
  E->>T: Execute within authorized scope
  T-->>E: Result
  E-->>V: Execution outcome
  V->>V: Emit audit record
  alt Verification fails
    V-->>P: Deny execution
  end

Figure 4. Issuer, presenter, verifier, executor, and tool interactions show sealing, presentation, verification, execution gating, and audit emission.

Status

  • Current version: v0.4.0
  • Status: Draft / Public Review

v0.4.0 adds APP-Approval-1, a normative approval gate and signed approval receipt model for high-consequence agent actions. It expands the verifier pipeline to 13 ordered steps by validating approval receipts after revocation and derivation checks, but before capability resolution. Approval can unlock already-declared gated authority, while expanded authority requires issuance of a new sealed policy.

Stewardship

The Agent Permission Protocol is stewarded by Crittora.

Stewardship implies maintenance, versioning, and editorial responsibility. It does not imply exclusive ownership, implementation rights, or control over downstream use.

The protocol is intended to be examined, challenged, and implemented independently.

Canonical specification

The authoritative specification of the Agent Permission Protocol is published in the accompanying whitepaper:

https://www.crittora.com/app/whitepaper

This repository mirrors the released public version and changelog. The full mirrored whitepaper is also available on this site at Whitepaper. In the event of wording divergence, the whitepaper at crittora.com is authoritative.

The public source repository is hosted at:

https://github.com/Crittora/agent-permission-protocol

Intended audience

This specification is written for:

  • System architects designing agentic platforms
  • Security engineers responsible for execution control
  • Platform owners accountable for downstream outcomes
  • Researchers evaluating agent governance primitives

It is not written for marketing, evangelism, or trend commentary.

License

This repository is licensed under the Apache License, Version 2.0.

Closing note

As agents gain the ability to act, the critical question is no longer what they can do.

It is:

Who authorized this action — and under what constraints — at the moment it executed?

The Agent Permission Protocol exists to make that question answerable by design.

Stewarded by Crittora.