Authorization Model
The approval and authorization boundaries that govern WitnessOps execution.
Authorization is the control contract that separates a requested action from an allowed execution path.
1. Problem this page solves
Teams often have execution evidence but weak evidence of who authorized what and under which boundaries.
This page defines the authorization model that must exist before governed execution is allowed to proceed.
2. What you should understand after reading
After this page, you should understand:
- which principals exist and what each role authorizes
- approval modes and their risk posture
- what authorization records must include before execution
- what authorization proves vs what remains trust-based
3. Principals and authority scope
WitnessOps records three principal classes:
| Principal | Role | Assumption boundary |
|---|---|---|
operator | Initiates and runs workflow | Caller identity provenance is external trust input |
approver | Authorizes gated/high-risk steps | Approver authority mapping is externally maintained |
system | Automation principal for orchestration | Permissions are minimally scoped and policy-bound |
If identity input is false, WitnessOps preserves false identity faithfully. That is an explicit trust boundary.
4. Approval modes and minimum bar
| Mode | Current posture | Risk profile |
|---|---|---|
| Self-approval | Allowed only when explicit policy permits | Fast, weaker separation of duties |
| Designated approver | Named principal required | Better accountability for intrusive actions |
| Multi-party approval | Target posture for highest-risk lanes | Strongest resistance to single-principal failure |
For production-impacting or sensitive-data workflows, require designated approver or stronger.
5. Required authorization record fields
Before execution, authorization should clearly capture:
- objective of the step
- exact target boundary
- technique class/risk class
- approval authority and timestamp path
- time/context constraints (engagement/incident window)
If one of these is missing, authorization quality is incomplete.
6. Denial states and emitted evidence
Authorization fails when identity, scope, approval, tool allowance, or record completeness does not satisfy policy.
On failure, the step does not run and denial becomes part of governed record.
Authorization evidence should include:
- operator and approver principals
- approval/denial timestamp
- runbook version and policy context
- gate evaluation outcomes
- target/engagement linkage
This proves decision-path existence, not decision quality.
7. What authorization does not guarantee
Authorization does not guarantee:
- truthful upstream identity source
- perfect scope source quality
- independent judgment where self-approval is allowed
- prevention of collusion by itself
Its core value is reviewability: unsafe approvals and scope drift are inspectable after the fact.
8. Next-page handoff
Next, read Policy Gates for per-step enforcement behavior that executes this authorization contract.
Then use:
- Lab Mode and Scope Bypass for exception path handling
- Runbooks for authored workflow contracts
- Threat Model for trust-boundary limits