OpenOSINT: an LLM front end for 20 OSINT tools, with a hard-stop execution model
AI-powered OSINT agent with interactive REPL, MCP server, and CLI. 19 tools. Works with Claude, GPT-4, or local models. For authorized security research only.
At a glance
- What is it?
- OpenOSINT wraps classic reconnaissance utilities (holehe, maigret, sherlock and others) behind a natural-language agent that runs as a REPL, CLI, MCP server or web UI. Its selling point is that the model never invents output: it emits tool calls and your machine runs the binary.
- Who is it for?
- Adopt OpenOSINT if you already know which OSINT utilities you want and would rather describe a target in a sentence than remember a dozen flag combinations, and if you are comfortable running third-party reconnaissance binaries on your own host. Skip it if you need a reproducible, scriptable pipeline with pinned tool versions, or if your environment forbids the outbound traffic these tools generate.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap OpenOSINT fills: one prompt instead of twenty flag sets
Classic OSINT work is a chain of small binaries. You run one tool against an email address, read the output, decide the next target, run a different tool against it. Each tool has its own flags, its own output format, and its own idea of what a username looks like. The README frames OpenOSINT as an agent that puts 20 investigation tools behind a natural-language interface, so the operator describes the goal and the agent decides which binary to invoke. The intended users are named explicitly: security researchers and analysts. That framing matters, because the tool is not a scanner you point at a network. It is an orchestration layer over identity and infrastructure lookups, and the repository states it is for authorized security research only. If you have never run holehe or sherlock by hand, the agent's tool selection will be opaque to you, and you will not be able to tell a genuine empty result from a misconfigured one.
How the agent avoids hallucinated findings
The design claim in the README is specific: the AI issues hard-stop tool calls and your code executes the real binary, which the project says makes hallucinated findings structurally impossible. Read that as an architecture statement rather than a guarantee about accuracy. The model's job is to choose a tool and fill in its arguments. The execution layer, running locally in Python, invokes the actual utility and returns its real output. A model that invents a plausible-looking email registration therefore produces nothing, because no binary ran. What this does not protect against is a bad target, a rate-limited lookup that returns an empty set, or a tool whose upstream site changed its response format. The structural guarantee covers fabrication, not correctness. The repository also ships a web layer: results land on an interactive 3D globe, and clicking a point pivots into a follow-up investigation. A separate graph explorer shows entities from different datasets linked by candidate same_as edges with a confidence score, and a human review card where a reviewer accepts or rejects the match. The demo GIF is explicitly labelled synthetic and deterministic, and the demo README notes the entities are seeded at the statement layer rather than produced by the current mappers. That is an unusually honest disclosure, and it also tells you the entity-resolution path is newer than the collection path.
Installing and running it: the commands the README gives
Installation is a single pip command: pip install openosint. Three entry points are documented. Running openosint with no arguments starts the interactive AI REPL, which the README calls the default. openosint web starts a browser interface. openosint email target@example.com runs a direct tool with no AI in the loop, which is the mode to reach for when you already know the tool and want a predictable result. For editor and desktop-client integration, the repository publishes an MCP server under the name io.github.OpenOSINT/openosint, and the README carries an mcp-name field with that identifier. The model backend is selectable: the description states it works with Claude, GPT-4, or local models, so an air-gapped or privacy-sensitive setup can keep inference on the same machine as the binaries. The README does not, in the portion available, spell out the environment variable names for API keys or the model selection flag, so treat configuration discovery as the first thing to check in the docs directory rather than guessing at variable names.
The sponsor-backed tools are the fragile part
Two of the advertised integrations are commercial services rather than open utilities. IP2Location.io powers the search_ip2location tool and provides IP geolocation, ISP data, VPN, proxy and Tor detection, and datacenter classification. RapidProxy supplies residential proxies for data collection. Both are marked as sponsored in the README, and both have integration guides under docs/integrations. This is a normal funding model for a project with this dependency profile, and it is disclosed rather than hidden. The practical consequence is that a tool in the agent's list can fail for a billing reason rather than a technical one. When the agent picks search_ip2location and the key is absent or exhausted, the failure surfaces mid-investigation, and the agent has no way to know the difference between no data and no quota. If your workflow depends on IP enrichment, test that path first. The README also lists Breach and Compromised-Credential data and Email and Identity Lookup as open sponsorship slots, which suggests the set of paid dependencies may grow.
Where the agent model costs you reproducibility
The direct CLI mode and the agent mode produce different kinds of artifacts. A direct invocation gives you a command you can paste into a script, diff between runs, and hand to a colleague. An agent session gives you a conversation. If the model picks a different tool on Tuesday than it did on Monday, the evidence trail changes with it, and nothing in the README describes a replay or pinning mechanism for agent decisions. For one-off research on a single target, that trade is fine and probably worth it. For a recurring monitoring job, an audit, or anything where a second analyst must reproduce your steps, the direct CLI is the mode to build on, and the agent is a convenience layer on top. The entity-resolution review card, with its field-by-field comparison and accept action, is a partial answer to this: it records a human decision on a match. It does not record why the agent chose a tool.
How it compares to running Sherlock and holehe directly
The obvious alternative is the underlying utilities themselves, invoked by hand or by a shell script. Sherlock and holehe are standalone programs with documented flags and stable, parseable output. A shell script that calls them gives you determinism, version pinning through your package manager, and no inference cost. What it does not give you is tool selection. The agent's value appears when the next step depends on the previous result in a way you did not anticipate: an email lookup surfaces a username, and the agent immediately pivots to username enumeration across sites without you writing that branch. The trade is that you have handed the routing decision to a language model, and you cannot inspect the routing logic the way you can read a shell script. If your investigations follow a fixed playbook, the script wins. If they branch unpredictably and you are present to supervise, the agent saves real time.
Licence, releases and the commercial tier
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. On top of that, the README points to a Commercial License starting from 300 EUR per year, described as a vendor contract with SLA and indemnification, plus a paid Complete Kit at 55 USD bundling prompts and a playbook, and a Setup Sprint at 350 USD for a done-for-you install. These are separate offerings from the MIT code, not restrictions on it. If you need contractual assurances that the MIT grant does not provide, that tier exists; whether it is worth the fee depends on your procurement rules, and this is a question for your own counsel rather than something the README settles. On maintenance, the release cadence visible in the repository is fast: three releases within August 2026, with the latest push in September 2026. Frequent releases over a small window usually mean active development, and they also mean the interface can move under you. Pin a version in any environment you depend on.
Editorial conclusion
Adopt OpenOSINT if you already know which OSINT utilities you want and would rather describe a target in a sentence than remember a dozen flag combinations, and if you are comfortable running third-party reconnaissance binaries on your own host. Skip it if you need a reproducible, scriptable pipeline with pinned tool versions, or if your environment forbids the outbound traffic these tools generate. Before committing, verify three things: that the MCP server entry registers under the name io.github.OpenOSINT/openosint in your client, that the 20 advertised tools match the ones you actually need, and that the sponsor-backed tools such as search_ip2location have a working API key path, since an unconfigured key turns that tool into a dead end mid-investigation.
Community notes