Why use NotHoly for bug bounty

A bug bounty runs in a loop: recon, triage, a proof of concept, a report a triager can reproduce. Two things slow it down. A general model refuses to write the proof of concept for a program that pays for exactly that, and every enrichment lookup adds to a bill. NotHoly removes both. The model takes the loop, the research data costs no tokens, and the CLI keeps the work on your machine and inside the program's scope. The bug bounty use case has the methodology; this is about why the tool fits the loop.

#The loop, without the refusal

The model reads your recon output and ranks what looks reachable, explains a response that smells like an IDOR or an SSRF, and writes the proof of concept for the endpoint you are allowed to test. It does not stop to weigh whether the request is permitted, because the program's scope already answered that. With reasoning on, a triage step works through a chain before it ranks, and the same model drafts the request that tests the next hop. For a web target it reads a JavaScript bundle you paste; for a mobile target you attach the APK and get the manifest and the strings. The knowledge base brings OWASP testing methodology and payload references with a source on each passage, so a technique comes with somewhere to check it. Because the model is abliterated, a working proof of concept for an in-scope endpoint comes back as code, not as a refusal, and you can iterate on it in the same conversation until a triager could run it.

#Stay inside the program's scope

A program gives you a scope and rules, and notholy engage turns them into a guard. You record the in-scope hosts and wildcards and point --auth at the program page, and every command the agent runs is checked against that scope first. An out-of-scope host makes you type it and logs the override, so an accidental hit on a sibling domain that is not in the program is caught before it leaves your machine. The rules live outside the repo, so a target's own files cannot widen your scope. The log is a chained log.jsonl, a tamper-evident record of what you touched and when, which is the record a program or a dispute asks for.

notholy engage init --name acme-bbp --scope "*.acme.com,api.acme.com" --auth "https://hackerone.com/acme"

#From a finding to a report

A finding is paid only when a triager can reproduce it. Pipe your notes and the request into the model and ask for a write-up with impact, steps and a suggested fix, in the format the program wants. The CLI reads standard input, so a note file, a HAR export or a diff feeds it directly, and --json on a lookup returns structured data your scripts can parse. Enrich the report with a CVE lookup that carries CVSS, EPSS and KEV, and an advisory query for the dependency you suspect, neither of which costs tokens. Prepaid per-token pricing fits a hunt that runs hot for a weekend and quiet for a month, because you pay for the weekend.

cat finding.md | notholy "turn this into a reproducible report with impact, steps and a suggested fix"

#Where it does not fit

The active testing is yours. NotHoly's servers never scan or send traffic to a target, so the requests to the program come from your tools, on your machine. Whether a finding is in scope, valid, or a duplicate is the program's call, not the model's, and the model can be wrong, so reproduce the proof of concept yourself before you submit. The account needs an e-mail, and the chat keeps your conversations unless you open an ephemeral one.

Keep the requests on your machine and let the model carry the reading and the writing. Install the CLI, add a small balance on pricing, and run a target you already have scope for.