OpenOSINT: 20 OSINT-Werkzeuge hinter einer natürlichen Spracheingabe

Welches Problem der Agent eigentlich löst

Die Werkzeuge, die OpenOSINT bündelt, sind nicht neu. In den Topics des Repositories tauchen holehe, maigret und sherlock auf, also Programme, die eine E-Mail-Adresse oder einen Benutzernamen gegen eine lange Liste von Diensten prüfen. Der Aufwand liegt traditionell nicht in der Einzelabfrage, sondern in der Orchestrierung: welches Werkzeug bekommt welchen Parameter, in welcher Reihenfolge, und wie werden die Ausgaben zusammengeführt. Genau diese Schicht ersetzt das Projekt durch eine natürlichsprachliche Schnittstelle. Die README beschreibt es als OSINT-Agenten für Sicherheitsforscher und Analysten, mit 20 Untersuchungswerkzeugen hinter einer Konversationsoberfläche. Der Beschreibungstext des Repositories nennt dagegen 19 Tools. Diese Abweichung ist kein Detail: sie zeigt, dass die Tool-Registry sich zwischen Releases bewegt, und wer die Anzahl als Planungsgröße nimmt, sollte sie an der installierten Version nachzählen statt am Marketing-Text. Adressiert wird ein wiederkehrender Arbeitsablauf, kein einmaliges Skript. Wer täglich dieselben drei Abfragen für unterschiedliche Ziele fährt, spart durch die Abstraktion echte Zeit. Wer einmalig eine Domain auflösen will, spart nichts.

Der Agent entscheidet, der Code führt aus

Die zentrale Behauptung steht als kursiver Satz in der README: das KI-Modell gibt harte Tool-Aufrufe aus, der eigene Code führt die echte Binärdatei aus, halluzinierte Ergebnisse seien damit strukturell unmöglich. Das ist eine Aussage über die Datenflussrichtung. Das Modell erzeugt demnach keine Fließtext-Antwort, aus der ein Mensch Fakten herausliest, sondern einen strukturierten Aufruf, den die Laufzeit gegen ein reales Programm auflöst. Der Unterschied ist praktisch relevant, weil ein Modell ohne diese Trennung plausibel klingende DNS-Records erfinden kann, die niemand als falsch erkennt. Die Architektur wird durch die vier Betriebsarten sichtbar, die die README aufzählt: REPL, CLI, MCP-Server und Browser-Web-UI. Der MCP-Server ist der interessanteste Teil, weil er den Agenten aus dem eigenen Terminal heraus in fremde Clients verlagert. Das Repository ist unter io.github.OpenOSINT/openosint in der MCP-Registry veröffentlicht, laut README. Für die Web-UI zeigt die README einen Globus, auf dem Treffer als Punkte landen, und einen Entity-Graph, in dem zwei unabhängig beobachtete Organization-Knoten über eine gestrichelte same_as-Kante mit Score 0.83 verbunden sind. Wichtig ist die Fußnote darunter: die gezeigte Demo nutzt deterministische synthetische Daten, alle Entitäten sind fiktiv, und die Knoten werden auf der Statement-Ebene eingesetzt, nicht von den aktuellen Mappern erzeugt. Das ist eine ehrliche Einschränkung und sollte beim Lesen der Animation mitgedacht werden.

Installation und die drei Einstiegspunkte

Der Einstieg ist ein einzelner pip-Befehl: pip install openosint. Danach nennt die README drei Aufrufe. openosint startet die interaktive KI-REPL, also den Standardmodus. openosint web öffnet die Weboberfläche. openosint email target@example.com ruft ein einzelnes Werkzeug direkt auf, ohne Modell dazwischen. Dieser dritte Pfad ist der unterschätzte: er liefert dieselbe Funktion ohne API-Key, ohne Latenz eines Modellaufrufs und ohne die Frage, ob das Modell den richtigen Parameter gewählt hat. Für reproduzierbare Arbeit ist er die richtige Wahl. Die README nennt als Modelloptionen Claude, GPT-4 oder lokale Modelle, ohne an dieser Stelle die Konfigurationsschlüssel zu zeigen. Wer den Agenten-Modus braucht, muss also die Dokumentation auf der Projektseite konsultieren, um zu erfahren, wie der jeweilige Anbieter hinterlegt wird. Das Repository selbst liefert in der gekürzten Fassung keine Config-Beispiele, und ich habe die Software nicht installiert, um sie zu ermitteln. Festhalten lässt sich nur: die Modellwahl ist austauschbar, und ein lokales Modell entfernt die Abhängigkeit von einem externen Anbieter, kostet aber eigene Hardware. Der MCP-Pfad richtet sich an Nutzer, die den Server in einen bestehenden Client einbinden, statt das Terminal zu wechseln.

Wo das Konzept an seine Grenzen stößt

Die harten Tool-Aufrufe schützen vor erfundenen Ergebnissen, nicht vor falsch gewählten Parametern. Wenn das Modell einen Benutzernamen statt einer E-Mail-Adresse an ein Werkzeug übergibt, führt die Laufzeit trotzdem ein echtes Programm aus, nur mit dem falschen Argument. Die strukturelle Garantie deckt also die Existenz des Ergebnisses, nicht seine Relevanz. Der zweite Punkt betrifft die Abhängigkeiten. Die genannten Werkzeuge sind eigenständige Programme, die gegen Dienste im Netz arbeiten. Ändert ein Dienst seine Schnittstelle, liefert die Abfrage weniger Treffer, und der Agent hat darauf keinen Einfluss. Ergebnisse sind damit zeitgebunden und nicht ohne Weiteres reproduzierbar. Drittens die Rechtslage: die README stellt das Projekt ausdrücklich unter den Vorbehalt autorisierter Sicherheitsforschung. Das ist keine Formalie. Wer Benutzernamen gegen fremde Dienste prüft, erzeugt Anfragen bei Dritten, und die Verantwortung dafür trägt der Ausführende, nicht das Werkzeug. Schließlich die falsche Werkzeugwahl: für eine einzelne DNS-Auflösung ist der Agent Overhead. Die README zeigt in der Demo einen DNS-Lookup, der in unter zwei Sekunden zurückkommt. Wer das einmal braucht, ruft dig auf.

Was maigret und sherlock allein anders machen

Die naheliegende Alternative sind die Werkzeuge, die OpenOSINT intern ohnehin aufruft. maigret und sherlock prüfen Benutzernamen gegen viele Dienste und geben eine Liste von Treffern aus. Der Unterschied liegt nicht in der Suchabdeckung, sondern in der Steuerung. Bei den Einzelwerkzeugen legt der Nutzer die Zielliste, die Reihenfolge und die Auswertung selbst fest, meist über Kommandozeilen-Flags und eine Ausgabedatei. Das ist deterministisch und in ein Skript einbettbar. OpenOSINT setzt darüber eine Schicht, die aus einer natürlichsprachlichen Anweisung einen Aufruf ableitet und mehrere Werkzeuge in einer Sitzung kombinieren kann. Der Preis dieser Bequemlichkeit ist eine zusätzliche Fehlerquelle zwischen Absicht und Ausführung. Wer eine Prüfung wiederholen und die Ergebnisse vergleichen will, ist mit dem direkten Aufruf besser bedient, weil dort jeder Parameter explizit im Befehl steht. Wer dagegen explorativ arbeitet und während einer Untersuchung von einer E-Mail-Adresse auf einen Handle und dann auf eine Domain wechselt, profitiert von der Konversationsschicht, weil der Kontext zwischen den Schritten erhalten bleibt.

Wartung, Release-Tempo und Lizenz

Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten auf dem 8. September 2026. Die Release-Historie zeigt v2.27.0 vom 26. August 2026, v2.26.0 einen Tag zuvor und v2.25.1 am 24. August 2026. Drei Releases innerhalb von drei Tagen bedeuten ein hohes Änderungstempo. Für Nutzer heißt das: Update-Kosten sind real, und ein Blick in die Release Notes vor jedem Sprung ist sinnvoll, besonders wenn der MCP-Server in einen fremden Client eingebunden ist, dessen Verhalten sich mit der Server-Version ändern kann. Die Lizenz ist MIT, also permissiv, mit den üblichen Freiheiten bei Weitergabe und Änderung. Daneben existiert laut README ein kommerzielles Angebot ab 300 Euro pro Jahr, das einen Vertrag, SLA und Freistellung umfasst. Das ist kein Widerspruch zur MIT-Lizenz, sondern ein zusätzliches Angebot für Organisationen, die Zusicherungen brauchen, die eine Open-Source-Lizenz nicht gibt. Wer die MIT-Version nutzt, erhält keine SLA und keinen Support-Anspruch. Die README verlinkt außerdem kostenpflichtige Extras, darunter ein Setup-Paket für 350 Dollar, das den Installationsaufwand abnimmt. Ob das nötig ist, hängt davon ab, wie viel Zeit die eigene MCP-Einbindung kostet. Eine rechtliche Bewertung der Datenabfragen ersetzt keines dieser Angebote.

Einordnung vor dem ersten Einsatz

OpenOSINT ist kein Ersatz für OSINT-Methodik, sondern eine Ausführungsschicht darüber. Der stärkste Teil des Designs ist die Trennung zwischen Modellentscheidung und realem Prozess, weil sie eine ganze Klasse von Fehlern ausschließt. Der schwächste Teil ist die Dokumentationslage in der gekürzten README: Modellkonfiguration, Proxy-Einbindung und die genaue Zusammensetzung der 20 Werkzeuge lassen sich daraus nicht ableiten. Zwei Sponsoren sind im README sichtbar, IP2Location.io und RapidProxy, wobei IP2Location laut README das Werkzeug search_ip2location mit Geodaten, ISP- und VPN-Erkennung versorgt. Das ist eine externe Abhängigkeit mit eigenem Kontingent und eigenen Bedingungen, die bei der Kostenplanung mitgezählt werden sollte. Für wen lohnt es sich? Für Analysten, die wiederkehrende Prüfungen über mehrere Ziele fahren und die Ergebnisse in einer Oberfläche statt in fünf Terminalfenstern sehen wollen. Für wen nicht? Für alle, die Ergebnisse archivieren und Monate später identisch reproduzieren müssen, sowie für Umgebungen, in denen kein externer Modellendpunkt erreichbar ist und kein lokales Modell betrieben werden kann.

Redaktionelles Fazit

Wer wiederkehrende Lookups über E-Mail, Handle oder Domain automatisiert und die Ausführung ohnehin in einer kontrollierten Umgebung betreibt, findet hier eine schlanke MIT-lizenzierte Basis. Wer Ergebnisse ohne laufende Tool-Abhängigkeit reproduzieren muss oder keinen API-Key einsetzen will, sollte zuerst die CLI direkt aufrufen und die Modellpfade prüfen. Vor dem produktiven Einsatz zu verifizieren: ob die installierte Version tatsächlich 20 statt der im Beschreibungstext genannten 19 Werkzeuge registriert, und ob die genutzten MCP-Clients mit dem Server unter io.github.OpenOSINT/openosint zusammenarbeiten.

Offizielle Quellen

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