Bug bounty with an AI co-pilot: the loop

Bug bounty is paid testing inside the boundaries a program sets. This track takes you from nothing to a first valid report, with an AI model doing the reading and the drafting while you keep the judgement and run anything that reaches a target. This first post is the loop you repeat on every program. The rest of the track goes deep on each stage and then builds a small agent that runs part of the loop for you.

A model is a fast reader and a decent writer with no memory of your scope and no stake in your account. It will summarize a policy, sort a list of endpoints, explain a strange response, and draft a report. It will also invent an endpoint, misread a status code, and sound certain while doing it. You treat its output as a lead, never as a finding.

#The loop

The work is a loop of five stages. You run it once on a program, then again on the next asset, then again on the next bug class. The model helps at each stage. It does not decide what is in scope, and it does not send a request to a target for you.

Stage	What you do	Where the model helps
Pick	Choose a program and an asset	Summarize the policy, flag odd clauses
Scope	Read what is in and what is out	Turn a long policy into a short checklist
Recon	Map the surface you may touch	Sort endpoints, read JS, suggest parameters
Test	Send requests and read responses	Explain a response, propose the next case
Report	Write it up	Draft the steps while you verify each line

#Pick a program and read the scope

A program is a public offer to test named assets under named rules. Before anything else you read the policy end to end: the domains and apps in scope, the ones out of scope, the classes it does not reward, and the limits on rate and automation. Paste the policy into a chat and ask the model to list in-scope hosts, out-of-scope hosts, and any rule that would get a report closed. Then read the policy yourself, because a wrong summary here is the kind of mistake that ends an account. Choosing your first program covers how to read a scope in detail.

#Recon without touching out-of-scope hosts

Recon maps the surface the program lets you test. You collect subdomains, endpoints, and parameters, then decide where a bug is likely. The model is useful for reading, not for reaching out: it can group a messy endpoint list, read a minified JavaScript bundle, and point at parameters worth testing. Keep every scan and request on the hosts the scope lists. For the tooling, the toolkit post sets up a terminal that keeps you inside scope.

#Test, then verify before you believe it

Testing is where beginners lose time to false positives. The model will say a response looks like an IDOR or an XSS. Sometimes it is right. You confirm by hand: reproduce the request, change one thing, watch the response, and keep the exact request and response that prove it. A bug you cannot reproduce on demand is not a bug yet. Testing common web bugs with AI help walks through IDOR, XSS, SSRF, and broken auth, including how to avoid the false positives the model hands you.

#Write the report

A report has to let a stranger reproduce the bug and understand the impact. The model drafts well from your notes: give it the request, the response, and the effect, and it will produce a clean writeup. You then verify every step, every URL, and every claim about impact, because the triager will. Writing reports that get paid has the structure and the review checklist.

#What the model is good at, and where it lies

Models read fast, translate jargon, and keep a tired brain moving at two in the morning. They also hallucinate endpoints, overstate severity to sound helpful, and mix up similar CVEs. The OWASP Top 10 for LLM Applications catalogs these failure modes. The rule that keeps you safe is simple: the model proposes, you dispose. Nothing it writes reaches a program until you have reproduced it.

#Next in this track

Read how to choose your first program, then set up the toolkit and the terminal. The bug bounty use case and the OWASP Web Security Testing Guide are the two references worth keeping open the whole time. The later posts build a hackbot that runs recon and testing on your machine, under your approval, using the NotHoly CLI.