[Discussion] Safety rails for parallel pentest — throttling, opt-in techniques, kill-switch?

Context

--pentest-technique + --pentest-workers can hit 32 hosts concurrently across 5 techniques (SMB null session, LDAP anonymous bind, RPC probe, SMTP VRFY, Kerberos probe). Fast, but potentially:

• Triggers IDS/EDR at unrealistic-for-manual-testing rates
• Overloads small labs or shared authorization scopes
• Produces log volume the blue team was not warned about

Question

Do we need additional safety rails beyond --scope-confirmed?

Options to weigh

1. Rate limiting — per-host QPS cap, jitter between attempts. Config knob or default?
2. Technique opt-in — require explicit --pentest-technique smb-null-session,ldap-anon rather than all. Prevents accidental Kerberos-probe storms.
3. Global kill-switch — Ctrl+C should abort in-flight workers cleanly and emit a partial-results JSON, not lose everything.
4. Dry-run parity — every technique must produce identical output structure in dry-run vs active, so operators can preview before firing.
5. Attribution header — inject a User-Agent/comment string identifying the operator (from CLI flag) so blue teams can filter noise during authorized exercises.

Non-goals

• Blocking legitimate red-team engagements
• Changing which techniques are available

Opinions on which of these are must-have vs nice-to-have?

Start by reviewing the CLI paths for --pentest-technique, --pentest-workers, --scope-confirmed, and dry-run, then trace how the five listed techniques are dispatched. Resolve which safety rails are required before identifying the affected worker, cancellation, output, and attribution code; done means an agreed scope and acceptance criteria, not just an implementation choice.