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 execution 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 explicit.
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: execute in-scope work, capture evidence, escalate at boundaries
- 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
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 remains 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/deny outcomes, approval events, command/tool output, timestamps, receipt-linked artifacts | root cause, exploitability, business impact, attacker intent |
| Failure handling | explicit governed failures (approval stall, tool crash, 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 explicit:
- Scope enforcement is driven by
in-scope.txt. If configuration is wrong, enforcement boundaries are wrong. - Approval behavior follows workflow and external policy. Paused approvals do not auto-resolve.
- Runtime integrity (host, keys, toolchain) is assumed. Host compromise invalidates governance guarantees.
- Tool output quality is not validated by receipt generation. Receipts can attest execution of incorrect tool output.
- Receipt guarantees prove what ran and what was captured, not whether your conclusion is correct.
See Threat Model for the complete trust boundary map.
6. Next-page handoff
Next, read Defender for the triage and containment path that follows operator-led execution.