Permits

Permit structure

Permits are explicit control-plane-issued authorization objects. Approval alone is insufficient for execution (per GP-002).

Permit binding requirements include (governed_execution_spec.md Stage 7):

• approved canonical request or execution envelope
• permitted tool identity
• permitted provider class (if relevant)
• allowed scope
• side-effect class
• policy version
• approval record identifier
• workflow lineage
• trust-state constraints
• expiry

Fingerprint binding

Approval fingerprint is the primary binding object connecting approval to executable scope (canonicalization_binding_and_approval_spec.md §10).

CB-003 requires that an approval remains valid only when execution stays within approved canonical target boundaries. Scope expansion requires renewed approval.

Multi-use permits

Policy may allow bounded multi-use permits inside an approved execution envelope. Each permit use is separately recorded in evidence.

Default binding target is envelope-first, while strict modes can require exact invocation binding (per CB-004, canonicalization_binding_and_approval_spec.md §5 and §16).

Permit validation at execution time

Permit checks occur at tool layer before execution (governed_execution_spec.md Stage 8):

• permit authenticity
• permit expiry
• permit-tool match
• permit-scope match
• side-effect-class match
• workflow-lineage match
• trust-state eligibility
• checkpoint status

Any failed check denies execution. Syndicate Code guarantees audit-before-effect: if required audit evidence (like the execution intent event) cannot be durably recorded before the tool is invoked, execution is hard-blocked and the tool is never called; no degraded mode is permitted (per GP-004).

Permit revocation

syndicate permit revoke <permit-id> --reason "<text>"
syndicate permit list
syndicate permit show <permit-id>

Revocation emits permit.revoked and takes immediate effect for new executions (cli_command_reference.md §13.3).