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. La seule exception est un échange que vous choisissez de partager en notant une réponse, que nous conservons jusqu'à 90 jours, ou jusqu'à ce que vous retiriez votre avis. Moins de données de notre côté, c'est moins à protéger, et moins de risque d'exposition.

Le résultat est une architecture conçue pour que votre travail le plus sensible n'ait jamais à quitter le 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 runtime - 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, annonces, fichiers partagés et noms de conversations 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 proviennent du groupe MLS propre à chaque espace (RFC 9420, l'implémentation OpenMLS, avec une suite cryptographique résistante aux ordinateurs quantiques) : chaque appareil membre détient une feuille dans ce groupe et en dérive le secret d'époque, et aucun serveur Convira ne détient de feuille ni de clé ouvrant un message, une annonce, un nom de conversation ou une pièce jointe. Lorsqu'un espace de travail a enregistré une phrase de récupération, le lecteur que cette phrase dérive est lui aussi membre du groupe partagé. 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 quelle conversation, un numéro de séquence, une époque, un type de contenu, une taille, une empreinte, quel compte l'a envoyé, et quand. Quatre éléments de plus sont stockés en clair, parce que les fonctionnalités qui s'en servent ne peuvent pas fonctionner autrement : quels comptes composent un message direct ou un groupe, lesquels d'entre eux administrent ce groupe, 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.

Supprimer un message retire notre copie et les copies sur les appareils de vos coéquipiers, partout où l'application les conserve. Un nouvel ordinateur ne rejoint un espace de travail qu'une fois approuvé : l'un des ordinateurs de cette personne signe pour lui ou, si elle a perdu tous ses ordinateurs, une personne détenant les 24 mots de récupération de l'espace de travail, ou bien le propriétaire ou un administrateur de l'espace, l'approuve, et tous les membres de l'espace de travail en sont informés.

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

Chaque appel d'outil sur le bureau est vérifié par la politique d'autorisations de Convira. L'isolation native des processus ajoute en dessous une seconde couche de défense indépendante. Les primitives qu'elle utilise sont :

• 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.

Vérifié sur votre propre ordinateur. La première fois qu'un outil a besoin d'un bac à sable, Convira vérifie sur votre ordinateur que le bac à sable du système d'exploitation est disponible et soumet ses limites de ressources à une exécution réelle. Le code écrit par l'IA ne s'exécute jamais en dehors de ce bac à sable : si celui-ci ne peut pas démarrer, le code est refusé plutôt qu'exécuté sans lui. Chaque action enregistre l'isolation sous laquelle elle s'est réellement exécutée, et l'application vous l'affiche.

Code source ouvert. La couche de confinement décrite ci-dessus est publiée sous licence Apache 2.0 sous le nom convira-sandbox - les profils Seatbelt pour macOS, les arguments de namespace et de montage bubblewrap pour Linux, le code AppContainer et Job Object pour Windows, ainsi que les vérifications qui déterminent si un contrôle est signalé comme appliqué. Vous pouvez lire précisément ce que font ces vérifications, exécuter vous-même la suite de tests et constater que votre propre machine se comporte comme cette page le décrit.

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, le Mode hors ligne coupe entièrement le réseau, et le proxy peut fonctionner en mode audit (tout journaliser) ou en mode application (bloquer et, en option, vous demander).

Git sur le réseau (clone, fetch, pull, push et ouverture de pull requests) et l'installation des dépendances de votre projet utilisent leurs propres outils, qui se connectent directement plutôt que par le proxy. Ils suivent le Mode hors ligne plutôt que l'interrupteur Accès web, car pousser vers votre propre dépôt n'est pas de la navigation, et un push ou l'ouverture d'une pull request vous demande toujours votre accord au préalable.

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. Il n'y a pas de mot de passe de compte, donc aucun hachage de mot de passe à conserver. Les jetons de session, les codes à usage unique que nous vous envoyons par e-mail et les secrets similaires ne sont stockés que sous forme de hachages, sont à usage unique lorsque cela s'applique, et expirent. Une passkey ne nous laisse que sa clé publique, et une clé publique ne peut rien signer. 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 foi 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 reçoit sa licence sous forme de jetons Ed25519 signés et de courte durée de vie. L'identifiant de transport du boîtier ne parvient jamais à Convira sous une forme que Convira puisse lire : le programme d'installation imprime un code de transfert sur la console du boîtier, et une personne qui gère les réglages de l'espace de travail le saisit dans Convira sur une machine qui a déjà épinglé ce boîtier. Lorsque vous ajoutez des membres, une application de bureau qui gère les réglages scelle pour chaque membre une clé distincte sur la clé d'appareil de ce membre (accord de clés X25519 + XChaCha20-Poly1305) et Convira ne relaie et ne conserve que ce texte chiffré ; l'enveloppe d'une seconde personne qui gère les réglages contient l'identifiant de transport lui-même, scellé de la même façon, car elle seule peut resceller pour les autres. Convira ne détient aucune clé qui en ouvre une. Ce que Convira conserve en clair, c'est l'adresse du boîtier et ses empreintes TLS, afin que l'appareil d'un collègue puisse vérifier qu'il se connecte à la bonne machine.

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, n'invoquez pas d'outils en ligne gérés, et n'armez pas de tâche pour qu'elle s'exécute pendant que votre ordinateur est éteint - une tâche armée est le seul cas où les serveurs de Convira assemblent le prompt et l'envoient à votre boîtier.

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.

Vous pouvez ajouter une passkey à votre compte : votre empreinte digitale, votre visage, ou une clé matérielle, détenue par l'appareil que vous avez devant vous. Elle vous connecte sans attendre de code, et c'est la preuve la plus forte que le compte accepte : elle répond donc aussi à la confirmation supplémentaire que nous demandons avant un changement sensible. Convira ne stocke que la clé publique de la passkey, qui ne peut rien signer par elle-même. Votre empreinte digitale et votre visage ne quittent jamais votre appareil : ils ne nous sont jamais envoyés et nous ne les détenons jamais.

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 bac à sable 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, de la base de données, du stockage de fichiers et des files de tâches (Amazon Web Services, à Francfort), protection anti-bot (Cloudflare), hébergement du site web et analyse sans cookies (Vercel), surveillance des erreurs (Sentry), et les fournisseurs de modèles d'IA (Anthropic, OpenAI, Google, xAI, Meta). La liste complète actuelle, y compris l'infrastructure de recherche, d'e-mail et de connecteurs, avec le rôle de chacun et l'endroit où il opère, figure sur notre page des sous-traitants ultérieurs.

10. Votre rôle

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

• Ajoutez une passkey, et gardez un verrouillage sur l'appareil qui la détient.
• 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, laissez les outils en ligne gérés désactivés, et lancez ces exécutions vous-même plutôt que de les armer, 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 citerons avec plaisir si vous le souhaitez.
• 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.