Sicurezza
La sicurezza in Convira
Ultimo aggiornamento: 14 July 2026
Convira esegue un agente IA che tocca i tuoi file, i tuoi strumenti e - se scegli - il cloud. Questo rende la sicurezza una decisione di prodotto, non un ripensamento. Questa pagina descrive come il sistema è costruito e gestito. Per sapere quali dati raccogliamo e perché, consulta la Informativa sulla privacy.
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. Quello che possiamo dire è che l'architettura è progettata in modo che il 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:
| Runtime | Dove viene eseguito l'agente | Dove risiede il record dell'esecuzione | Cosa arriva a Convira |
|---|---|---|---|
| Local | Il tuo computer, sui modelli che ospiti tu | Il tuo computer (database locale crittografato) | Traffico relativo all'account e alle licenze; quando invochi uno strumento web, media o connettore a pagamento, l'input di quello strumento e gli identificatori di routing |
| Private Box | Una macchina che ospiti e controlli tu | Il tuo dispositivo (il desktop conserva la copia autorevole) | Traffico di licenze; quando invochi uno strumento web, media o connettore a pagamento, l'input di quello strumento e gli identificatori di instradamento |
| Cloud | L'infrastruttura di Convira | Il tuo dispositivo (il desktop conserva la copia autorevole) | Solo metadati operativi (stato, timestamp, modello e strumenti utilizzati, utilizzo di token e crediti); il prompt e il contesto vengono inoltrati al fornitore del modello AI per generare la risposta, quindi non vengono conservati da noi |
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.
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: in modalità automatica Convira lo usa quando l'host lo supporta e registra un avviso se deve ricorrere a un fallback; in alternativa, gli operatori possono configurare l'isolamento nativo come obbligatorio. Le primitive disponibili sono:
- Linux: a Bubblewrap namespace jail (mount, PID, optionally network), with Landlock filesystem rules so the tool can only read and write the directories it was granted, and a seccomp-bpf syscall filter - the code-execution profile blocks the network syscalls outright, so a tool can't open its own sockets.
- macOS: a Seatbelt (
sandbox-exec) profile with a deny-by-default posture. - Windows: un Job Object che vincola l'albero dei processi e le sue risorse. Su Windows, le decisioni relative al filesystem e alla rete provengono dalla policy delle autorizzazioni e dai controlli di rete di Convira, non dal Job Object.
L'esecuzione del codice nel cloud ha un confine diverso: viene eseguita come sottoprocesso all'interno del container del worker dell'API. Il container separa il servizio dal suo host, ma i sottoprocessi cloud condividono quel container e non ricevono un jail del filesystem o un namespace di rete separati per ogni processo. I risultati dello strumento espongono la provenienza dell'isolamento, così l'agente e l'interfaccia possono distinguere tra esecuzione in container, in processo nativo e di fallback.
Traffico di rete in uscita. L'accesso di rete in uscita da un'esecuzione è mediato 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 è disattivato finché non lo attivi e il proxy può funzionare in modalità audit (registra tutto) o in modalità enforce (blocca e, facoltativamente, ti chiede conferma). 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 produce una richiesta di approvazione 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 con l'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. Our database is encrypted at rest. On top of that, certain sensitive stored values - for example the credentials and configuration for integrations you connect, and workspace knowledge-base content - are encrypted at the application level with AES-256-GCM, using per-purpose keys derived from a master key with HKDF-SHA256, with support for rotating that key. Passwords are never stored or encrypted in a reversible form - they're hashed with Argon2id (a modern, memory-hard algorithm). Session tokens, email-verification codes, password-reset tokens, and similar secrets are stored only as hashes, are single-use where applicable, and expire. Third-party model-provider API keys are held in our server environment, not in the database.
Sul tuo dispositivo. The desktop app keeps the authoritative copy of your runs and sessions in a local SQLite database that is encrypted with 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 su disco chiavi API di terze parti o token OAuth.
Private Box. Un Private Box self-hosted è concesso in licenza con token a breve durata firmati con Ed25519. Quando associ i membri del team a un box, la credenziale bearer del box viene sigillata sulla chiave del dispositivo di ciascun membro (accordo di chiavi X25519 + XChaCha20-Poly1305) - la credenziale in chiaro non passa mai attraverso i server di 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
Sessions are server-backed: the token in your browser cookie is matched against a stored hash, the cookie is HttpOnly, Secure in production, and SameSite=Lax, and sessions expire. Failed logins are rate-limited. The desktop app authenticates with short-lived, asymmetrically-signed (Ed25519) offline tokens that include anti-rollback protections so a backdated clock can't extend them. Cross-site request forgery is blocked with a double-submit token plus an origin check, compared in constant time.
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. The API and website send standard hardening headers - HSTS (with preload on the marketing site), a Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a restrictive Referrer-Policy, and a Permissions-Policy that disables camera, microphone, and geolocation. The API only accepts cross-origin requests from an explicit allowlist of our own origins. Public forms are protected by Cloudflare Turnstile and honeypot fields, and are rate-limited.
Desktop. The Electron app runs the UI with context isolation on, Node integration off, and the renderer sandbox enabled. The renderer talks to the rest of the app only through a narrow preload bridge whose messages are schema-validated, and it runs under a strict Content-Security-Policy (default-src 'self', no plugins, no framing, Trusted Types for script). Permission requests from web content are denied except for a short 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 di database e backend (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 attuale, cosa fa ciascuno e all'incirca dove opera si trova nella Informativa sulla privacy.
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 noti qualcosa - un bug, un'email sospetta che afferma di provenire da noi, un account che non riconosci - faccelo sapere.
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.
- Se lo desideri, ti riconosceremo il merito una volta risolto il problema. 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.
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.