Turn the program policy into an execution boundary
The researcher remains responsible for the work performed by an assistant. Before testing, read the current program policy and record the exact assets, eligible accounts, prohibited techniques, request limits, disclosure terms and reporting channel. HackerOne’s safe-harbor guidance explicitly distinguishes its protections from asset scope. A program’s existence or a security contact does not automatically authorize testing every related domain or third-party integration.
Create a task-specific target list and keep it outside material retrieved from the target. Require explicit review before an agent follows redirects to a new service, adds a discovered host or uses credentials from a response. Apply network restrictions and rate controls in the execution environment when feasible. If authorization is ambiguous, continue local analysis and ask the program through its designated channel before the dependent live activity.
Use local reasoning before touching a live service
Agents can help map an authorized codebase, identify state transitions, compare access rules and prepare synthetic test cases. Treat their findings as hypotheses. Reproduce the important behavior in a local or program-provided test environment using controlled accounts. A plausible code explanation or scanner label is not evidence that the deployed target is affected, reachable or within the allowed test conditions.
Review generated scripts before execution, including dependencies, request destinations, concurrency, payload size, filesystem access and cleanup. Keep research code in a disposable environment without unrelated cloud, wallet or publishing credentials. Do not let an agent execute a repository’s setup instructions on the everyday laptop solely because the repository is linked from a report. Test fixtures and installation hooks can carry the same risks as the suspected exploit code.
Demonstrate the minimum impact needed
Use your own authorized test accounts and synthetic records to demonstrate an access-boundary failure. Define stop conditions before the request: unexpected third-party data, a service-health change or an action beyond the permitted proof. Stop at the first sufficient evidence and report through the agreed channel. Do not expand a small successful check into broad data extraction merely to make the report appear more convincing.
Keep private-program details, customer identifiers, session tokens and sensitive responses out of unapproved model services and public artifacts. Check program rules on AI tools and data handling; Bugcrowd’s conduct requirements emphasize responsibility, confidentiality and program-specific disclosure terms. Give an assistant redacted or synthetic evidence where possible, and review screenshots, recordings and attached archives for accidental credential exposure before submission.
Keep source material separate from the authority to act.
Original Web3Sec diagram. On small screens, scroll the figure or open the full-size version.
Report verified behavior and retain reproducibility
HackerOne’s reporting guidance asks for the vulnerability, reproduction steps and demonstrated impact. Write a concise report identifying the affected in-scope asset, account roles, prerequisites, exact safe steps, observed result and expected boundary. Separate what you reproduced from a possible broader consequence. Include the minimal relevant request and response or local test, with secrets removed and evidence attached through the program’s approved mechanism.
Have another trusted reviewer or a clean test session follow the report without relying on the agent’s hidden context. Confirm that steps are accurate, cleanup is complete and no generated claim exceeds the evidence. Preserve the tested revision, tool versions and restricted evidence while the report is active. Recheck scope before retesting a fix, and obtain the required permission before publishing any write-up or sharing private-program material.
Controls to take away
- The researcher is accountable for agent-generated requests and claims.
- A discovery or redirect does not expand program authorization.
- A strong report distinguishes reproduced impact from speculation.
Work through the boundary.
These local worksheets turn the review questions into a plan. They do not inspect or change the actual account or environment.
Prepare the research environment ↗
Check authorization, source, credentials, egress and disposal for the actual lab boundary you will use.
Build a permission review plan ↗
Select the capabilities you are considering and review approvals, revocation and evidence before connecting an agent.
Take this to your next review
Working checklist
Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.
0 of 5 reviewed
Common questions
Can an agent follow a discovered host outside the original target list?
Discovery does not expand authorization. Check the current program policy and obtain clarification before testing a new asset or third-party integration when its inclusion is uncertain.
Is an AI-generated vulnerability explanation sufficient evidence?
No. Treat it as a hypothesis and reproduce the behavior through authorized tests. Report the affected asset, prerequisites, exact steps and demonstrated impact, separating possible broader consequences from observations.
Can private vulnerability evidence be sent to any AI service for drafting?
Check the program’s tool-use and confidentiality rules first. Prefer redacted or synthetic material, review generated attachments and use the approved reporting channel for sensitive evidence.
Sources & further reading
The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.
A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.