The bug bounty toolkit and the NotHoly CLI

You do not need a large toolkit to start. You need a browser, a proxy, a terminal, and a place to keep notes and evidence. This post sets up that short list and puts an AI model where it helps most: in the terminal, reading output and proposing the next step, while every command runs on your machine under your approval. It follows choosing a program and leads into reading JavaScript with AI.

#The short list

A browser and its dev tools cover a surprising amount of early work. A proxy such as mitmproxy lets you watch and edit traffic between the browser and the target. The terminal is where the agent and the scanners live. Notes are where a finding becomes a report.

#The NotHoly CLI in the terminal

The NotHoly CLI runs an agent in your project. It can read and search files, run a command, and call remote research tools, and by default it asks before every write and every command. Install it and sign in once.

curl -fsSL https://notholy.com/install.sh | sh
notholy login
notholy --version

Run it inside a working directory for the program. In ask mode, the default, the agent proposes a command and waits for your yes. In plan mode it only reads. Start in plan mode while you learn the app.

notholy --mode plan -p "list the hosts and endpoints you can find in these notes"

The model never reaches a target from NotHoly's side. Commands run locally, from your address, with your approval. That is the property you want for bug bounty: the traffic comes from where the program expects it, and you can log every request.

#Record the scope with notholy engage

Before you test, record what the program lets you touch. notholy engage holds the scope for the run and checks the target of each command against it.

notholy engage init --name acme-web --scope "*.example.com,api.example.com" --exclude vpn.example.com --until 2026-12-31
notholy engage status

With an engagement active, the agent reads the host out of each command before it runs. An in-scope target goes through the normal approval. An out-of-scope target makes you type the host yourself, and the override is written to a local log. The check reads command text and does not resolve DNS, so it catches your mistakes and is no sandbox. It turns the scope from something you have to remember into something the terminal checks.

#A proxy to see every request

Point your browser at a local proxy and you can read, pause, edit, and replay every request. This is where most web testing happens. When a response looks odd, copy the raw request and ask the model what it means and what to change next. You run the changed request through the proxy yourself. The proxy also gives you the exact request and response text that a report needs as evidence.

#Keep notes and evidence from the first request

Open a notes file per program before you touch anything. For each lead, save the request, the response, the time, and what you expected versus what you saw. The model can draft from these notes later, and good notes are the difference between a report that pays and one the triager cannot reproduce. Keep evidence out of any public repository, and keep client or program data off shared services.

#A quick home lab

Run the app, or a demo build of it, on your own machine so you can learn its behavior without sending traffic to the live target for every question. How to build a legal home lab sets up an isolated environment for exactly this.

#Next in this track

With the terminal, the proxy, and the scope in place, move to reading JavaScript with AI to find endpoints. The OWASP Web Security Testing Guide is the reference for what to test once you have mapped the surface.