Scope discipline
Only test what the program explicitly authorizes
Operate only within the approved in-scope assets, URL patterns, and authorized testing windows defined by the program. Scope violations — even accidental ones — can result in program bans, legal exposure, and damage to the broader security research community.
DO
- Import scope from the program's official HackerOne or Bugcrowd scope definition
- Verify wildcard scope coverage before starting any subdomain recon
- Re-confirm scope on every new hunt session in case it has changed
- Stop immediately and flag if the agent reaches an asset not clearly in scope
DO NOT
- Do not assume a subdomain is in scope because the parent domain is
- Do not test assets that are in scope for another program you are not registered for
- Do not modify the scope policy mid-session to expand coverage without proper review
Reproducibility
If you cannot reproduce it, do not submit it
Triage teams hold AI-assisted submissions to the same standard as manual reports — sometimes higher, because reviewers are increasingly skeptical of AI-generated output. A finding without a working reproduction path is not a finding. The ValidationAgent enforces this before you see output, but you are responsible for reviewing the evidence chain before submission.
DO
- Review the full HTTP evidence bundle (request, response, diff) before every submission
- Verify the curl command runs successfully against the live target before submitting
- Confirm the reproduction still works at submission time, not just at detection time
- Include your test environment details if they affect reproducibility
DO NOT
- Do not submit a PENDING finding — wait for CONFIRMED status
- Do not submit without verifying the target has not been patched since detection
- Do not clean up evidence artifacts before submission — include the full chain
Target stability
Never disrupt the target application
Bug bounty testing must not create lasting impact on the target system. Denial-of-service patterns, destructive write operations, user data exposure beyond what is required to demonstrate impact, and any action that affects the target's other users are not acceptable — regardless of whether they are within scope.
DO
- Use test accounts created for bounty testing, not real user accounts
- Rate-limit hunt intensity if you notice response degradation on the target
- Use the pause control to stop the hunt if unexpected side effects appear
- Report unintended disruption to the program immediately, even if in scope
DO NOT
- Do not attempt DoS or load testing of any kind
- Do not exfiltrate real user data beyond what is needed to demonstrate the finding
- Do not modify or delete production data outside a controlled test environment
Coordinated disclosure
Work with the program, not against it
Responsible disclosure means giving the organization time to fix the issue before it becomes public. Most programs specify their disclosure policy — typically 90 days for critical findings. Follow the program timeline. If you disagree with a triage decision, escalate through the platform's appeal process, not by going public.
DO
- Follow the program's stated disclosure timeline precisely
- Communicate clearly with the triage team if you need clarification
- Use the program's official submission channel — not social media DMs
- Give the organization time to patch before posting any public writeup
DO NOT
- Do not publish a writeup before the program confirms the fix is deployed
- Do not contact the company directly outside the bounty platform unless instructed
- Do not threaten public disclosure to pressure faster triage decisions
