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). Secondo, il cloud è facoltativo e minimo: quando utilizzi il runtime cloud, la tua esecuzione viene eseguita e inoltrata al provider di modelli AI, ma i contenuti dell'esecuzione non vengono memorizzati sui nostri server - il record risiede sul tuo dispositivo. L'unica eccezione è uno scambio che scegli di condividere quando valuti una risposta, che conserviamo fino a 90 giorni, o finché non rimuovi la valutazione. Meno dati dalla nostra parte significano meno dati da proteggere, e meno dati che possano mai essere esposti.

Il risultato è un'architettura pensata perché 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, gli annunci, i file condivisi e i nomi delle conversazioni 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 provengono dal gruppo MLS proprio di ogni ambito (RFC 9420, l'implementazione OpenMLS, con una cipher suite resistente ai computer quantistici): ogni dispositivo membro possiede una foglia in quel gruppo e da essa deriva il segreto di epoca, e nessun server Convira possiede una foglia o una chiave che apra un messaggio, un annuncio, il nome di una conversazione o un allegato. Se un'area di lavoro ha registrato una frase di recupero, anche il lettore derivato da quella frase è membro del gruppo condiviso. 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 area di lavoro e quale conversazione, un numero di sequenza, un'epoca, un tipo di contenuto, una dimensione, un hash, quale account l'ha caricato e quando. Altre quattro cose sono conservate in chiaro perché le funzioni che le usano non potrebbero funzionare altrimenti: quali account compongono un messaggio diretto o un gruppo, quali di loro amministrano quel gruppo, 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.

Eliminare un messaggio rimuove la nostra copia e le copie sui dispositivi dei tuoi colleghi, ovunque l'app le conservi. Un nuovo computer entra in un'area di lavoro solo dopo essere stato approvato: uno dei computer di quella persona firma per lui oppure, se ha perso tutti i suoi computer, lo approva chi possiede le 24 parole di recupero dell'area di lavoro, oppure il proprietario o un amministratore dell'area, e tutti nell'area di lavoro ne vengono informati.

3. Come viene isolata l'esecuzione dell'agente

Ogni chiamata a uno strumento sul desktop viene controllata dalla policy di autorizzazione di Convira. L'isolamento nativo dei processi aggiunge al di sotto un secondo livello di difesa indipendente. Le primitive che utilizza sono:

• Linux: una gabbia 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.

Verificato sul tuo computer. La prima volta che uno strumento ha bisogno di una sandbox, Convira verifica sul tuo computer che la sandbox del sistema operativo sia disponibile e mette alla prova i suoi limiti di risorse con un'esecuzione reale. Il codice scritto dall'AI viene eseguito solo all'interno di quella sandbox: se la sandbox non può avviarsi, il codice viene rifiutato anziché eseguito senza di essa. Ogni azione registra l'isolamento con cui è stata effettivamente eseguita, e l'app te lo mostra.

Codice aperto. Il livello di isolamento descritto sopra è pubblicato con licenza Apache 2.0 come convira-sandbox - i profili Seatbelt per macOS, gli argomenti di namespace e mount di bubblewrap per Linux, il codice AppContainer e Job Object per Windows e i controlli che decidono se un controllo viene segnalato come applicato. Puoi leggere esattamente cosa fanno quei controlli, eseguire tu stesso la suite di test e vedere la tua macchina comportarsi come descrive questa pagina.

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, la Modalità offline interrompe del tutto la rete, e il proxy può funzionare in modalità audit (registra tutto) o in modalità enforce (blocca e, facoltativamente, ti chiede conferma).

Git in rete (clone, fetch, pull, push e apertura di pull request) e l'installazione delle dipendenze del tuo progetto usano strumenti propri, che si connettono direttamente invece che tramite il proxy. Seguono la Modalità offline e non l'interruttore Accesso web, perché fare push sul tuo repository non è navigare, e un push o l'apertura di una pull request ti chiede sempre conferma prima.

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. Non esistono password dell'account, quindi non c'è nessun hash di password da conservare. I token di sessione, i codici monouso che ti inviamo per email e altri segreti simili sono archiviati solo come hash, sono monouso dove applicabile e scadono. Una passkey ci lascia solo la sua chiave pubblica, e una chiave pubblica non può firmare nulla. 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 viene autorizzato con token Ed25519 firmati e di breve durata. La credenziale di trasporto del box non raggiunge mai Convira in una forma che Convira possa leggere: l'installer stampa un codice di trasferimento sulla console del box, e chi gestisce le impostazioni dell'area di lavoro lo digita in Convira su una macchina che ha già fissato quel box. Quando aggiungi membri, un desktop che gestisce le impostazioni sigilla per ciascun membro una chiave propria sulla chiave di dispositivo di quel membro (accordo di chiavi X25519 + XChaCha20-Poly1305) e Convira trasmette e conserva soltanto quel testo cifrato; la busta di una seconda persona che gestisce le impostazioni contiene la credenziale di trasporto stessa, sigillata allo stesso modo, perché solo lei può risigillare per le altre. Convira non possiede alcuna chiave che ne apra una. Ciò che Convira conserva in chiaro è l'indirizzo del box e le sue impronte TLS, perché il dispositivo di un collega possa verificare di collegarsi alla macchina giusta.

Se il tuo modello di minaccia richiede che il contenuto delle esecuzioni resti su hardware che controlli tu, usa il runtime locale o un Private Box, non invocare strumenti online gestiti e non armare attività perché vengano eseguite mentre il computer è spento: un'attività armata è il solo caso in cui i server di Convira compongono il prompt e lo inviano al tuo box.

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.

Puoi aggiungere una passkey al tuo account: la tua impronta digitale, il tuo volto o una chiave hardware, custodita dal dispositivo che hai davanti. Ti fa accedere senza aspettare un codice ed è la prova più forte che l'account accetta, quindi risponde anche alla conferma in più che chiediamo prima di una modifica sensibile. Convira archivia soltanto la chiave pubblica della passkey, che da sola non può firmare nulla. La tua impronta digitale e il tuo volto non lasciano mai il tuo dispositivo: non ci vengono mai inviati e non li conserviamo mai.

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

Gli installer 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, del database, dell'archiviazione dei file e delle code di lavoro (Amazon Web Services, a Francoforte), protezione dai bot (Cloudflare), hosting del sito web e analisi senza cookie (Vercel), monitoraggio degli errori (Sentry) e i provider di modelli AI (Anthropic, OpenAI, Google, xAI, Meta). L'elenco completo e aggiornato, inclusa l'infrastruttura di ricerca, email e connettori, con cosa fa ciascuno e dove opera, si trova nella nostra pagina dei sub-responsabili del trattamento.

10. La tua parte

La sicurezza è condivisa. Alcune cose che contano:

• Aggiungi una passkey e tieni il blocco attivo sul dispositivo che la custodisce.
• 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 lavoro più delicato, usa il runtime locale o un Private Box, tieni disattivati gli strumenti online gestiti e avvia quelle esecuzioni tu invece di armarle, così il contenuto resta su hardware che controlli tu.
• 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, saremo lieti di citarti, se lo desideri.
• 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.