---
name: exploitation
description: Controlled exploitation of discovered vulnerabilities with proper scoping and authorization
hats: [attack-strategist, exploit-developer, exploit-reviewer, attack-operator, verifier]
fix_hats: [classifier, exploit-developer, feedback-assessor]
review: ask
elaboration: collaborative
inputs:
  - stage: enumeration
    discovery: vulnerability-catalog
outputs:
  - discovery: access-log
    hat: attack-operator
---

# Exploitation

Controlled exploitation of discovered vulnerabilities with proper scoping and authorization. Units are **attack surfaces** (per ARCHITECTURE.md §2.2 adversarial/security role): one unit per surface from the upstream vulnerability catalog that the strategy chain selected for proof-of-concept work.

## Per-unit baton

This stage uses the architecture §3.5 pattern: plan-do-verify front loop FOLLOWED BY an adversarial-operator step, then a terminal verify.

- **`attack-strategist`** (plan): chooses which vulnerabilities on this surface to attempt, in what order, with what success criteria. Confirms every step is in scope before the developer touches code.
- **`exploit-developer`** (do): translates the strategy into a controlled PoC — safe defaults, rate limits, kill switches, rollback steps, pre-flight checks. Tests against a local/staging surrogate before the operator goes near production.
- **`exploit-reviewer`** (verify): body-only review of the PoC — does it match the plan, is it scope-safe, are safety constraints concrete, was it test-driven against a surrogate?
- **`attack-operator`** (adversarial-do): executes the PoC against the authorized target inside the agreed time window, logs every action with timestamps, aborts on unintended effects.
- **`verifier`** (adversarial-verify): terminal validator — was scope respected, was evidence captured, was no destruction caused?

The baton: surface assessment → attack plan → reviewed PoC → execution log → validated outcome.

## Inputs and outputs

Consumes `enumeration/vulnerability-catalog`. Produces `ACCESS-LOG.md` per unit, which feeds post-exploitation.

## Fix loop and gate

`fix_hats: [classifier, exploit-developer, feedback-assessor]` — the implementer hat is `exploit-developer` because most findings here ask for a safer PoC, a tighter pre-flight, or a missing rollback. Gate is `ask` because a human MUST sign off before any exploit attempt against a real target.
