OPERATE
Governance Domain

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 explains 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 can authorize
  • approval modes and their risk posture
  • what authorization records must include before execution
  • what authorization proves and what still depends on trust

3. Principals and authority scope

WitnessOps records three principal classes:

PrincipalRoleAssumption boundary
operatorInitiates and runs the workflowCaller identity provenance is an outside trust input
approverAuthorizes gated or high-risk stepsApprover authority mapping is maintained outside WitnessOps
systemAutomation principal for orchestrationPermissions are minimally scoped and policy-bound

If identity input is false, WitnessOps preserves that false identity faithfully. That is an explicit trust boundary.

4. Approval modes and minimum bar

ModeCurrent postureRisk profile
Self-approvalAllowed only when explicit policy permitsFast, weaker separation of duties
Designated approverNamed principal requiredBetter accountability for intrusive actions
Multi-party approvalTarget posture for highest-risk lanesStrongest resistance to single-principal failure

For production-impacting or sensitive-data workflows, require a designated approver or stronger.

5. Required authorization record fields

Before execution, authorization should clearly capture:

  1. the objective of the step
  2. the exact target boundary
  3. the technique class or risk class
  4. the approval authority and timestamp path
  5. the time or context constraints, such as engagement or 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 the denial becomes part of the governed record.

Authorization evidence should include:

  • operator and approver principals
  • approval or denial timestamp
  • runbook version and policy context
  • gate evaluation outcomes
  • target or engagement linkage

This proves the decision path existed. It does not prove the decision was good.

7. What authorization does not guarantee

Authorization does not guarantee:

  • a truthful upstream identity source
  • perfect scope-source quality
  • independent judgment where self-approval is allowed
  • prevention of collusion on its own

Its core value is reviewability: unsafe approvals and scope drift remain inspectable after the fact.

8. Next-page handoff

Next, read Policy Gates for the per-step enforcement behavior that puts this authorization contract into action.

Then use:

Authorization Model | WitnessOps