New Operator
Start here if you are doing hands-on security work and need to understand scope, workflows, evidence, and escalation.
This page defines the operator lane for hands-on security work under governed scope, approval, and evidence rules.
1. Problem this page solves
Operators lose control of risk when execution starts before scope, approval boundaries, and evidence requirements are clear.
This page gives the first-pass operating path so execution decisions stay auditable and proportional.
2. What you should understand after reading
After this page, you should understand:
- the operator role boundary: run in-scope work, capture evidence, escalate at the boundary
- what to read first before running technical steps
- which execution decisions you own
- what to treat as observed evidence vs inferred conclusion
- what to defer until after the first operating cycle
3. Mechanism-first role path
Fleet / mesh operators
If you operate on the WitnessOps mesh (fleet VM, bastion, goal0-edge), use internal mesh operator documentation for hunt sync, DNS, and deploy truth. That material is not published on this public docs site. This site remains the buyer and doctrine layer.
Read first (in order)
- Getting Started
- Authorization Model
- Operations
- Evidence
- Is This In Scope?
- Do I Need to Escalate?
- What Evidence Is Required?
Decisions you own in this role
| Decision | What you own | Primary pages |
|---|---|---|
| Scope check | Confirm each target and action stays in approved scope before execution | Authorization Model, Is This In Scope? |
| Workflow selection | Choose the least disruptive runbook path that can answer the objective | Operations, Runbooks |
| Evidence sufficiency | Collect enough traceable evidence to support or reject the claim | Evidence, What Evidence Is Required? |
| Escalation trigger | Stop and escalate when scope, approval, or impact certainty breaks | Do I Need to Escalate? |
Defer initially
Defer these until your first governed workflow is complete:
- integration implementation details in Integration Author
- low-level receipt field references in Receipt Spec
- scenario pages not tied to the current assignment
4. Observed vs inferred
| Layer | What is observed | What is inferred |
|---|---|---|
| Execution and evidence | scope gate allow or deny outcomes, approval events, command or tool output, timestamps, receipt-linked artifacts | root cause, exploitability, business impact, attacker intent |
| Failure handling | explicit governed failures such as approval stall, tool crash, or evidence hash mismatch | confidence that the investigation is complete |
Treat inferred conclusions as conclusions. Do not record them as direct observations.
5. Role-specific trust assumptions
Operate with these assumptions kept explicit:
- Scope enforcement is driven by
in-scope.txt. If configuration is wrong, enforcement boundaries are wrong. - Approval behavior follows workflow and outside policy. Paused approvals do not auto-resolve.
- Runtime integrity (host, keys, toolchain) is assumed. Host compromise breaks governance guarantees.
- Tool output quality is not validated by receipt generation. Receipts can attest execution of incorrect tool output.
- Receipt checks (when verified against trusted keys) prove what the system recorded as run and captured, not whether host reality matches the record or whether your conclusion is correct.
See Threat Model for the full trust-boundary map.
6. Next-page handoff
Next, read Operations to move from role boundaries into the governed workflow path you will actually run.