> ## Documentation Index > Fetch the complete documentation index at: https://docs.atlasent.io/llms.txt > Use this file to discover all available pages before exploring further. # Permit > A Permit is the bounded runtime artifact that embodies a positive authorization and is verified at the execution boundary before the governed effect. 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 ```text theme={null} Authority + Policy + Action + Resource + Context + Assertions/Approval ↓ Evaluation → Decision ↓ allow only Permit issued ↓ Gate verifies Permit for this execution attempt ↓ Verification / single-use consumption ↓ Execution → Native Effect ↓ Evidence / Proof ``` ## Issue The public evaluation operation is: ```http theme={null} POST /v1/evaluate ``` 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: ```http theme={null} POST /v1-verify-permit ``` 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. Why the determination is made at the execution boundary. See the Permit in the full Action → Evidence lifecycle. ## Related * [Organizational authority](/concepts/organizational-authority) * [Authority vs. authorization vs. approval vs. access](/concepts/authority-vs-authorization) * [Quickstart → Verify a permit](/quickstart/verify-permit) * [Proof verification](/concepts/proof-verification) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.