Execution Modes
STATIC, LOCAL, STAGING, and PRODUCTION_SAFE define how much dynamic traffic a run may generate. Mode is recorded in the scope record before any testing.
The four modes
The execution mode is the single control that decides how much dynamic traffic a run may generate. It is declared in the scope record before any testing and is carried through evidence, findings, and the final report.
| Mode | Intended use | Dynamic traffic |
|---|---|---|
STATIC | Source, configuration, and schema review only | None |
LOCAL | Local application, local database, test fixtures, browser automation | Local only |
STAGING | Explicitly authorized non-production target with a rollback plan | Allowlisted hosts |
PRODUCTION_SAFE | Non-destructive evidence gathering and bounded verification | Tightly restricted |
Choosing a mode
If the operator does not specify a mode, start in STATIC, then ask or derive whether LOCAL is available before any dynamic testing. Escalation is a decision, not a drift.
- STATIC
- Everything reachable by reading code, configuration, schemas, migrations, lockfiles, and workflows. Most authorization and business-logic hypotheses can be narrowed here before a single request is sent.
- LOCAL
- Fixtures can be used freely if they are isolated and reversible. Two-account comparisons, concurrency tests with harmless fixture state, and browser automation belong here.
- STAGING
- Requires an exact host allowlist and a rollback plan. Useful when a boundary depends on infrastructure that cannot be reproduced locally.
- PRODUCTION_SAFE
- Prefer read-only evidence and the smallest non-destructive proof. If a test could mutate money, identity, inventory, authorization, external providers, or customer data, it needs explicit authorization or it moves to local and staging fixtures.
Never permitted
- A code-review request never becomes uncontrolled internet scanning.
- Broad exploit spraying is replaced by the minimum test that proves or refutes the hypothesis.
- Evidence, auditability, and rollback are preserved throughout.
- Third-party systems referenced by the code are not in scope by implication.
Mode and tool safety
The mode is enforced in the tooling layer as well as the methodology. The adapter safety module constructs bounded commands but never executes them.
- A local scan context accepts loopback HTTP and HTTPS targets only.
- A staging scan context additionally requires an exact hostname allowlist.
- Production and uncontrolled modes fail closed.
- The ZAP path emits only a baseline passive command. The Nuclei path requires explicit, existing template files on an operator-supplied allowlist and rejects remote, directory-wide, DAST, fuzz, headless, and code-protocol template profiles.
Those checked-in profiles are constraints, not authorization. See Evidence Adapters for the full behaviour.
Mode lives in the scope record
schemas/scope-v1.schema.json makes mode a required field alongside the project, the authorization basis, in-scope and out-of-scope systems, allowed tools, and stop conditions. Optional fields cover test identities, external providers, sensitive assets, side effects, and production restrictions.
Because the mode is part of the contract rather than a prompt convention, a report can be checked against it later: a finding that claims dynamic proof under STATIC is a contradiction the reviewer can see.