Plan → execute → reflect: execution-grounded confirmation

· methodology ·

Severity policy is one half of the stack. The other half is the research method: plan a probe, execute it under a safety envelope, then reflect with hard oracles. That loop lives in tcsf/exploit/confirmation_loop.py.

Safety before HTTP

  • TargetEnvironment.in_scope(url) — out-of-scope requests never leave
  • destructive_payload_blocked — research-mode write blocks (DROP / DELETE / …)
  • Planner / executor / reflector are separable stages — each can fail closed

Hard oracles in validate_exploit_impact

  • SQLi — syntax markers + boolean body-oracle vs baseline
  • XSS — payload reflection without HTML-encoding
  • BOLA / IDOR — validate_bola_response rejects generic nginx/404 bodies

Memory changes the next probe

Trajectory helpers (filter_fp_payloads, record_successful_probe, top_payloads_for_category) bias future attempts. Successful paths attach exploit_verified evidence via attach_exploit_verified_evidence. Unverified chains stay hypothesis or medium — the gate and the loop are one system.

Why this matters

Autonomous security research only earns trust when the runtime can refuse to overclaim. This note documents a shipped invariant in Nexus / TCSF — the kind of detail practitioners and search engines both need to evaluate the system honestly.

FAQ

What blocks a probe before HTTP?

TargetEnvironment.in_scope and destructive_payload_blocked — out-of-scope and research-mode write payloads never leave.

What counts as verified impact?

Hard oracles in validate_exploit_impact: SQLi markers + boolean body-oracle, XSS reflection without HTML-encoding, BOLA via validate_bola_response.

Further reading