Was Dinoer nicht hinter Ihrem Rücken tut

Sie erwägen, einer Forschungspipeline Zugriff auf Ihre Anmeldedaten und den ausgehenden Netzwerkverkehr Ihres Computers zu gewähren. Das ist eine ernste Entscheidung. Hier sind die Grundlagen dafür, zusammen mit der Datei, die dies jedes Mal durchsetzt – nicht unser Wort.

Dinoer speichert Ihre Zugangsdaten niemals in einem Terminal

Sie durchlaufen niemals Ihre Shell, Ihren Befehlsverlauf oder die Protokolle von Dinoer.

→ lib/repertoire_chiffre.py – wie ein Anmeldedatensatz tatsächlich ein Formular erreicht →

Dieselbe Regel gilt innerhalb von evaluer: Eine Szenario-Aktion mit einem Klartextwert auf einem Feld, das wie password/secret aussieht, wird abgelehnt – action_secret_en_clair, geprüft bevor das Szenario überhaupt Playwright erreicht, nicht nachträglich kontrolliert.

Was Dinoer selbst schreibt, wird standardmäßig ausgeblendet. Rückgabewerte, URLs und Fehlermeldungen, die über die Standardausgabe oder das Operationsprotokoll laufen, werden neutralisiert, es sei denn, Sie fordern explizit etwas anderes (--no-filtre-evaluer, was dann in der JSON-Ausgabe selbst gemeldet wird).

→ lib/sanitisation.py

Was dies nicht abdeckt: Der Agent, der Dinoer ausführt, hat eigenen Zugriff auf Ihre Maschine. Wenn Sie ihm ein Terminal geben, kann er Ihr eingebundenes Verzeichnis wie jede andere Datei lesen. Dinoer schützt den Pfad, den es kontrolliert – nicht den, den Sie daneben öffnen.

Der Korpus ist das, was dem delegierten Modell erlaubt ist, zu verlassen

opencode.jsonc verweigert websearch/webfetch dem Modell, das Ihren Bericht erstellt – es existiert, weil ein tatsächlicher Durchlauf am 14. August 2026 das Gegenteil ergab: zwölf aktive Suchvorgänge, die im endgültigen Text unsichtbar waren und Inhalte aus Quellen bezogen, die der gesammelte Korpus nie enthielt. Dies wurde durch Aufzeichnung des gesamten Ereignisstroms des Modells verifiziert, nicht durch blinden Glauben an das, was es zurückgab.

→ opencode.jsonc, lib/modeles.py::invoquer_opencode()

Was das nicht abdeckt. bash bleibt erlaubt – echte Szenarien brauchen es –, und ein Modell, dem websearch verweigert wurde, hat in einem Verifikationslauf stattdessen über bash curl das offene Web erreicht. Das ist die einzige Garantie auf dieser Seite, die nicht absolut ist, und sie wird auch so benannt, statt aufgerundet.

Es hängt nicht davon ab, von wo Sie es starten. OpenCode liest opencode.jsonc aus dem Verzeichnis, in dem es gestartet wird, und das .deb Paket installiert diese Datei nicht. Seit 1.0.1 setzt invoquer_opencode() daher dieselbe Verweigerung selbst, in OPENCODE_CONFIG_CONTENT, zusammengeführt mit einem bereits vorhandenen Wert. Gemessen am 25. September 2026 mit opencode debug config (OpenCode 1.18.32), gestartet von /tmp mit diesem Wert: websearch und webfetch sind deny, bash bleibt allow. Ohne ihn sind vom selben Verzeichnis aus die ersten beiden allow – weshalb der Wert bei jedem Aufruf gesetzt und nicht dem Verzeichnis überlassen wird.

Was Dinoer berichtet, entscheidet es nicht

pret_a_agir: false bedeutet eine Reibung wurde wahrgenommen – eine WAF-Signatur, eine Sitzungsabweichung, eine Navigationsgrenze. Es bedeutet nicht ich verweigere die Ausführung. Dinoer meldet, was es bemerkt hat, und überlässt Ihnen die Entscheidung.

Die WAF-Erkennung basiert auf Schlüsselwörtern und kann fehlerhaft sein. Sie wird als eine Anzahl angegeben, nie als eine Ausnahme gemeldet, die die Ausführung stoppt, und --ignorer-waf ist dort für den Fall, dass Sie überprüft haben und es falsch war.

Die Unterscheidung ist wichtiger, als es scheint. Ein Werkzeug, das über den Zugang moralisiert, wird zu einem Werkzeug, an dem man vorbeitarbeitet, und ein Werkzeug, an dem die Leute vorbeitarbeiten, stoppt jegliche Berichterstattung.

Der Agent entscheidet nicht selbstständig darüber, was er tut – mit einer Ausnahme, die explizit genannt wird

Jeder Klick, jeder Tastendruck, jede Navigation, die der gespeicherte Browser-Kern ausführt, ist eine Zeile, die in einer Szenariodatei geschrieben wird. Dieser Teil von Dinoer führt eine Liste aus; er erfindet keine.

→ scenarios/schema.json

Die Forschungsabfolge ist nicht die gleiche Aussage. campagne.py delegiert tatsächliche interpretatorische Urteilsfähigkeit an ein Modell – ob eine Seite eine offene Frage beantwortet, ob zwei Seiten dasselbe Ereignis beschreiben. Diese Delegation ist der Sinn und Zweck der Abfolge, nicht eine Lücke darin – aber das bedeutet, dass diese Garantie, wörtlich gelesen, den Browser-Kern abdeckt und nicht den Synthese-Schritt darüber hinaus. Sagen Sie dies klar und deutlich, anstatt zu zulassen, dass die Formulierung aus der RPA-Ära mehr impliziert, als sie jetzt abdeckt.

Sie können alles später noch einmal überprüfen

Jeder Durchlauf wird in einem datumsgesteuerten, schreibgeschützten Operationsprotokoll erfasst – was versucht wurde, wo, mit welchem Ergebnis, und mit dem dahinterstehenden Zweck versehen. Was die Pipeline getan hat, können Sie einsehen – nicht nur den Bericht, den sie Ihnen liefert.

→ journal.py, /var/log/dinoer/operations.jsonl

Was verlässt Ihre Maschine, und durch welchen Ausgang?

Drei Dinge können Ihre Maschine verlassen, und jedes davon liegt in Ihrer Hand: die Anfragen an die SearXNG-Instanz, die Sie konfigurieren, der gesammelte Text, der an das Modell von OpenCode geht, und eine Benachrichtigung an einen ntfy-Server (ntfy.sh, sofern Sie keinen anderen festlegen). Ihre Anmeldedaten nicht. Die vollständige Tabelle mit der Datei hinter jeder Zeile steht auf der Architekturseite; den Preis des zweiten Punkts nennen die technischen Entscheidungen.

Und was Dinoer nicht behauptet:

Es ist nicht sorgfältiger als das Szenario oder die Beschreibung, die Sie ihm geben. Ein schlecht geschriebenes Dokument kann erheblichen Schaden anrichten – und zwar in Maschinengeschwindigkeit. Die oben genannte Garantie deckt lediglich ab, woher eine Antwort stammt, aber nicht, ob die Frage eine gute Frage war.