AI agents for security
Why automate recon and testing on the NotHoly API
Put a model that does not refuse in your pipeline, with CVE, advisory and public-page reads that do not cost tokens. Your tools do the active work.
Turn scattered recon into structured notes, an entity graph and a timeline for a scope you own, and let the NotHoly chat summarise and spot gaps.
Collection produces mess: a file per tool, subdomains, URLs, emails, screenshots. Organising turns that into something you can reason over and hand off. Three structures do most of the work: a notes file with one fact per line and its source, an entity graph that links hosts, people and IPs, and a timeline that orders events. The NotHoly chat reads all three and writes the summary, and more usefully, it tells you what is missing.
Keep a single notes file in plain text or Markdown. Each line is a claim and where it came from.
api-dev.example.com 200 nginx source: httpx 2026-11-10
[email protected] in breach "AcmeLeak" source: hibp 2026-11-10
origin 203.0.113.7 behind CDN source: dns-history 2026-11-09Plain text diffs, greps and survives a tool changing its output format. A finding with no source line is a rumour, so do not promote it into the report until you can name where it came from.
A graph answers what connects to what. Nodes are hosts, IPs, people, emails and orgs, and edges are relations like resolves-to, owns and works-at. Maltego is the classic graphing tool, and recon-ng stores entities in a workspace database you can query and export. Even a two-column list of source and target, loaded into any graph viewer, shows clusters a flat list hides, such as the one IP that ties five apparently unrelated hosts together.
Some findings are events: a certificate issued, a domain registered, a commit pushed, a breach dated. Order them. A timeline shows that the staging host appeared the same week as the leaked config, or that an employee's public repo predates the service it names. Keep it as a simple dated list, because the order is the insight, not the formatting.
This is where the AI earns its place. Paste your notes, your edge list and your timeline, and ask for both a summary and a gap list.
Here are my OSINT notes, an entity edge list, and a timeline.
Write a one-page summary grouped by asset. Then list the gaps:
entities with only one source, hosts with no owner, and the
three checks that would most reduce my uncertainty.A summary is easy; the gap list is the point. The model flags the single-sourced claims, the dangling nodes and the obvious next checks, which is the review a tired analyst skips. It reasons over what you pasted and invents no new facts, so verify any "likely" it offers before you write it down.
Structure does not loosen the rules. Keep personal data such as emails, breach records and names in a separate, encrypted file, and keep it out of the graph image you drop into a report. Label every entity with whether it is in scope, so an out-of-scope node you found while pivoting never slides into the findings.
No. A Markdown notes file, a two-column edge list and a dated timeline cover most engagements. Reach for a graph tool when the entity count gets past what you can hold in your head.
Treat it as stateless for this. Keep the source of truth in your own files, paste what you need, and save the output back to your notes. Your files, not the chat, are the record.
With everything structured, the last step is the deliverable. Turn it into a report in turning OSINT into a clean report. Back to image and geolocation OSINT basics.
AI agents for security
Put a model that does not refuse in your pipeline, with CVE, advisory and public-page reads that do not cost tokens. Your tools do the active work.
AI agents for security
The design of a small bug bounty agent: an LLM, a set of tools, memory, and guardrails, wired into a loop that runs on your machine under your approval.
AI agents for security
A small Python bug bounty agent with tool calling on the NotHoly API: it proposes recon commands, waits for your approval, reads output, and keeps notes.