Il posto più sicuro per il tuo lavoro è il computer su cui si trova già.

1. Il nostro approccio

Due principi guidano tutto ciò che segue. Primo, prima il locale, per impostazione predefinita: nel runtime locale l'inferenza, la memoria e i file dell'agente vengono eseguiti sulla tua macchina, con i modelli che ospiti tu. L'eccezione è uno strumento a pagamento che scegli di eseguire - ricerca web e su X, generazione di immagini e video, azioni dei connettori - che richiede chiavi provider gestite in nostro possesso, quindi quella singola chiamata allo strumento viene eseguita da Convira e restituita al tuo dispositivo (e solo mentre sei online). In secondo luogo, il cloud è facoltativo e minimo: quando utilizzi il runtime cloud, la tua esecuzione viene eseguita e inoltrata al provider di modelli IA, ma i contenuti dell'esecuzione non vengono memorizzati sui nostri server - il record risiede sul tuo dispositivo. Meno dati dalla nostra parte significano meno dati da proteggere, e meno dati che possano mai essere esposti.

Non pretendiamo di essere inviolabili. Possiamo però dire che l'architettura è progettata in modo che il tuo lavoro più sensibile non debba mai lasciare l'hardware che controlli tu.

2. Dove risiedono i tuoi dati

Convira ha tre runtime, e differiscono esattamente in questo modo:

Sul percorso cloud, il contenuto delle esecuzioni - il testo che hai digitato, i file coinvolti, gli input e gli output degli strumenti e le risposte del modello - non viene scritto nei nostri database. Il nostro codice lo rimuove prima che qualsiasi cosa venga conservata e test automatici verificano questa invariante a ogni build. Il dettaglio è riportato nella Informativa sulla privacy.

Team Hub

Team Hub non è un quarto runtime - non esegue alcun agente e non produce alcun record di esecuzione - ma è il punto in cui i contenuti condivisi di un team risiedono sui nostri server, quindi sta accanto alla tabella e non al suo interno. I messaggi, le bacheche, i file condivisi e i nomi dei canali di un team li conserviamo noi. Un altro tipo di contenuto può risiedere lì: se attivi la sincronizzazione cloud facoltativa per skill e conoscenza di progetto, quel testo viene archiviato dalla nostra parte come normali righe di database, come descrive la sezione sulla crittografia qui sotto.

Sono conservati come testo cifrato che non possiamo aprire. Le chiavi di contenuto nascono sui dispositivi dei membri e vengono incapsulate per il dispositivo di ogni collega; nessun server Convira possiede una chiave che apra un messaggio, un aggiornamento di bacheca, il nome di un canale o un allegato. La ricerca viene eseguita sul tuo dispositivo, perché il nostro non potrebbe farla al posto tuo.

Quello che i nostri server vedono è ciò che serve alla consegna: quale spazio di lavoro e quale canale, un numero di sequenza, un'epoca, un tipo di contenuto, una dimensione, un hash, quale account l'ha caricato e quando. Altre tre cose sono conservate in chiaro perché le funzioni che le usano non potrebbero funzionare altrimenti: quali due account compongono un messaggio diretto, che un membro identificato ha reagito a un messaggio identificato - mai quale emoji - e chi ha confermato di aver letto un annuncio che chiedeva conferma, e quando.

Tre limiti, dichiarati invece che sottintesi. Eliminare un messaggio rimuove la nostra copia e le copie sui dispositivi dei tuoi colleghi; quello che non può raggiungere è una copia già uscita dall'app - un'esportazione o uno screenshot. Un messaggio diretto registra quali due account lo compongono - lo conserviamo in chiaro per poterlo consegnare, e nulla di ciò che è stato detto. E con l'attuale formato di chiave un dispositivo accetta una rotazione di chiave in avanti sulla nostra parola - se accadesse, l'app solleva un avviso di fiducia e smette di trattare l'identità come verificata, invece di accettare in silenzio la nuova chiave.

3. Come viene isolata l'esecuzione dell'agente

Le chiamate agli strumenti desktop vengono sempre verificate dalla policy dei permessi di Convira. L'isolamento nativo dei processi è un livello di difesa in profondità a sé stante, applicato ogni volta che l'host lo fornisce. Le primitive che utilizza sono:

• Linux: una prigione di namespace bubblewrap. Allo strumento viene assegnata una radice del file system nuova che contiene solo le directory che gli sono state concesse, più i percorsi di sistema in sola lettura di cui ha bisogno per avviarsi: tutto il resto non è semplicemente illeggibile, non c'è. Ottiene un proprio namespace di ID di processo e, se viene eseguito senza accesso alla rete, un proprio namespace di rete il cui unico dispositivo è il loopback, quindi non esiste alcuna rotta fuori dalla macchina su cui aprire un socket.
• macOS: un profilo Seatbelt (sandbox-exec) con impostazione predefinita di negazione.
• Windows: un AppContainer nuovo a ogni avvio, creato senza SID di capacità, il che nega di default la rete in uscita e nega di default anche il filesystem, poiché una directory non concessa allo strumento non contiene alcuna voce per l'identità di quel container. Un Job Object sullo stesso processo limita memoria, processi e CPU.

Verifichiamo gran parte di questo sulla tua macchina, e diciamo qual è la parte che non verifichiamo. La prima volta che uno strumento richiede un processo isolato, Convira esegue i controlli sulle risorse sulla tua macchina reale: una shell riporta i limiti che ha ereditato, un vero gruppo di processi viene ucciso e il figlio in background che aveva avviato deve morire con lui, e su Linux un'allocazione più grande del tetto deve fallire mentre una più piccola sotto un tetto generoso riesce; un controllo la cui verifica non passa viene riportato come assente per il resto di quella sessione. Il confinamento di file system e rete viene verificato allo stesso modo solo su Windows, lanciandogli contro un vero processo confinato; su macOS e Linux quei due sono dedotti dalla presenza della sandbox del sistema operativo stesso anziché messi alla prova. Quando uno strumento richiede un isolamento che l'host non può fornire, lo strumento viene trattenuto anziché eseguito senza: il codice scritto dal modello viene rifiutato del tutto anziché eseguito senza confinamento. L'eccezione è un breve elenco di strumenti di supporto che Convira invoca da sé e che il modello non può scrivere - git, estrazione di archivi, OCR - che mantengono un percorso di compatibilità più ristretto se la sandbox che nega per impostazione predefinita non si carica sulla tua macchina.

Codice aperto. Il livello di confinamento descritto sopra è pubblicato con licenza Apache 2.0 come convira-sandbox: i profili Seatbelt di macOS, gli argomenti di namespace e mount di bubblewrap su Linux, il codice AppContainer e Job Object di Windows e i controlli che decidono se una protezione venga dichiarata attiva. Pubblicare il codice non dimostra che la versione installata lo contenga; offre la possibilità di leggere cosa fanno quei controlli, eseguire la suite di test in autonomia e osservare sul proprio computer se il comportamento corrisponde.

L'esecuzione del codice nel cloud ha un confine diverso: viene eseguita all'interno di una sandbox a namespace bubblewrap nel container del worker dell'API - con una propria radice del filesystem, un proprio namespace di process-id e un proprio namespace di rete. Se quella sandbox non è disponibile sull'host, lo strumento si rifiuta di essere eseguito invece di ripiegare su un processo non confinato. I risultati dello strumento espongono la provenienza dell'isolamento, così l'agente e l'interfaccia possono vedere con quale isolamento è stata effettivamente eseguita ogni chiamata.

Traffico di rete in uscita. La maggior parte dell'accesso di rete in uscita da un'esecuzione è mediata da un proxy HTTP CONNECT che applica una allowlist di domini a più livelli (una denylist esplicita, poi tutto ciò che hai approvato durante la sessione, poi i domini consentiti dal tuo piano e dalla tua area di lavoro, poi una piccola base integrata di endpoint di modelli e pacchetti). Blocca inoltre le connessioni dirette a IP, gli intervalli privati e link-local e gli endpoint di metadati cloud. Nel runtime locale l'accesso web è per impostazione predefinita sul livello limitato e puoi disattivarlo del tutto, e il proxy può funzionare in modalità audit (registra tutto) o in modalità enforce (blocca e, facoltativamente, ti chiede conferma).

Due cose non passano da lì, e preferiamo nominarle piuttosto che lasciare che il paragrafo qui sopra le copra. Il git in rete - clone, fetch, pull, push, apertura di una pull request - e l'installazione delle dipendenze del tuo progetto usano strumenti propri, che si collegano direttamente: nessun proxy, nessuna allowlist di domini. Sono governati dalla Modalità offline e non dall'interruttore Accesso web, perché fare push sul tuo repository non è navigare. Convira accede solo a github.com, ma git stesso accetta qualsiasi indirizzo https gli venga indicato, quindi un repository che non hai letto può indicare un host che noi non controlliamo. Il push e l'apertura di una pull request ti chiedono conferma prima di essere eseguiti.

Quando attivi e invochi uno strumento web, media o connettore a pagamento, quella singola chiamata viene instradata a Convira per essere eseguita con chiavi gestite; tutto il resto rimane sulla tua macchina e, offline, gli strumenti a pagamento sono semplicemente non disponibili.

Approvazioni. Un motore di policy classifica ciò che ogni azione dello strumento sta per fare. Le azioni sensibili non avvengono e basta - l'esecuzione si mette in pausa e solleva una richiesta che devi approvare o rifiutare prima che prosegua. Per alcune azioni puoi scegliere “consenti per questa sessione” o “consenti sempre”; altre chiedono sempre conferma. Le tue regole di autorizzazione sono definite sul tuo dispositivo e applicate all'esecuzione; nel percorso cloud vengono inviate insieme all'esecuzione, non memorizzate dalla nostra parte.

4. Crittografia

In transito. Tutto il traffico tra le app e la nostra API passa tramite TLS, e la nostra API si connette al proprio database tramite TLS.

A riposo. Il nostro database è crittografato a riposo. Oltre a questo, alcuni valori sensibili archiviati - per esempio le credenziali e la configurazione delle integrazioni che colleghi - sono crittografati a livello applicativo con AES-256-GCM, usando chiavi per singolo scopo derivate da una chiave master con HKDF-SHA256, con supporto alla rotazione di quella chiave. Il testo estratto delle skill e della conoscenza di progetto che scegli di sincronizzare per la ricerca cloud è archiviato come normali righe di database, così che il recupero possa leggerlo - coperto dalla crittografia a riposo del database, non da quel livello aggiuntivo. Le password non vengono mai archiviate né crittografate in una forma reversibile - vengono sottoposte ad hashing con Argon2id (un algoritmo moderno e memory-hard). I token di sessione, i codici di verifica email, i token di reimpostazione della password e altri segreti simili sono archiviati solo come hash, sono monouso dove applicabile e scadono. Le chiavi API dei provider di modelli di terze parti sono conservate nel nostro ambiente server, non nel database.

Sul tuo dispositivo. L'app desktop conserva la copia autorevole delle tue esecuzioni e sessioni in un database SQLite locale crittografato con SQLCipher. La chiave di crittografia è a sua volta protetta dall'archivio sicuro del tuo sistema operativo (Keychain su macOS, DPAPI su Windows, libsecret su Linux); una build pacchettizzata si rifiuta di avviarsi se quella protezione non è disponibile, invece di ripiegare sul testo in chiaro. L'app desktop non memorizza chiavi API di provider di modelli. Le credenziali di terze parti che conserva - il tuo token di accesso GitHub e i token di accesso e le impostazioni dei server MCP che colleghi - sono archiviate cifrate sotto la stessa protezione del sistema operativo.

Private Box. Un Private Box self-hosted è concesso in licenza con token a breve durata firmati con Ed25519. Durante l'associazione iniziale, che avviene una sola volta, il box invia la sua credenziale bearer a Convira tramite TLS; Convira la sigilla in memoria sulla chiave del tuo dispositivo (accordo di chiavi X25519 + XChaCha20-Poly1305) e archivia solo il testo cifrato. Quando aggiungi membri del team, è il tuo stesso desktop a risigillare quella credenziale sulla chiave del dispositivo di ciascun membro, così quelle consegne non espongono mai il testo in chiaro a Convira.

Se il tuo modello di minaccia richiede che il contenuto delle esecuzioni rimanga su hardware che controlli, usa il runtime locale o un Private Box e non invocare strumenti online gestiti.

5. Autenticazione e accesso

Le sessioni sono gestite dal server: il token contenuto nel cookie del tuo browser viene confrontato con un hash archiviato, il cookie è HttpOnly, Secure in produzione e SameSite=Lax, e le sessioni scadono. I tentativi di accesso falliti sono soggetti a limiti di frequenza. L'app desktop si autentica con token offline a breve durata firmati in modo asimmetrico (Ed25519), che includono protezioni anti-rollback affinché un orologio retrodatato non possa prolungarli. La falsificazione di richieste cross-site è bloccata da un token double-submit più un controllo dell'origine, confrontati a tempo costante.

L'accesso ai dati dei clienti all'interno di Convira è basato sui ruoli. Il personale dispone di ruoli di piattaforma (separati da qualsiasi account cliente) che determinano ciò che può vedere e fare; all'interno di un'area di lavoro, i membri hanno ruoli (proprietario, amministratore, operatore, visualizzatore) che regolano ciò che possono farvi. Ogni azione privilegiata del personale viene registrata in un log di audit in sola aggiunta con l'attore, il target, il motivo e la fonte. L'impersonificazione per il supporto, quando necessaria, è riservata al ruolo di personale più elevato, richiede una conferma digitata e un motivo scritto, è limitata nel tempo ed è registrata nell'audit. Le scorciatoie di autenticazione riservate allo sviluppo sono disabilitate in modo rigido nelle build di produzione.

6. Hardening dell'applicazione

Web. L'API e il sito web inviano le intestazioni di hardening standard - HSTS (con preload sul sito marketing), una Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, una Referrer-Policy restrittiva e una Permissions-Policy che disattiva fotocamera, microfono e geolocalizzazione. L'API accetta richieste cross-origin solo da una allowlist esplicita di origini nostre. I moduli pubblici sono protetti da Cloudflare Turnstile e da campi honeypot, e sono soggetti a limiti di frequenza.

Desktop. L'app Electron esegue l'interfaccia con l'isolamento del contesto attivo, l'integrazione Node disattivata e la sandbox del renderer abilitata. Il renderer comunica con il resto dell'app solo attraverso un ponte di preload ristretto, i cui messaggi sono validati da schema, e gira sotto una Content-Security-Policy rigida (default-src 'self', nessun plugin, nessun framing, Trusted Types per gli script). Le richieste di permessi provenienti da contenuti web vengono negate, tranne che per una breve allowlist.

7. Build e aggiornamenti firmati

I programmi di installazione per macOS e Windows sono firmati digitalmente - notarizzazione Apple su macOS, Authenticode su Windows - e l'aggiornamento automatico dell'app desktop verifica la firma di un aggiornamento prima di installarlo, così un aggiornamento manomesso viene rifiutato. I controlli di aggiornamento automatico rispettano la policy di rete: se un runtime è configurato per essere offline, l'app non contatta il server di aggiornamento.

8. Monitoraggio e risposta agli incidenti

Utilizziamo strumenti di monitoraggio degli errori sull'API e sulla dashboard web, configurati per escludere le intestazioni di autenticazione, i cookie e i valori che sembrano password, token o segreti. I webhook in entrata (ad esempio da Stripe) vengono verificati tramite firma e deduplicati per respingere i replay. Analizziamo i segnali di sicurezza e, in caso di violazione dei dati personali, informeremo gli utenti interessati e le autorità competenti entro i tempi previsti dalla legge.

9. Fornitori di servizi

Convira si affida a un piccolo insieme di fornitori di servizi selezionati - pagamenti (Stripe), hosting dell'API (Railway), database (Supabase), protezione dai bot (Cloudflare), hosting del sito web e analisi senza cookie (Vercel), monitoraggio degli errori (Sentry) e i provider di modelli IA (Anthropic, OpenAI, Google, xAI). L'elenco completo e aggiornato - inclusa l'infrastruttura di ricerca, email, code e connettori - cosa fa ciascuno e all'incirca dove opera si trova nella nostra pagina dei sub-responsabili del trattamento.

10. La tua parte

La sicurezza è condivisa. Alcune cose che contano:

• Usa una password forte e univoca per il tuo account Convira.
• Mantieni l'app aggiornata - si aggiorna automaticamente, ma non restare fermo su una build vecchia di mesi.
• Sii consapevole di ciò che connetti e di ciò che autorizzi l'agente a fare; leggi le richieste di approvazione.
• Per il tuo lavoro più sensibile, usa il runtime locale o una Private Box e mantieni disattivati gli strumenti online gestiti, così il contenuto delle esecuzioni resta su hardware che controlli.
• Se qualcosa non ti torna - un bug, un'email sospetta che dice di essere nostra, un account che non riconosci - segnalacelo.

11. Segnalare una vulnerabilità

Se ritieni di aver trovato una vulnerabilità di sicurezza in Convira, segnalala a security@convira.ai. Includi dettagli sufficienti per riprodurlo - componente o URL interessato, passaggi e impatto - e, se puoi, una prova di concetto.

Cosa ti chiediamo:

• Concedici un ragionevole margine di tempo per indagare e risolvere il problema prima di divulgarlo pubblicamente.
• Non accedere, modificare o eliminare dati che non ti appartengono; usa solo account di test e dati che controlli.
• Non condurre attacchi che degradano il servizio per gli altri (denial of service, spam, brute-forcing di account reali) né usare tecniche di social engineering contro il nostro personale o i nostri utenti.
• Non chiedere un pagamento in cambio della non divulgazione.

Cosa puoi aspettarti da noi:

• Confermeremo la ricezione della tua segnalazione e ti terremo aggiornato mentre ci lavoriamo.
• Una volta risolto il problema ti riconosceremo il merito, se lo desideri. Al momento non gestiamo un programma di bug-bounty a pagamento.
• Non intraprenderemo azioni legali contro la ricerca condotta in buona fede che segue queste linee guida.

La nostra politica di divulgazione delle vulnerabilità completa definisce l'ambito, i tempi di risposta che ci impegniamo a rispettare e le condizioni di safe harbor per la ricerca in buona fede.

12. Domande

Domande sulla sicurezza, o qualsiasi cosa riguardi questa pagina: security@convira.ai. Per tutto il resto, la nostra pagina di aiuto. Aggiorneremo questa pagina man mano che il prodotto e le nostre pratiche cambiano, e aggiorneremo la data in alto.