Quanto è privato Odysseus AI con un modello locale? Dati e rete

Quanto è privato Odysseus AI? Quattro confini

L’auto-hosting cambia chi gestisce lo spazio di lavoro, ma non elimina tutti gli altri soggetti coinvolti in un flusso. Conviene distinguere quattro confini: il dispositivo o server che conserva lo spazio, il modello che riceve un prompt, i servizi esterni contattati da una funzione e gli utenti di rete che possono raggiungere l’applicazione. Ogni confine risponde a una domanda diversa sulla privacy.

Un modello locale può rispondere senza inviare il prompt a un’azienda di modelli ospitati. La ricerca può comunque mandare query a SearXNG e ai motori esterni, mentre un’integrazione di calendario comunica con il server configurato. Un reverse proxy o una porta pubblica cambia anche chi può accedere allo spazio, indipendentemente dal luogo in cui avviene l’inferenza. Chiediti quale componente riceve ciascun dato, invece di trattare l’auto-hosting come un’unica impostazione di privacy.

Cosa resta locale quando usi un modello locale

La pagina ufficiale di sicurezza di Odysseus AI afferma che, con un modello locale servito da backend come Ollama, llama.cpp o vLLM, prompt e risposte restano sul tuo hardware. Indica inoltre che conversazioni, documenti, memoria e cache della posta si trovano nella cartella `data/` dell’applicazione. È la base più chiara per dire che l’inferenza locale può evitare l’invio di prompt e risposte a un fornitore remoto di inferenza.

Il perimetro dell’affermazione è importante. Un modello locale descrive il punto di inferenza, non ogni funzione dell’app. Una ricerca Web, una singola chiamata a un modello cloud o la sincronizzazione di posta e calendario hanno destinazioni separate. Sistema operativo, backup, disco, browser e amministratori fanno anch’essi parte del confine di fiducia. I dati locali richiedono comunque controlli di accesso e una politica di backup.

La pagina ufficiale afferma anche che il codice del progetto non include telemetria né analisi con chiamate automatiche. È una dichiarazione del progetto, non una misura indipendente della conservazione dei fornitori, dei log dell’host o di tutte le installazioni modificate.

Dove inviano i dati le funzioni collegate

Quanto è privato Odysseus AI con le integrazioni attive? Dipende dall’azione. La documentazione ufficiale spiega che i fornitori di modelli cloud ricevono i prompt inviati, la ricerca Web passa da SearXNG ai motori a monte e la sincronizzazione di posta o CalDAV comunica con il server configurato. Sono percorsi previsti, non la prova che ogni richiesta venga copiata a tutti i servizi.

Prima di un’attività sensibile, individua il percorso: endpoint del modello selezionato, uso della ricerca, account collegato e possibile effetto esterno di uno strumento. L’immagine seguente è concettuale. Separa le destinazioni per aiutarti a verificare la funzione e la configurazione effettive, senza dedurre il comportamento della tua installazione dal disegno.

Perché l’esposizione di rete è un rischio distinto

Un modello locale non decide chi può aprire lo spazio di lavoro. La pagina ufficiale afferma che Docker collega per impostazione predefinita l’app, ChromaDB, SearXNG e ntfy a `127.0.0.1`. Descrive `APP_BIND=0.0.0.0` come scelta per una rete LAN o un reverse proxy intenzionale, insieme a origini consentite coerenti. L’indirizzo di ascolto cambia la raggiungibilità, ma non rende sicuro da solo un servizio esposto.

Il modello di minaccia del progetto descrive Odysseus per utenti fidati su una rete privata e raccomanda di trattarlo come una console di amministrazione. Non suggerisce di esporre al pubblico un servizio senza autenticazione. Mantieni privati i porti interni, evita il port forwarding diretto su Internet e usa una rete di accesso privata come Tailscale, Cloudflare Access o WireGuard se è adatta al tuo ambiente.

Per ogni accesso oltre localhost, valuta insieme reverse proxy, HTTPS, origini consentite, autenticazione e firewall. Controlla quale servizio modifica ogni impostazione: ampliare le mappature dei container può rendere raggiungibili anche database o ricerca, oltre all’app.

Account, amministratori e permessi degli strumenti

I materiali ufficiali descrivono ruoli multiutente, autenticazione TOTP a due fattori, password con hash, controlli di sessione e strumenti privilegiati riservati agli amministratori. Raccomandano di mantenere attiva l’autenticazione e disattivare il bypass localhost fuori dallo sviluppo locale. Questi controlli possono ridurre l’accesso non autorizzato, ma non impediscono a un amministratore di usare le capacità assegnate al suo account.

La distinzione è esplicita nel modello di minaccia: un amministratore autenticato può eseguire comandi shell, leggere e scrivere file, inviare email e controllare il servizio dei modelli. Il documento mira a contrastare accesso non autenticato, violazioni dei privilegi, prompt injection da contenuti non attendibili e servizi interni raggiungibili dall’esterno. Non cerca di impedire all’amministratore di esercitare i poteri previsti.

Il modello descrive anche approvazioni degli strumenti e protezioni dei prompt per contenuti esterni come pagine Web o email. Sono difese utili, non la prova che ogni attacco sia impossibile. Usa un account non amministratore per il lavoro comune, limita gli amministratori e ruota le credenziali o i token esposti.

Controllo pratico prima di usarlo con dati reali

Fai una breve verifica prima di collegare account personali o inserire materiale riservato. L’obiettivo è comprendere i percorsi e ridurre l’esposizione inutile, non certificare la sicurezza dell’installazione. Inizia con un test a basso rischio e osserva quali servizi si attivano.

1. Scegli l’endpoint di inferenza

   Verifica se il modello è locale o ospitato. Per l’uso locale, conferma che l’indirizzo punti al servizio Ollama, llama.cpp o vLLM che controlli.

2. Rivedi le integrazioni

   Elenca ricerca, posta, calendario, notifiche e modelli remoti. Disattiva ciò che non serve e verifica la destinazione di ogni funzione attiva.

3. Limita l’accesso

   Mantieni attiva l’autenticazione, evita il bypass localhost fuori dallo sviluppo e assegna ruoli amministratore solo a chi ne ha bisogno.

4. Controlla porte e proxy

   Distingui i servizi loopback da quelli visibili sulla LAN. Mantieni privati i porti interni e proteggi l’accesso remoto con un livello dedicato.

5. Proteggi i dati locali

   Limita l’accesso a `data/`, individua dove si trovano i backup e proteggi gli archivi copiati come il server in uso.

6. Prova con contenuti non sensibili

   Esegui una richiesta innocua, osserva la destinazione configurata e verifica autenticazione e approvazioni prima del lavoro reale.

Quanto è privato Odysseus AI per ogni attività?

La stessa installazione può avere caratteristiche di privacy diverse a seconda dell’attività. Riassumere un file con un modello locale apre meno percorsi esterni di un prompt inviato a un modello cloud, ma conta ancora chi può accedere all’account e all’host. La ricerca Web aggiunge motori di ricerca; un’attività di posta aggiunge il server dell’account e i permessi d’azione.

Per un gruppo, la domanda pratica non è solo se l’app è auto-ospitata. Decidi quali dati possono essere trattati da un modello locale, quali possono raggiungere fornitori approvati e quali integrazioni richiedono l’autorizzazione di un amministratore. Registra le decisioni e ricontrollale dopo modifiche a endpoint, proxy o integrazioni.

Cosa non dimostra questa verifica

Questo articolo riassume la pagina ufficiale di sicurezza e il modello di minaccia controllati il 23 ottobre 2026. Non è un penetration test, un audit del codice, una valutazione legale o una garanzia di un fornitore. Le dichiarazioni ufficiali su telemetria e inferenza locale sono attribuite al progetto e qui non sono state verificate in modo indipendente. Il comportamento dipende anche da commit, configurazione, account collegati e gestione operativa. Controlla documentazione aggiornata e installazione prima di fare affidamento su un controllo.