# AI-assisted bug bounty work: keep scope, execution and evidence under researcher control Canonical: https://www.web3sec.news/blog/ai-assisted-bug-bounty-workflow Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Authorized security research Published: 2026-11-08 Updated: 2026-11-08 Use agents for understanding and reproducible reporting while preserving program authorization, data boundaries and meaningful human validation. ## The short answer Use an agent to develop hypotheses and prepare reproducible evidence within a program’s current written scope. The researcher remains accountable for generated requests, target selection and disclosure. Validate locally first, review scripts before execution, use authorized test accounts and stop after minimal sufficient evidence. Keep private program data out of unapproved services. ### Diagram: Investigate untrusted code in an isolated place. Keep research environments disposable and separate from host identity. ![An untrusted repository enters a disposable sandbox with no host secrets, no writable host mounts, and restricted egress. Only reviewed findings leave the sandbox; running a repository is not a reason to expose credentials.](https://www.web3sec.news/diagrams/research-sandbox.svg) [Full-size SVG](https://www.web3sec.news/diagrams/research-sandbox.svg) · [PNG download](https://www.web3sec.news/diagrams/research-sandbox.png) Original explanatory control model; not a reconstruction of private incident evidence. ## 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. ### Diagram: Content is evidence. Approval is authority. Keep source material separate from the authority to act. ![Sources enter a working context and produce a proposal. A separate approval gate checks scope before a tool action. Untrusted content cannot authorize execution.](https://www.web3sec.news/diagrams/trust-boundary.svg) [Full-size SVG](https://www.web3sec.news/diagrams/trust-boundary.svg) · [PNG download](https://www.web3sec.news/diagrams/trust-boundary.png) Original explanatory control model; not a reconstruction of private incident evidence. ## 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 Local planning worksheets; they do not inspect or change accounts or environments. - [Prepare the research environment](https://www.web3sec.news/tools/research-preflight): Check authorization, source, credentials, egress and disposal for the actual lab boundary you will use. - [Build a permission review plan](https://www.web3sec.news/tools/agent-permissions): Select the capabilities you are considering and review approvals, revocation and evidence before connecting an agent. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Record current assets, prohibited techniques and program reporting rules. - [ ] Constrain targets and rate limits outside retrieved content. - [ ] Review generated code and reproduce hypotheses locally first. - [ ] Use controlled accounts and stop after minimal sufficient evidence. - [ ] Redact and independently reproduce the final report before submission. ## 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 - [HackerOne: safe harbor overview and scope distinction](https://docs.hackerone.com/en/articles/8494502-safe-harbor-overview-faq) - [HackerOne: submitting reproducible vulnerability reports](https://docs.hackerone.com/en/articles/8473994-submitting-reports) - [Bugcrowd: researcher code of conduct](https://www.bugcrowd.com/resources/hacker-resources/code-of-conduct/) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)