Policy Gates
How WitnessOps enforces approvals, scope, and preconditions before execution can proceed.
Policy gates are the runtime enforcement layer that turns authorization policy into an allow-or-block decision before a step runs.
1. Problem this page solves
Authorization can look complete on paper while execution still runs outside the intended boundary.
This page explains how WitnessOps enforces preconditions at runtime so policy is not treated as documentation only.
2. What you should understand after reading
After this page, you should understand:
- which gate families are checked before execution
- how gate composition and evaluation order work
- what happens when a gate fails
- what gate evidence is emitted for later review
3. Enforcement mechanism
Gates are declared with runbook steps and evaluated at execution time.
For a step to run, all required gates for that step must pass. Evaluation is ordered and stops on the first failure.
That design prevents partial-approval behavior and keeps later review deterministic.
4. Gate families
| Gate family | What is enforced | Failure meaning |
|---|---|---|
| Scope check | Target stays inside the approved scope boundary | Out-of-scope execution attempt blocked |
| Approval requirement | A required approver has explicitly authorized the step | No valid approval path |
| Target authorization | The target has pre-authorization for the engagement or context | Target not authorized for this run |
| Environmental constraint | Runtime context satisfies policy window, classification, or network constraints | Right action, wrong context |
| Freemail rejection | Principal identity meets governance identity requirements | Identity quality below policy floor |
| Tool allowlist | The step tool is permitted for the workflow risk class | Unauthorized capability invocation |
5. Documentation boundary
This page defines the policy-gate contract. Before claiming that a specific gate family is operationally enforced in a deployment, tie the claim to a runbook version, control-plane configuration, receipt field, or implementation artifact.
Without that link, the safe claim is that the gate is part of the documented governed-execution model, not that a particular production run enforced it.
6. Gate failure semantics
When a gate fails:
- the step does not run
- the failure reason and failing gate are recorded
- the operation either pauses for correction or ends if terminal
- receipt evidence captures the blocked state
A blocked gate is a successful control outcome, not a runtime defect.
7. Evidence and trust boundary
Receipts should record the gate set, evaluation order, pass/fail states, and approval identity and timestamps where required.
This proves policy checks were evaluated as part of the execution path.
What still depends on trust:
- correctness of outside policy sources
- correctness of upstream identity systems
- quality of scope inputs and classification mapping
8. Next-page handoff
Next, read Evidence to see how these gate outcomes appear in portable execution evidence and receipt chains.
Then use:
- Receipts for receipt-level gate and execution records
- Authorization Model for principal and approval boundaries
- Scope Check for operator-side boundary decisions