Why use NotHoly for OSINT

OSINT is two jobs: collecting what is public, and making sense of it. The collection is a pile of pages, certificates, repositories and handles. The sense-making, deciding what connects to what and what matters, is where a model helps, if it takes the question and reads the page itself instead of waiting for you to paste it. A general model stalls on parts of this work. NotHoly reasons over what you gathered and does the passive collection through tools that only read. Abliteration is why it does not stall.

#The model reasons over what you collect

Hand it a list of subdomains, a set of profiles, a dump of certificate data or a repository's history, and it groups, correlates and summarizes: which host looks like staging, which account ties to which, what a commit message gives away. It drafts the next search and writes the note. Because the model does not refuse, mapping an organization's public footprint for a job you are scoped for is read like any other data. Reasoning carries through, so a chain of weak signals is weighed before a conclusion is drawn. The same conversation holds the whole trail, so a connection you drew an hour ago is still there when the next page confirms it. The output is a lead to confirm, not a fact, which is the right way to treat any correlation. The knowledge base also carries documentation for the recon tooling you run, from subdomain enumeration to crawling, so a flag or an output format is one lookup away rather than a trip to a wiki, and the source stays attached to the answer.

#Passive collection, built in

The tools only read. Web search returns titles, URLs and excerpts, with security sources ranked first and identical queries cached briefly. The page reader fetches one public page at a time through an egress that checks every address and redirect, pins the connection to the checked IP, honors robots.txt and refuses private and internal addresses, IP literals and exposed-file paths. When you explicitly ask for it, a dark web search queries indexes of Tor hidden services and returns titles, .onion URLs and snippets, without opening the listed pages and with a filter that drops abuse material. None of this sends active traffic to a target. How search and sources work has the detail.

curl -X POST https://api.notholy.com/v1/web/search \
  -H "Authorization: Bearer $NOTHOLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "acme.com subdomains certificate transparency"}'

#From the terminal and your scripts

The same search and reasoning run from the CLI and over MCP, so a collection script passes a file to the model and gets back a grouped, annotated read. The research routes are not billed per token, so pulling and correlating a large set costs only the reasoning. Results come back as structured data with --json, so a pipeline stores them and the model reads them back later, and an MCP client on another model can still call NotHoly's search and knowledge base.

cat subdomains.txt | notholy "group these by likely purpose and flag anything that looks like staging or admin"

#Where it does not fit

It reads public pages only. The page reader will not open an authenticated page, a link it found inside a page or a .onion, and it caps how many paths it fetches from one host, so it is a reader, not a crawler. The dark web results are unverified leads from an index, not visited pages. It is not a people-search engine or a data broker, and the lawful, in-scope use of what you find is yours to ensure. The model can invent a connection, so verify before it goes in a report. The account needs an e-mail, and a saved chat keeps its history unless you make it ephemeral.

Let the tools read what is public and the model make sense of it. Add a small balance on pricing, and point it at a footprint you are scoped to map.