Skip to main content
A Permit is the current runtime/wire artifact implementing a positive Authorization for a bounded execution context. It is issued only after an Evaluation produces an allow Decision under the current Authority, Policy, Context, approvals/assertions, and other required conditions. A Permit is not:
  • standing organizational Authority;
  • an Approval;
  • a durable permission to act indefinitely;
  • proof that Execution occurred;
  • the Evidence record itself.
The distinction matters because Authorization, Permit issuance, Verification, Execution, and Evidence are separate states.

​
Where the Permit sits

​
Issue

The public evaluation operation is:
On a positive Authorization, the current wire response carries the Permit on the flat response surface (for example permit_token, with related expiry metadata where applicable). New integrations should follow the current OpenAPI/SDK contract rather than older documentation that showed a fictional nested permit: { ... } object. A Permit is bound to the authorized execution context under the applicable contract. The exact binding fields and representation are wire-contract details; do not infer or reconstruct them from display labels.

​
Verify before execution

The current public verification operation is:
Verification occurs at the Gate, immediately before the governed execution attempt. The verification path checks the Permit against the execution context and applicable validity, expiry, revocation, binding, and replay requirements. In the current permit-gated flow, verification also enforces single-use consumption semantics so a Permit cannot authorize repeated execution attempts.
Gate on Verification, not on the earlier allow Decision alone.
An allow Decision means the request satisfied the evaluated authorization conditions at that point. The Gate still has to establish that the Permit is valid for this execution attempt.

​
Single-use and replay protection

A Permit is designed for a bounded execution, not as a reusable bearer permission. Single-use semantics matter because they prevent one positive Authorization from silently authorizing multiple native effects. Replay protection also makes the evidence chain clearer: a Permit can be correlated to a specific governed execution attempt rather than becoming an open-ended capability. If a Permit has expired, been revoked, already been consumed, or does not match the execution binding, the governed permit-gated path must not treat it as valid for a new execution.

​
Permit vs. Authority

Authority is standing and scoped. Permit is bounded and per execution. A principal can have Authority for a class of changes without holding a valid Permit for every request in that class. Policy, context, separation of duties, required approvals, resource state, or other conditions can still make a particular request unauthorized.

​
Permit vs. Approval

An Approval can satisfy a policy condition. It does not itself become the Permit. The runtime re-evaluates the complete request/evidence package and may issue a Permit only if the current conditions satisfy Authorization. This prevents an old or mismatched approval from becoming an automatic execution credential.

​
Permit vs. Evidence / Proof

A Permit is used to control Execution. Evidence is the durable record of what was determined, issued, verified, executed, and observed. Proof is cryptographically verifiable Evidence. Do not describe the Permit itself as the complete audit trail or as proof that the native effect occurred.

​
Fail-closed usage

Where an execution path is actually configured and tested as fail-closed and permit-gated:
No valid Permit means no execution through that governed path.
Do not generalize that statement to shadow, advisory, historical, or otherwise non-enforcing paths.

​
Implementation guidance

  • Use the current SDK/OpenAPI response shape; do not rely on older nested-Permit examples.
  • Preserve the original Action/Actor/Resource/Environment/Context information needed for the verification binding; do not invent missing binding data from the evaluate response.
  • Verify at the actual execution boundary, not minutes earlier in an unrelated workflow step.
  • Treat replay, expiry, revocation, mismatch, malformed responses, and verification failures according to the configured enforcement posture.
  • Persist Evidence that can correlate the Authorization, Permit, Verification, and native execution outcome.

Execution-time authorization

Why the determination is made at the execution boundary.

Runtime flow

See the Permit in the full Action → Evidence lifecycle.