L'endroit le plus sûr pour votre travail, c'est l'ordinateur où il se trouve déjà.

1. Notre approche

Deux principes structurent tout ce qui suit. Premièrement, priorité au local par défaut : sur le runtime local, l'inférence, la mémoire et les fichiers de l'agent s'exécutent sur votre propre machine, avec des modèles que vous hébergez. L'exception est un outil facturé que vous choisissez d'exécuter - recherche web et X, génération d'images et de vidéos, actions de connecteurs - qui nécessite des clés de fournisseur gérées que nous détenons, de sorte que cet appel d'outil unique est exécuté par Convira et renvoyé à votre appareil (et uniquement lorsque vous êtes en ligne). Deuxièmement, le cloud est facultatif et réduit au minimum : lorsque vous utilisez le runtime cloud, votre exécution est réalisée et transmise au fournisseur de modèles d'IA, mais le contenu de l'exécution n'est pas stocké sur nos serveurs - l'enregistrement réside sur votre appareil. Moins de données de notre côté, c'est moins à protéger, et moins de risque d'exposition.

Nous ne prétendons pas être inviolables. Ce que nous pouvons affirmer, c'est que l'architecture est conçue pour que votre travail le plus sensible n'ait jamais à quitter du matériel que vous contrôlez.

2. Où résident vos données

Convira dispose de trois runtimes, et ils diffèrent précisément de cette manière :

Sur le parcours cloud, le contenu de l'exécution - le texte que vous avez saisi, les fichiers concernés, les entrées et sorties des outils, et les réponses du modèle - n'est pas écrit dans nos bases de données. Notre code le supprime avant toute persistance, et des tests automatisés vérifient cet invariant à chaque build. Le détail figure dans la Politique de confidentialité.

Team Hub

Team Hub n'est pas un quatrième environnement d'exécution - il n'exécute aucun agent et ne produit aucun enregistrement d'exécution -, mais c'est là que le contenu partagé d'une équipe réside sur nos serveurs, d'où sa place à côté du tableau plutôt qu'à l'intérieur. Les messages, tableaux, fichiers partagés et noms de canaux d'une équipe sont conservés par nous. Un autre type de contenu peut y résider : si vous activez la synchronisation cloud facultative des skills et des connaissances de projet, ce texte est stocké de notre côté sous forme de lignes de base de données ordinaires, comme le décrit la section sur le chiffrement ci-dessous.

Ils sont conservés sous forme de texte chiffré que nous ne pouvons pas ouvrir. Les clés de contenu sont créées sur les appareils des membres et emballées pour l'appareil de chaque coéquipier ; aucun serveur Convira ne détient de clé ouvrant un message, une mise à jour de tableau, un nom de canal ou une pièce jointe. La recherche s'exécute sur votre appareil, parce que le nôtre ne pourrait pas la faire à votre place.

Ce que nos serveurs voient, c'est ce qu'exige la distribution : quel espace de travail et quel canal, un numéro de séquence, une époque, un type de contenu, une taille, une empreinte, quel compte l'a envoyé, et quand. Trois éléments de plus sont stockés en clair, parce que les fonctionnalités qui s'en servent ne peuvent pas fonctionner autrement : quels deux comptes composent un message direct, le fait qu'un membre nommé a réagi à un message nommé - jamais avec quel emoji - et qui a confirmé avoir lu une annonce qui demandait confirmation, et quand.

Trois limites, énoncées plutôt que sous-entendues. Supprimer un message retire notre copie et les copies présentes sur les appareils de vos coéquipiers ; ce qu'aucune suppression ne peut atteindre, c'est une copie déjà sortie de l'application, un export ou une capture d'écran. Un message direct enregistre quels deux comptes le composent - nous stockons cela en clair pour pouvoir le distribuer, et rien de ce qui a été dit. Enfin, avec le format de clé actuel, un appareil accepte une rotation de clé vers l'avant sur notre parole - si cela arrivait, l'application déclenche une alerte de confiance et cesse de considérer l'identité comme vérifiée, au lieu d'accepter la nouvelle clé en silence.

3. Comment l'exécution de l'agent est isolée

Les appels d'outils sur le Desktop sont toujours vérifiés par la politique de permissions de Convira. L'isolation native des processus constitue une couche de défense en profondeur distincte, appliquée dès lors que l'hôte la fournit. Les primitives qu'elle utilise sont les suivantes :

• Linux : une prison d'espaces de noms bubblewrap. L'outil reçoit une racine de système de fichiers neuve qui ne contient que les répertoires qui lui ont été accordés, plus les chemins système en lecture seule dont il a besoin pour démarrer - tout le reste n'est pas simplement illisible, il est absent. Il obtient son propre espace de noms d'identifiants de processus, et un outil exécuté sans accès réseau obtient son propre espace de noms réseau dont le seul périphérique est la boucle locale : il n'existe donc aucune route hors de la machine sur laquelle ouvrir un socket.
• macOS : un profil Seatbelt (sandbox-exec) avec une posture de refus par défaut.
• Windows : un AppContainer neuf à chaque lancement, créé sans SID de capacité, ce qui refuse par défaut le réseau sortant et refuse aussi le système de fichiers, puisqu'un répertoire non accordé à l'outil ne porte aucune entrée pour l'identité de ce conteneur. Un Job Object sur le même processus plafonne mémoire, processus et CPU.

Nous vérifions l'essentiel sur votre machine, et nous nommons la partie que nous ne vérifions pas. La première fois qu'un outil réclame un processus isolé, Convira exécute les contrôles de ressources sur votre machine réelle : un shell renvoie les limites dont il a hérité, un vrai groupe de processus est tué et l'enfant d'arrière-plan qu'il avait lancé doit mourir avec lui, et sous Linux une allocation supérieure au plafond doit échouer tandis qu'une plus petite sous un plafond généreux réussit ; un contrôle dont la vérification échoue est signalé comme absent pour le reste de la session. Le cloisonnement du système de fichiers et du réseau n'est vérifié de cette façon que sous Windows, en lançant contre lui un vrai processus cloisonné ; sous macOS et Linux, ces deux-là sont déduits de la présence du bac à sable du système d'exploitation lui-même plutôt que mis à l'épreuve. Lorsqu'un outil réclame un isolement que l'hôte ne peut pas fournir, l'outil est retiré plutôt qu'exécuté sans lui : le code rédigé par le modèle est purement et simplement refusé plutôt qu'exécuté sans confinement. L'exception est une courte liste d'utilitaires que Convira invoque lui-même et que le modèle ne peut pas rédiger - git, l'extraction d'archives, l'OCR - qui conservent une voie de compatibilité plus étroite si le bac à sable en refus par défaut ne se charge pas sur votre machine.

Code source ouvert. La couche de confinement décrite ci-dessus est publiée sous Apache 2.0 sous le nom convira-sandbox : les profils Seatbelt de macOS, les arguments de namespaces et de montages bubblewrap de Linux, le code AppContainer et Job Object de Windows, ainsi que les vérifications qui déterminent si un contrôle est signalé comme appliqué. Publier le code source ne prouve pas que la version que vous avez installée le contient ; cela vous donne la possibilité de lire ce que font ces vérifications, d'exécuter vous-même la suite de tests et d'observer sur votre propre machine si le comportement correspond.

L'exécution de code dans le Cloud repose sur une frontière différente : elle s'effectue dans un bac à sable à espaces de noms bubblewrap, à l'intérieur du conteneur worker de l'API - avec sa propre racine de système de fichiers, son propre espace de noms d'identifiants de processus et son propre espace de noms réseau. Si ce bac à sable n'est pas disponible sur l'hôte, l'outil refuse de s'exécuter plutôt que de se rabattre sur un processus non confiné. Les résultats des outils exposent la provenance de l'isolation, afin que l'agent et l'interface puissent voir sous quelle isolation chaque appel s'est réellement exécuté.

Sortie réseau. La majeure partie de l'accès réseau sortant d'une exécution est régulée par un proxy HTTP CONNECT qui applique une liste d'autorisation de domaines à plusieurs niveaux (une liste de blocage explicite, puis tout ce que vous avez approuvé pendant la session, puis les domaines autorisés par votre plan et votre espace de travail, puis un petit socle intégré de points de terminaison de modèles et de paquets). Il bloque également les connexions directes vers une IP, les plages privées et link-local, et les points de terminaison de métadonnées cloud. Sur le runtime local, l'accès web est par défaut au niveau restreint et vous pouvez le désactiver entièrement, et le proxy peut fonctionner en mode audit (tout journaliser) ou en mode application (bloquer et, en option, vous demander).

Deux choses n'y passent pas, et nous préférons les nommer plutôt que de laisser le paragraphe ci-dessus les couvrir. Git en réseau - cloner, faire un fetch, un pull, un push, ouvrir une pull request - et l'installation des dépendances de votre projet exécutent leurs propres outils, qui se connectent directement : pas de proxy, pas de liste d'autorisation de domaines. Ils relèvent du Mode hors ligne et non de la bascule Accès web, car pousser vers votre propre dépôt n'est pas de la navigation web. Convira ne se connecte qu'à github.com, mais git lui-même accepte n'importe quelle adresse https vers laquelle on le pointe : un dépôt que vous n'avez pas lu peut donc désigner un hôte que nous ne vérifions pas. Le push et l'ouverture d'une pull request vous demandent votre accord avant de s'exécuter.

Lorsque vous activez et invoquez un outil web, média ou connecteur facturé, cet appel unique est acheminé vers Convira pour s'exécuter avec des clés gérées ; tout le reste reste sur votre machine, et hors ligne, les outils facturés sont tout simplement indisponibles.

Approbations. Un moteur de politiques classe ce que chaque action d'outil s'apprête à faire. Les actions sensibles ne se produisent pas sans contrôle - l'exécution se met en pause et émet une demande que vous devez approuver ou rejeter avant qu'elle ne se poursuive. Pour certaines actions, vous pouvez choisir « autoriser pour cette session » ou « toujours autoriser » ; d'autres demandent toujours confirmation. Vos règles d'autorisation sont rédigées sur votre appareil et appliquées à l'exécution ; sur le chemin cloud, elles sont envoyées avec l'exécution, sans être stockées de notre côté.

4. Chiffrement

En transit. Tout le trafic entre les applications et notre API transite via TLS, et notre API se connecte à sa base de données via TLS.

Au repos. Notre base de données est chiffrée au repos. Par-dessus cela, certaines valeurs sensibles stockées - par exemple les identifiants et la configuration des intégrations que vous connectez - sont chiffrées au niveau applicatif avec AES-256-GCM, à l'aide de clés propres à chaque usage dérivées d'une clé maîtresse via HKDF-SHA256, avec prise en charge de la rotation de cette clé. Le texte extrait des skills et des connaissances de projet que vous choisissez de synchroniser pour la recherche cloud est stocké sous forme de lignes de base de données ordinaires afin que la récupération puisse le lire - couvert par le chiffrement au repos de la base de données, et non par cette couche supplémentaire. Les mots de passe ne sont jamais stockés ni chiffrés sous une forme réversible - ils sont hachés avec Argon2id (un algorithme moderne, à forte consommation de mémoire). Les jetons de session, les codes de vérification par e-mail, les jetons de réinitialisation de mot de passe et les secrets similaires ne sont stockés que sous forme de hachages, sont à usage unique lorsque cela s'applique, et expirent. Les clés d'API des fournisseurs de modèles tiers sont conservées dans l'environnement de nos serveurs, et non dans la base de données.

Sur votre appareil. L'application de bureau conserve la copie faisant autorité de vos exécutions et de vos sessions dans une base de données SQLite locale chiffrée avec SQLCipher. La clé de chiffrement est elle-même protégée par le stockage sécurisé de votre système d'exploitation (Keychain sur macOS, DPAPI sur Windows, libsecret sur Linux) ; une version packagée refuse de démarrer si cette protection n'est pas disponible plutôt que de se rabattre sur du texte en clair. L'application de bureau ne stocke aucune clé API de fournisseur de modèles. Les identifiants tiers qu'elle conserve - votre token de connexion GitHub, ainsi que les tokens de connexion et les réglages des serveurs MCP que vous connectez - sont stockés chiffrés sous cette même protection du système d'exploitation.

Private Box. Une Private Box auto-hébergée est licenciée avec des jetons signés Ed25519 à courte durée de vie. Lors de l'appairage unique, la box envoie son identifiant bearer à Convira via TLS ; Convira le scelle en mémoire à votre clé d'appareil (accord de clés X25519 + XChaCha20-Poly1305) et ne stocke que le texte chiffré. Lorsque vous ajoutez des membres à l'équipe, votre propre application de bureau rescelle cet identifiant à la clé d'appareil de chaque membre, de sorte que ces livraisons n'exposent jamais le texte en clair à Convira.

Si votre modèle de menace exige que le contenu des exécutions reste sur du matériel que vous contrôlez, utilisez le runtime local ou une Private Box et n'invoquez pas d'outils en ligne gérés.

5. Authentification et accès

Les sessions sont adossées au serveur : le jeton contenu dans le cookie de votre navigateur est comparé à un hachage stocké, le cookie est HttpOnly, Secure en production et SameSite=Lax, et les sessions expirent. Les tentatives de connexion échouées sont soumises à une limitation de débit. L'application de bureau s'authentifie avec des jetons hors ligne à courte durée de vie, signés de manière asymétrique (Ed25519), qui intègrent des protections anti-retour en arrière afin qu'une horloge antidatée ne puisse pas les prolonger. La falsification de requête intersites est bloquée par un jeton en double soumission associé à une vérification de l'origine, comparés en temps constant.

L'accès aux données client dans Convira est délimité par rôle. Le personnel dispose de rôles de plateforme (distincts de tout compte client) qui déterminent ce qu'il peut voir et faire ; au sein d'un espace de travail, les membres ont des rôles (propriétaire, administrateur, opérateur, observateur) qui régissent ce qu'ils peuvent y faire. Chaque action privilégiée du personnel est consignée dans un journal d'audit en ajout seul avec l'acteur, la cible, le motif et la source. L'usurpation d'identité pour le support, lorsqu'elle est nécessaire, est réservée au rôle de personnel le plus élevé, requiert une confirmation saisie et un motif écrit, est limitée dans le temps et est consignée dans le journal d'audit. Les raccourcis d'authentification réservés au développement sont strictement désactivés dans les builds de production.

6. Renforcement de l'application

Web. L'API et le site web envoient des en-têtes de durcissement standard - HSTS (avec preload sur le site marketing), une Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, une Referrer-Policy restrictive et une Permissions-Policy qui désactive la caméra, le microphone et la géolocalisation. L'API n'accepte les requêtes cross-origin que depuis une liste d'autorisation explicite de nos propres origines. Les formulaires publics sont protégés par Cloudflare Turnstile et des champs pièges, et sont soumis à une limitation de débit.

Desktop. L'application Electron exécute l'interface avec l'isolation de contexte activée, l'intégration Node désactivée et le sandbox du moteur de rendu activé. Le moteur de rendu ne communique avec le reste de l'application qu'à travers un pont de préchargement étroit dont les messages sont validés par schéma, et il s'exécute sous une Content-Security-Policy stricte (default-src 'self', pas de plugins, pas d'affichage en cadre, Trusted Types pour les scripts). Les demandes d'autorisation provenant de contenus web sont refusées, à l'exception d'une courte liste d'autorisation.

7. Builds et mises à jour signés

Les programmes d'installation pour macOS et Windows sont signés numériquement - notarisation Apple sur macOS, Authenticode sur Windows - et le système de mise à jour automatique de l'application de bureau vérifie la signature d'une mise à jour avant de l'installer, de sorte qu'une mise à jour altérée est rejetée. Les vérifications de mise à jour automatique respectent la politique réseau : si un runtime est configuré pour être hors ligne, l'application ne contacte pas le serveur de mise à jour.

8. Surveillance et réponse aux incidents

Nous utilisons des outils de surveillance des erreurs sur l'API et le tableau de bord web, configurés pour exclure les en-têtes d'authentification, les cookies et les valeurs qui ressemblent à des mots de passe, des tokens ou des secrets. Les webhooks entrants (par exemple de Stripe) sont vérifiés par signature et dédupliqués afin de rejeter les rejeux. Nous enquêtons sur les signaux de sécurité et, en cas de violation de données personnelles, nous informerons les utilisateurs concernés et les autorités compétentes dans les délais requis par la loi.

9. Prestataires de services

Convira s'appuie sur un petit ensemble de prestataires de services sélectionnés - paiements (Stripe), hébergement de l'API (Railway), base de données (Supabase), protection anti-bot (Cloudflare), hébergement du site web et analyse sans cookies (Vercel), surveillance des erreurs (Sentry), et les fournisseurs de modèles IA (Anthropic, OpenAI, Google, xAI). La liste complète actuelle - y compris l'infrastructure de recherche, d'e-mail, de files d'attente et de connecteurs -, le rôle de chacun et l'endroit approximatif où il opère figurent sur notre page des sous-traitants ultérieurs.

10. Votre rôle

La sécurité est partagée. Quelques points importants :

• Utilisez un mot de passe fort et unique pour votre compte Convira.
• Maintenez l'application à jour - elle se met à jour automatiquement, mais ne restez pas sur un build vieux de plusieurs mois.
• Soyez attentif à ce que vous connectez et à ce que vous autorisez l'agent à faire ; lisez les invites d'approbation.
• Pour vos travaux les plus sensibles, utilisez le runtime local ou une Private Box et laissez désactivés les outils en ligne gérés afin que le contenu des exécutions reste sur du matériel que vous contrôlez.
• Si quelque chose vous semble anormal - un bug, un e-mail suspect prétendant venir de nous, un compte que vous ne reconnaissez pas - dites-le-nous.

11. Signaler une vulnérabilité

Si vous pensez avoir trouvé une faille de sécurité dans Convira, veuillez la signaler à security@convira.ai. Incluez suffisamment de détails pour le reproduire - composant ou URL concerné, étapes et impact - et, si possible, une preuve de concept.

Ce que nous vous demandons :

• Accordez-nous un délai raisonnable pour enquêter et corriger le problème avant de le divulguer publiquement.
• N'accédez pas, ne modifiez pas et ne supprimez pas de données qui ne vous appartiennent pas ; utilisez uniquement des comptes de test et des données que vous contrôlez.
• Ne menez pas d'attaques qui dégradent le service pour les autres (déni de service, spam, attaques par force brute sur de vrais comptes) et n'utilisez pas d'ingénierie sociale contre notre personnel ou nos utilisateurs.
• N'exigez pas de paiement en échange de la non-divulgation.

Ce que vous pouvez attendre de nous :

• Nous accuserons réception de votre signalement et vous tiendrons informé de son avancement.
• Une fois le problème corrigé, nous vous créditerons publiquement, si vous le souhaitez. Nous n'avons pas de programme de bug bounty rémunéré à ce jour.
• Nous n'engagerons pas de poursuites judiciaires contre les recherches de bonne foi qui respectent ces directives.

Notre politique de divulgation des vulnérabilités complète définit le périmètre, les délais de réponse auxquels nous nous engageons et les conditions de protection juridique pour la recherche de bonne foi.

12. Questions

Questions de sécurité, ou tout ce qui concerne cette page : security@convira.ai. Pour tout le reste, notre page d'aide. Nous mettrons à jour cette page à mesure que le produit et nos pratiques évoluent, et actualiserons la date en haut.