OpenOSINT: an OSINT agent that keeps the model out of the findings

The hallucination problem OpenOSINT is built around

Ask a general-purpose model to investigate an email address and it will produce a plausible answer. That is the failure mode this project targets. The README states the design directly: the AI issues hard-stop tool calls and your code executes the real binary, so hallucinated findings are structurally impossible. The model's job is routing, not reporting. It reads the request, picks a tool, and the Python layer runs the underlying program. What comes back is whatever the binary returned.

The audience follows from that. This is for security researchers and analysts who already know what a whois lookup or a username sweep is supposed to return, and who want the orchestration compressed without giving up provenance. It is not a teaching tool for someone learning OSINT from zero, and the repository says as much in its own framing: for authorized security research only. The DISCLAIMER.md and SECURITY.md files sit at the top level, which tells you the maintainers expect the legal boundary to be read before the tool is pointed at anything.

How the tool calls, datasets and entity graph fit together

The architecture has three visible layers. At the bottom, 19 investigation tools, several of which are external binaries the Dockerfile installs via pip: holehe, sherlock-project and sublist3r. Above them, an agent loop that talks to a model provider through one of three backends. On top, the interfaces: an interactive REPL, a CLI for direct non-AI calls, an MCP server, and a browser Web UI.

The graph side is where the project gets more interesting than a wrapper. The README describes an entity graph where statements carry their dataset, extractor, run id and confidence. Two Organization nodes observed independently by the openosint:github and openosint:whois datasets get linked by a dashed same_as candidate edge scored 0.83, and a human review card shows both entities field by field with matching values in green and differing values in amber. Accepting the edge clusters the pair and turns it solid. That is a deliberate choice to keep machine guesses as candidates until a person signs off, and it is the part of the design most worth copying.

One caveat the README raises against itself: the demo entities are seeded at the statement layer, not produced by today's mappers. The graph demo shows the review workflow, not the extraction pipeline's current accuracy.

Installing OpenOSINT and running a first lookup

The package is on PyPI. The README gives a single install line, and pyproject.toml requires Python 3.10 or newer.

pip install openosint

Before the AI modes work, you need a provider. Copy .env.example to .env and fill in one backend. Anthropic Claude is the default, and the example file shows the key format.

ANTHROPIC_API_KEY=sk-ant-...

The .env.example also documents OPENAI_BASE_URL, OPENAI_API_KEY and OPENAI_MODEL for a self-hosted OpenAI-compatible gateway, noting that the model's server must support tool or function calling. OPENOSINT_MODEL still works as an alias for ANTHROPIC_MODEL but logs a one-time deprecation warning.

With the key in place, running openosint with no arguments drops you into the interactive REPL. The direct CLI path skips the model entirely, which is the fastest way to confirm the binaries are reachable.

openosint email [email protected]

The README also lists openosint web for the browser interface. For a container deployment, docker-compose.yml builds the image, maps port 8080, reads .env, and mounts ./reports into /app/reports so results survive a restart.

docker compose up

The Dockerfile ends with openosint web --host 0.0.0.0 --port 8080 --no-browser --allow-remote. That last flag is not optional: the comment in the Dockerfile ties it to GHSA-cqr4-hcfp-m6m4 and says --allow-remote is required for a non-loopback bind.

The provider dependency is the real adoption cost

OpenOSINT is not a standalone scanner. Every AI-backed path needs a model, and the default is a hosted Anthropic endpoint. If your engagement rules prohibit sending target identifiers to a third-party API, the REPL, the Web UI and the MCP server are all closed to you, and you are left with the direct CLI calls, which is a much smaller product.

The escape hatch is the self-hosted OpenAI-compatible gateway. The .env.example names LiteLLM, llama-swap, vLLM, LM Studio and llama.cpp as candidates, and notes that this path takes precedence over Ollama when no ANTHROPIC_API_KEY is set. The constraint is stated plainly: the model's server must support tool or function calling, with llama.cpp launched with --jinja given as the example. A local model that cannot emit structured tool calls will not drive the agent, and the documentation does not describe a fallback for that case.

Two smaller edges are worth noting. The repository describes 19 tools in pyproject.toml while the README header says 20 investigation tools, so the count depends on which file you read. And the Web UI has its own access control surface: POST /api/setup is localhost-only unless OPENOSINT_SETUP_TOKEN is set, in which case remote callers must send it as X-Setup-Token. Deploying the web interface publicly without setting that token is a configuration mistake the .env.example is trying to prevent.

Where OpenOSINT sits against SpiderFoot and the MCP route

SpiderFoot is the obvious comparison, and the difference is not feature count. SpiderFoot is a self-contained scanning platform: you give it a target, it runs its own modules against a local database, and the correlation happens inside its own engine. No model provider sits in the loop, and nothing leaves your machine unless a module reaches out to a data source.

OpenOSINT inverts that. The intelligence lives in the agent's tool selection and in the entity graph's review workflow, and the execution is delegated to external binaries and HTTP APIs. You get a conversational interface and a same_as candidate review loop that SpiderFoot does not present the same way. You give up self-containment, and you take on an API key, a provider dependency and a per-investigation cost that a local SpiderFoot instance does not have.

The MCP server is the other reason to pick this over a plain CLI wrapper. Publishing to the MCP registry means the same 19 tools can be attached to a compatible client rather than driven from OpenOSINT's own REPL. If your workflow already lives in an MCP-capable assistant, that is the integration path; if it does not, the REPL is the entry point.

Licence, releases and what maintenance actually looks like

The project is MIT licensed, and pyproject.toml declares license = "MIT" with a Development Status classifier of Production/Stable. That covers the code in the repository.

It does not cover everything around it. The README advertises a Commercial License from €300/yr described as a vendor contract with SLA and indemnification, alongside paid kits and a setup sprint. There is a COMMERCIAL.md and a COMMERCIAL-LICENSE.md at the top level, and a CLA.md for contributors. If you are evaluating OpenOSINT for a commercial engagement, read those files rather than assuming the MIT grant is the whole picture. This is not legal advice; the point is that the repository contains more than one licensing document and they are not identical in scope.

The maintenance signal is healthy on the numbers alone: the last push was on 2026-09-08, and the release list shows v2.27.0 on 2026-08-26, v2.26.0 the day before, and v2.25.1 on 2026-08-24. That is a fast release cadence, and pyproject.toml carries version 2.28.2, so the published package is ahead of the most recent tagged release. The upgrade cost that follows from this is dependency churn: the project pins mcp>=1.0.0,<2 and anthropic>=0.40.0 with lower bounds only, so a fresh install resolves to whatever is current. Pin your own lockfile if you need reproducible runs.

Editorial conclusion

Adopt OpenOSINT if you already run OSINT tooling and want an agent layer that executes real binaries instead of narrating them, and if you are comfortable pinning an LLM provider in .env before anything works. Do not adopt it if you need a self-contained scanner with no API key, or if your engagement rules forbid sending target identifiers to a hosted model. Verify first that your chosen provider supports tool calling, since the self-hosted OpenAI-compatible gateway path requires it, and confirm your deployment binds correctly: the Dockerfile passes --allow-remote because GHSA-cqr4-hcfp-m6m4 makes that flag mandatory for a non-loopback bind.

Frequently asked questions

Official sources

1. License: MIT
2. OpenOSINT/OpenOSINT on GitHub
3. Project website
4. README
5. Releases