Wie privat ist Odysseus AI? Modelle, Daten und Netzwerkrisiken

Wie privat ist Odysseus AI? Vier Datenschutzgrenzen

Self-Hosting ändert, wer den Arbeitsbereich betreibt, entfernt aber nicht automatisch alle anderen Beteiligten aus einem Ablauf. Vier Grenzen helfen bei der Einordnung: das Gerät oder der Server mit den gespeicherten Daten, das Modell für einen Prompt, externe Dienste einer Funktion und Netzwerkbenutzer, die die Anwendung erreichen können. Jede Grenze beantwortet eine andere Datenschutzfrage.

Ein lokales Modell kann antworten, ohne den Prompt an ein gehostetes Modellunternehmen zu schicken. Die Suche kann trotzdem Anfragen an SearXNG und vorgeschaltete Suchmaschinen senden; eine Kalenderintegration spricht mit dem eingestellten Server. Auch ein Reverse-Proxy oder öffentlicher Port verändert den Zugriff, unabhängig davon, wo die Inferenz läuft. Prüfen Sie für jede Eingabe die konkrete empfangende Komponente, statt Self-Hosting als einzelne Datenschutzoption zu behandeln.

Was mit einem lokalen Modell lokal bleibt

Die offizielle Sicherheitsseite von Odysseus AI sagt, dass Prompts und Antworten bei lokalen Backends wie Ollama, llama.cpp oder vLLM auf Ihrer Hardware bleiben. Gespräche, Dokumente, Erinnerungen und Mail-Caches liegen laut dieser Seite im Verzeichnis `data/` der Anwendung. Das ist die klarste Grundlage für die Aussage, dass lokale Inferenz Prompts und Antworten von einem entfernten Inferenzanbieter fernhalten kann.

Der Geltungsbereich ist wichtig. Ein lokales Modell beschreibt den Inferenzendpunkt, nicht jede Funktion der Anwendung. Webrecherche, ein einzelner Cloud-Aufruf oder Mail- und Kalendersynchronisierung haben jeweils eigene Ziele. Betriebssystem, Backups, Datenträger, Browser und Administratoren gehören ebenfalls zur Vertrauensgrenze. Lokal gespeicherte Daten benötigen weiterhin Zugriffsschutz und eine durchdachte Sicherung.

Die offizielle Seite erklärt außerdem, der Quellcode enthalte weder Telemetrie noch eine automatische Analyseverbindung nach Hause. Das ist eine Aussage des Projekts und keine unabhängige Messung der Speicherung durch Anbieter, der Host-Protokolle oder jeder angepassten Installation.

Wohin verbundene Funktionen Daten senden

Wie privat ist Odysseus AI bei aktivierten Integrationen? Das hängt von der Aktion ab. Laut offizieller Dokumentation erhalten Cloud-Modellanbieter die an sie gesendeten Prompts; Websuche leitet Anfragen über SearXNG an vorgeschaltete Suchmaschinen weiter; Mail- oder CalDAV-Synchronisierung kommuniziert mit dem konfigurierten Server. Das sind vorgesehene Datenwege und kein Beleg dafür, dass jede Anfrage an jeden Dienst kopiert wird.

Identifizieren Sie vor einer sensiblen Aufgabe den Weg: den gewählten Modellendpunkt, eine aktive Suche, das verbundene Konto und mögliche externe Aktionen eines Werkzeugs. Die Abbildung ist konzeptionell. Sie trennt Ziele, damit Sie Funktion und Konfiguration Ihrer Installation prüfen, statt ihr Verhalten aus einer Illustration abzuleiten.

Warum Netzwerkerreichbarkeit ein eigenes Risiko ist

Ein lokal gehostetes Modell bestimmt nicht, wer den Arbeitsbereich öffnen kann. Die offizielle Sicherheitsseite sagt, Docker binde Anwendung, ChromaDB, SearXNG und ntfy standardmäßig an `127.0.0.1`. `APP_BIND=0.0.0.0` sei für eine bewusst eingerichtete LAN- oder Reverse-Proxy-Umgebung gedacht und müsse mit passenden erlaubten Ursprüngen verbunden werden. Eine Bind-Adresse ändert die Erreichbarkeit, macht einen exponierten Dienst aber nicht automatisch sicher.

Das Bedrohungsmodell des Projekts beschreibt Odysseus für vertrauenswürdige Nutzer in einem privaten Netzwerk und empfiehlt, die Anwendung wie eine Admin-Konsole zu behandeln. Ein nicht authentifizierter öffentlicher Dienst ist nicht vorgesehen. Halten Sie interne Ports geschlossen, vermeiden Sie direkte Portweiterleitungen ins Internet und nutzen Sie für Fernzugriff eine private Zugriffsschicht wie Tailscale, Cloudflare Access oder WireGuard, sofern sie zu Ihrer Umgebung passt.

Prüfen Sie außerhalb von localhost Reverse-Proxy, HTTPS, erlaubte Ursprünge, Authentifizierung und Firewall gemeinsam. Klären Sie, welchen Dienst eine Bind-Einstellung betrifft; breitere Container-Portzuordnungen können neben der App auch Datenbank oder Suche erreichbar machen.

Konten, Administratorzugriff und Werkzeugrechte

Die offiziellen Sicherheitsunterlagen beschreiben Mehrbenutzerrollen, TOTP-Zwei-Faktor-Authentifizierung, gehashte Passwörter, Sitzungsprüfungen und Admin-Beschränkungen für privilegierte Werkzeuge. Sie empfehlen, Authentifizierung eingeschaltet zu lassen und den localhost-Bypass außerhalb der lokalen Entwicklung zu deaktivieren. Solche Kontrollen können unberechtigten Zugriff verringern, hindern einen Admin aber nicht daran, seine zugewiesenen mächtigen Funktionen zu nutzen.

Das Bedrohungsmodell sagt ausdrücklich, dass ein angemeldeter Admin Shell-Befehle ausführen, Dateien lesen und schreiben, E-Mails senden und den Modelldienst steuern kann. Es zielt auf nicht authentifizierten Zugriff, überschrittene Rechte, Prompt-Injection durch nicht vertrauenswürdige Inhalte und von außen erreichbare interne Dienste. Es soll nicht verhindern, dass ein Admin seine vorgesehenen Rechte nutzt.

Das Dokument beschreibt außerdem Werkzeugfreigaben und Prompt-Schutz für externe Web- oder E-Mail-Inhalte. Das sind sinnvolle Abwehrmaßnahmen, aber kein Beweis, dass jeder Angriff unmöglich ist. Verwenden Sie für den Alltag ein Konto ohne Adminrechte, beschränken Sie Administratoren und ersetzen Sie offengelegte Zugangsdaten oder Tokens.

Praktische Datenschutzprüfung vor der Nutzung

Prüfen Sie die Umgebung, bevor Sie persönliche Konten verbinden oder vertrauliche Inhalte ablegen. Ziel ist, Datenwege zu verstehen und unnötige Offenlegung zu verringern, nicht die Installation als sicher zu zertifizieren. Beginnen Sie mit einem risikoarmen Test und beobachten Sie die aktivierten Dienste.

1. Inferenzendpunkt wählen

   Prüfen Sie, ob das Modell lokal oder gehostet ist. Bei lokalem Einsatz muss die Adresse auf den von Ihnen kontrollierten Ollama-, llama.cpp- oder vLLM-Dienst zeigen.

2. Integrationen prüfen

   Listen Sie Suche, Mail, Kalender, Benachrichtigungen und entfernte Modelle auf. Deaktivieren Sie Unnötiges und prüfen Sie das Ziel jeder aktiven Funktion.

3. Zugriff begrenzen

   Lassen Sie Authentifizierung aktiv, vermeiden Sie den localhost-Bypass außerhalb der Entwicklung und vergeben Sie Adminrechte nur bei Bedarf.

4. Ports und Proxy prüfen

   Unterscheiden Sie Loopback-Dienste von LAN-Diensten. Halten Sie interne Ports privat und schützen Sie Fernzugriff mit einer passenden Zugriffsschicht.

5. Lokale Daten schützen

   Beschränken Sie den Zugriff auf `data/`, kennen Sie den Speicherort der Backups und sichern Sie Archive so sorgfältig wie den laufenden Host.

6. Mit unkritischen Daten testen

   Führen Sie einen harmlosen Modellaufruf aus, beobachten Sie das Ziel und testen Sie Authentifizierung sowie Werkzeugfreigaben vor echter Arbeit.

Wie privat ist Odysseus AI je nach Aufgabe?

Dieselbe Installation kann je nach Aufgabe unterschiedliche Datenschutzmerkmale haben. Eine lokale Datei mit einem lokalen Modell zusammenzufassen eröffnet weniger externe Wege als ein Prompt an ein Cloud-Modell, hängt aber weiterhin davon ab, wer Konto und Host erreichen kann. Webrecherche ergänzt Suchanbieter; Mailarbeit ergänzt den Kontoserver und die Rechte für Aktionen.

Für Teams lautet die praktische Frage nicht nur, ob die Anwendung selbst gehostet wird. Legen Sie fest, welche Daten lokal verarbeitet werden dürfen, welche an freigegebene Anbieter gehen dürfen und welche Integrationen eine Admin-Freigabe erfordern. Halten Sie die Entscheidung fest und prüfen Sie sie nach Änderungen an Modellendpunkten, Proxyregeln oder Integrationen erneut.

Was diese Prüfung nicht belegt

Dieser Artikel fasst die am 23. Oktober 2026 geprüfte offizielle Sicherheitsseite und das Bedrohungsmodell zusammen. Er ist kein Penetrationstest, Code-Audit, keine Rechtsprüfung und keine Garantie eines Anbieters. Aussagen des Projekts zu Telemetrie und lokaler Inferenz sind als solche gekennzeichnet und wurden hier nicht unabhängig verifiziert. Das tatsächliche Verhalten hängt auch von Commit, Konfiguration, verbundenen Konten und Betrieb ab. Prüfen Sie aktuelle Dokumentation und Ihre Installation, bevor Sie sich auf eine Kontrolle verlassen.