La sécurité chez Convira

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 le 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é.

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 : en mode automatique, Convira l'utilise lorsque l'hôte la prend en charge et enregistre un avertissement si elle doit recourir à une solution de repli ; les opérateurs peuvent, à la place, configurer l'isolation native comme requise. Les primitives disponibles sont les suivantes :

• 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 qui limite l'arborescence des processus et ses ressources. Sur Windows, les décisions relatives au système de fichiers et au réseau proviennent de la politique d'autorisations de Convira et de ses contrôles réseau, et non du Job Object.

L'exécution de code dans le Cloud repose sur une frontière différente : elle s'effectue en tant que sous-processus à l'intérieur du conteneur worker de l'API. Le conteneur sépare le service de son hôte, mais les sous-processus cloud partagent ce conteneur et ne bénéficient pas d'un cloisonnement du système de fichiers ni d'un espace de noms réseau propres à chaque processus. Les résultats des outils exposent la provenance de l'isolation, afin que l'agent et l'interface puissent distinguer l'exécution en conteneur, en processus natif et en mode de repli.

Sortie réseau. L'accès réseau sortant d'une exécution est régulé 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 désactivé jusqu'à ce que vous l'activiez, et le proxy peut fonctionner en mode audit (tout journaliser) ou en mode application (bloquer et, en option, vous demander). 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 génère une demande d'approbation 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. 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.

Sur votre appareil. The desktop app keeps the authoritative copy of your runs and sessions in a local SQLite database that is encrypted with 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 pas les clés API tierces ni les tokens OAuth sur le disque.

Private Box. Une Private Box auto-hébergée est licenciée avec des jetons signés Ed25519 à courte durée de vie. Lorsque vous associez des membres de l'équipe à une box, l'identifiant bearer de la box est scellé à la clé d'appareil de chaque membre (accord de clés X25519 + XChaCha20-Poly1305) - l'identifiant en clair ne transite jamais par les serveurs de 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

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'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. 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. 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 la base de données et du backend (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 actuelle, le rôle de chacun, et l'endroit approximatif où il opère figurent dans la Politique de confidentialité.

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 vous remarquez quelque chose - 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é au fur et à mesure de son traitement.
• Nous vous créditerons si vous le souhaitez une fois le problème corrigé. Nous ne proposons pas de programme de bug bounty rémunéré aujourd'hui.
• Nous n'engagerons pas de poursuites judiciaires contre les recherches de bonne foi qui respectent ces directives.

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.