---
interpretation: strict
---

**Mandate:** The agent **MUST** verify exploitation stayed inside the engagement scope and rules of engagement at every step. Scope violations in this stage are the highest-severity class of finding the studio can produce — they shift liability, void engagement protections, and damage the relationship that lets the assessment happen at all. Strict-interpretation lens: when in doubt, flag.

## Check

The agent **MUST** verify, file feedback for any violation:

- **Targets in scope** — Every host, port, endpoint, and resource named in the attack plan, PoC, and execution log appears on the engagement's authorized-target list. Cross-check against the scope statement explicitly, not by memory.
- **Techniques permitted** — The technique class used at each step is permitted by ROE. Whole categories disallowed by ROE (denial-of-service-class, social-engineering-class, supply-chain pivots, third-party-property pivots) must not appear anywhere in the body.
- **Windows respected** — Every execution timestamp is inside an agreed window. Late-night / weekend / outside-business-hours probes that the engagement didn't authorize are violations even if no observable harm resulted.
- **No destruction** — No data was modified beyond canary-write proof-of-write values, no service was degraded beyond what the surrogate test predicted, no persistent change was left on the target. Cleanup was confirmed by observation, not just by command execution.
- **Evidence captured** — Every successful step has a request/response artifact, a hash, and a timestamp. Every step that aborted has the abort trigger and the cleanup confirmation. Missing evidence is a finding even on successful executions.
- **Methodology recorded** — The body documents the technique class, the steps taken, and the abort path with enough detail for a third party to follow what was done. "Trust me, the exploit worked" is not evidence.
- **Communication trail present** — On abort or unexpected behavior, the body shows the engagement lead was notified with timestamps and message excerpts.

## Common failure modes to look for

- A target host that appears in the execution log but not in the authorized-target list — sometimes a typo, sometimes a real scope slip
- Pivots through an in-scope asset to an out-of-scope asset (e.g., the in-scope web app is exploited, but the PoC reaches a database that wasn't named in scope)
- Time-window slips on multi-day engagements — a step run on day N+1 outside that day's agreed window
- Cleanup commands that were issued but not observation-confirmed — the artifact may still be on the target
- A PoC that demonstrates more than the success criterion required — gratuitous additional payloads, exploration beyond the named surface
- A captured response containing actual customer data values that weren't sanitized before commit
- An unplanned escalation (e.g., the operator gained admin access incidentally and didn't immediately abort to re-plan)
- Missing communication trail on an abort — the engagement lead may not have been told

## What to do when filing

Scope-compliance findings are **always** prioritized: file each one separately, name the exact step and timestamp, cite the ROE clause that was violated, and recommend the immediate remediation (e.g., "halt the unit, notify the engagement lead in <channel>, document the violation in the engagement log"). The fix loop's implementer (`exploit-developer` by default) may need to escalate findings of this class to the engagement lead before any further unit work continues.
