OpenOSINT wraps 21 reconnaissance lookups behind an AI agent that chains tools on findings, built for authorized security research, threat intelligence and defensive exposure assessments.
| Tool | OpenOSINT/OpenOSINT — AI-powered OSINT agent exposing 21 investigation tools through a REPL, CLI, web UI and native MCP server |
| Category | OSINT / reconnaissance automation, Python, LLM agent |
| Primary Use | Authorized investigations of emails, usernames, domains and IPs using chained lookups such as search_breach, search_dns, search_shodan and search_github |
| Safe Use | Intended for legal, authorized use only — sanctioned assessments, threat-intelligence research, and monitoring of your own organization's external exposure, per the project's explicit disclaimer |
| Telemetry Note | Passive by default, but every third-party query (Shodan, HIBP, VirusTotal, Bright Data) is visible to those providers; active tools like scrape_url and search_username appear in target-side logs, WAF alerts and rate-limit responses |
OpenOSINT is a Python-based OSINT agent that puts twenty-one investigation tools behind a natural-language interface, shipwrecking the traditional problem of gluing together holehe, sherlock, sublist3r and a dozen REST APIs by hand. The agent takes a plain-language description of a target, decides which tools apply, executes them, and pivots on findings — the README shows a breach lookup on an email surfacing a GitHub handle, which the agent then investigates for commit-discovered emails. Crucially for an analyst's trust model, results come from real tool executions and every finding is displayed alongside the tool call that produced it, while AI summaries are explicitly framed as leads to verify rather than proof.
The project can be consumed four ways: an interactive REPL launched with openosint, a direct CLI for no-AI tool invocation like openosint email target@example.com, a browser-based Web UI with streaming output and tool cards, and a native MCP server registered as io.github.OpenOSINT/openosint in the official MCP registry. The MCP path is the architecturally interesting one: any MCP-compatible AI client can drive the tools directly, and the server runs under uvx --from openosint openosint-mcp with no separate installation. Installation for self-hosting is a one-liner, pip install openosint, with reportlab as an optional extra for PDF reports.
Three AI backends are supported: Anthropic Claude as the default, local Ollama, or any OpenAI-compatible endpoint through LiteLLM, vLLM, or LM Studio. This flexibility matters operationally — analysts handling sensitive engagements can point the agent at a fully local model, keeping target descriptions off third-party LLM providers entirely. Every REPL session is persisted to ~/.openosint/history/ and browsable via openosint history, and investigations auto-save Markdown and PDF reports into a reports/ directory with timestamps, which is a sensible paper trail for authorized work.
The tool inventory reads like a curated best-of OSINT tooling. search_email wraps holehe for social-account discovery, search_username wraps sherlock across 400+ platforms, search_breach hits the HaveIBeenPwned v3 API, search_whois and search_rdap cover registrant and registration data, and search_dns uses dnspython for record enumeration plus SPF, DMARC and DKIM analysis. Infrastructure intelligence is well represented: search_shodan, search_censys, search_virustotal, search_abuseipdb, search_ip2location (sponsored, adding VPN/Proxy/Tor flags) and search_ip via ipinfo.io. search_github queries the GitHub REST API for profiles, repos and commit-discovered emails, and generate_dorks builds twelve targeted Google dork URLs entirely locally.
What distinguishes OpenOSINT from a simple tool wrapper is its noise and safety model, documented with unusual rigor. The project is passive by default: agents and MCP clients are only offered tools that query third-party data sources or compute locally. Active tools are not merely refused when called — they are not offered to the model at all, and an MCP client never sees them in tools/list. Tools are classified on a five-level scale: passive, touches target, noisy, unverified, and inherits for fan-out tools like investigate_graph that route according to the current mode.
The classification table is generated by python -m openosint.tool_policy and states precisely what each tool sends and where — for example, generate_dorks builds search URLs locally and sends nothing, while scrape_url delegates fetching to Bright Data's Web Unlocker so the target's server logs a request from Bright Data's IP rather than yours. Noisy tools that are off by default include search_email, search_username, search_domain and search_phone, the latter marked unverified pending traffic-capture validation. This kind of honest, machine-generated transparency about network behavior is rare in OSINT tooling and gives defenders a real basis for understanding detection surface.
Opting into active tools is explicit and layered: openosint --allow-active at the CLI, OPENOSINT_ALLOW_ACTIVE=1 as an environment variable, a loopback-only toggle in the Web UI settings, or the flag on openosint-mcp. A publicly reachable or demo instance can never enable active tools regardless of configuration, and a disabled tool requested anyway returns a structured disabled_in_passive_mode result explaining how to enable it. Tool-call volume is also governed: OPENOSINT_MAX_TOOL_CALLS caps each request at 15 calls by default, investigate_multi shares a 30-call cap across targets, and hitting the cap stops the investigation with an explicit message rather than silently truncating results.
The README is equally candid that passive is not private. Every third-party service queried — Shodan, HIBP, VirusTotal, Bright Data — sees what was searched for and usually the API key or source IP. For blue-team practitioners this cuts both ways: it is a warning for operators running sensitive investigations, and simultaneously a detection and threat-hunting signal, since adversary use of OpenOSINT or its underlying libraries generates query patterns visible to those same intelligence providers and to WAFs and rate limiters on the target side.
Performance and workflow ergonomics are addressed through --parallel, which runs complementary tools concurrently via asyncio.gather() — a meaningful improvement when an investigation fans out across WHOIS, DNS and breach sources. The Web UI adds a genuinely analytical layer beyond chat: an interactive 3D globe where investigation results land as clickable points enabling pivot investigations, and an entity graph explorer built on a statement-based data model. The graph demo shows two Organization nodes observed independently by the openosint:github and openosint:whois datasets linked by a dashed same_as candidate edge scored 0.83, with a human review card comparing entities field by field — matching values in green, differing in amber — before an Accept merges them.
That entity-resolution workflow deserves emphasis because it addresses the core epistemic problem of automated OSINT: correlating observations from different sources without over-trusting the machine. Confidence-scored candidate edges, per-statement provenance with dataset, extractor, run id and confidence, and mandatory human review before graph mutation reflect an architecture designed for analyst-in-the-loop verification rather than autonomous conclusion-drawing. The demo data is explicitly synthetic and regenerable via demo/web_demo.py, which is good hygiene for a security project's public artifacts.
Beyond the self-hosted core, the project offers a hosted companion, OpenOSINT Monitor, performing weekly external checks of a domain's SPF/DKIM/DMARC posture, TLS, security headers and lookalike domains, ownership-verified and free for one domain. That defensive monitoring angle aligns with the tool's legitimate center of gravity: measuring your own organization's external exposure, researching threat actors' infrastructure, and supporting authorized engagements. The repo carries an MIT license, sits at roughly 1.5k stars, publishes on PyPI, and includes a legal disclaimer stating the tool is for legal and authorized use only, with users solely responsible for compliance.
For practitioners evaluating fit, OpenOSINT lands somewhere between an OSINT framework like SpiderFoot and a raw MCP tool server, with the agent-chaining layer and the passive-by-default policy model as its differentiators. Watch items include the reliance on third-party API keys for Shodan, Censys, VirusTotal, AbuseIPDB and Bright Data, the unverified status of some tools' network behavior, and the fact that the AI backend sees your target descriptions unless you run Ollama locally. Within an authorized scope — your own domains, sanctioned assessments, threat research — it is a well-instrumented and unusually transparent addition to the reconnaissance toolkit.
OpenOSINT/OpenOSINT.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.