Skip to main content
Version:

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).

Reusable approval grants

Syndicate Code now distinguishes one-time permit issuance from reusable approval grants.

  • session_grant records the durable reusable grant created from a session-scoped or policy-scoped approval decision.
  • session_grant_ref records each matching action that reuses that grant instead of minting a fresh permit.
  • policy_session_grant records a policy-created reusable grant written at session open for governance-suspended / CI-style runs.

This means a reviewer can reconstruct the approval lineage from the auth chain without inferring reuse from runtime behavior.

Session and policy scope

Checkpoint approvals support three operator scopes:

  • once — allow only the current action
  • session — allow matching actions for the rest of the session
  • policy — allow matching actions while the same policy version remains active

Session and policy grants are invalidated on session close, policy change, trust violation, or explicit revoke.

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>
syndicate grants list
syndicate grants history --session <id>
syndicate revoke-grant <grant-id> --reason "<text>"

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