Why automate recon and testing on the NotHoly API

A recon run produces more than you can read: subdomains, endpoints, headers, versions, a wall of tool output. The slow part is triage, deciding what is worth a closer look. A model in the loop helps there, but only if it does not refuse the security context and if the supporting data does not turn every lookup into a bill. The NotHoly API gives you both. This piece is about wiring it in, not about recon method; the bug bounty use case covers the workflow itself.

#The model reads, your code touches

Keep the line clear. The model reasons over output you already have: it reads a scan, ranks what looks reachable, drafts the next step, writes the parser you were about to write. NotHoly's servers never scan, probe or send a payload to a target. The active part, the request to the host in scope, runs in your environment, from your address, under your control. That division is the point. You get a model that will discuss the finding without arguing about whether it is allowed, and the traffic to the target stays yours to run and to log. Tool results you feed back are treated as data, not instructions, so a hostile banner in a scan does not steer the run. When you run the active step from the terminal, notholy engage can record the scope and check each command against it before it runs, and nothing about that scope leaves your machine.

#Data that does not cost tokens

The Research API answers the lookups a recon loop makes constantly, and it is rate-limited per organization rather than metered per token. GET /v1/cve/{id} and GET /v1/cve/search return the NVD description, CVSS, CWE, EPSS score and CISA KEV status in one record, each source dated. POST /v1/advisories/query returns what OSV lists for a package and version. GET /v1/kb/search reads a curated, licensed knowledge base with a source and licence on every passage. POST /v1/web/search and POST /v1/web/read search and read public pages through an egress that refuses private and internal addresses, pins the connection to a checked IP and never sends traffic to a target. Results from NVD, CISA, GitHub, PortSwigger and OWASP rank first, and a page can be wrong, so open the source before you act. A CVE enrichment or a version check does not spend model tokens.

curl "https://api.notholy.com/v1/cve/search?q=openssh&kev=true&min_epss=0.5" \
  -H "Authorization: Bearer $NOTHOLY_API_KEY"

#Wire it into the pipeline

The model endpoint is OpenAI- and Anthropic-compatible, so your orchestration code, your function tools and your streaming stay as they are. Pass the model your own tools, let it call them, and run them yourself: the server runs only the functions you send. Reasoning and max_tokens carry through, so a triage step can think before it ranks. A non-streaming request with an Idempotency-Key can be retried and replayed for up to 24 hours, which helps a pipeline that re-runs a step. POST /v1/messages/count_tokens sizes a prompt before you spend. Function calling has the request shape, and the model ID comes from the catalog. Because the research routes cost no tokens, you can enrich a whole queue of findings and spend only on the reasoning that ranks them.

#Where it does not fit

It does not fit if you want the platform to run the scan. It will not. There is no server-side execution and no active tooling, and read_url opens only public pages, not an internal host or a link it found on a page. The model can rank a false positive first or miss a real one, so a ranked list is a queue to check, not a verdict. The research routes are capped per minute per organization, which is plenty for a pipeline and short of a bulk crawler. Prompts and responses to the model are not stored, though the metadata of each call is.

Let your scanners do the scanning and the model do the reading. Put a key and a small balance on pricing, and point your pipeline's triage step at the API.