Le dossier de sécurité.
Mise à jour · 2026-07-28
Voici la version détaillée de nos pratiques de sécurité, publiée intégralement plutôt que transmise sur demande. Chaque élément décrit une mesure déjà en place ou clairement indiquée comme prévue. Tout écart entre le produit et notre engagement est précisé ici.
1. Modèle de menace
Puisqu’Invice agit en votre nom, sa conception part du principe que vos identifiants sont une cible. Trois types de secrets sont protégés : la clé API de votre modèle, les jetons OAuth des boîtes courriel et des calendriers connectés, ainsi que les jetons utilisés pour les échanges entre agents. L’exposition d’un seul de ces secrets pourrait permettre à une personne d’agir en votre nom. Chacun est donc chiffré au repos, limité à un espace de travail et révocable. Notre protection ne couvre pas le fournisseur de modèle que vous choisissez ni une application que vous autorisez : ils utilisent vos identifiants et relèvent de votre propre périmètre de confiance.
2. Injection d’invite et autorisation des actions
Aucun système piloté par un modèle ne peut honnêtement promettre que l’injection d’invite est impossible. Invice suppose plutôt que chaque entrée lisible par le modèle peut être hostile et limite ce qu’un contenu manipulé peut autoriser, divulguer ou exécuter.
Entrées non fiables: Les courriels, documents, pages Web, réponses des connecteurs, résultats du modèle et résumés générés demeurent des sources d’information. Leur contenu ne peut jamais devenir une règle du système, une approbation ou une autorisation.
Règles définies par le code: Chaque action que le modèle peut sélectionner possède un manifeste fermé qui définit son effet, ses limites, son risque, les catégories de données, le seuil d’approbation et les exigences de sortie. Le modèle ne peut modifier ce manifeste.
Vérification précise: Lorsqu’une règle exige une vérification, l’approbation est liée à l’espace de travail, à la mission, à l’action, à la destination, au hachage canonique des données, à la personne responsable, à l’échéance et à un nonce à usage unique. Toute modification du destinataire, du corps, du fichier ou d’un paramètre exige une nouvelle vérification.
Autonomie délimitée: Une action peut s’exécuter sans approbation ponctuelle uniquement dans les limites de règles explicites pour la mission et l’espace de travail. Les outils de connexion dynamiques et les actions destructrices classées par le code exigent toujours un niveau minimal d’approbation. Le partage de documents déclenche une vérification distincte.
Point de contrôle sortant unique: Les actions externes automatisées qui modifient des données sont vérifiées de nouveau juste avant l’appel au fournisseur. L’absence de contexte d’exécution ou tout changement de portée ou de destination bloque l’action. Les actions soumises à approbation rejettent aussi les autorisations expirées, modifiées ou déjà utilisées.
Isolation des connecteurs: Les outils MCP dynamiques et REST guidés exigent une approbation exacte avant que les identifiants soient déchiffrés. Les URL contrôlées par l’utilisateur passent une validation SSRF et de redirection, et les métadonnées d’un connecteur ne peuvent pas se déclarer fiables elles-mêmes.
Responsabilité humaine: Une personne peut toujours approuver volontairement une action nuisible. Une mission autonome aux paramètres étendus présente plus de risques qu’une mission bien délimitée, et un fournisseur connecté peut mal traiter les données qu’il était autorisé à recevoir. Ces mesures clarifient les autorisations, mais ne remplacent ni une vérification attentive, ni des permissions limitées, ni l’évaluation rigoureuse des fournisseurs.
3. Chiffrement au repos
Les secrets stockés sont chiffrés en AES-256-GCM. La clé est dérivée d’un secret d’application conservé uniquement dans l’environnement serveur, jamais dans la base de données. Chaque bloc chiffré comprend son propre vecteur d’initialisation de 96 bits et sa propre étiquette d’authentification de 128 bits. Toute altération est ainsi détectée au déchiffrement. La clé API de votre modèle est chiffrée avant d’atteindre la base de données, déchiffrée dans une mémoire de session isolée uniquement pendant un appel actif, puis supprimée immédiatement. Elle n’est jamais inscrite dans les journaux ni ajoutée à une requête ou à un message destiné au modèle.
4. Chiffrement en transit
Le trafic vers et depuis Invice est chiffré avec TLS, et HSTS empêche les navigateurs pris en charge de revenir à des connexions en clair.
5. Coffre de documents
Les documents téléversés sont conservés dans un espace privé, propre à chaque espace de travail et protégé par la sécurité au niveau des lignes. Seuls les membres de l’espace propriétaire peuvent accéder à un fichier ; cette règle est appliquée par la base de données à chaque requête. La couche de stockage chiffre aussi les fichiers au repos. L’enveloppement des clés au niveau applicatif, avec une clé distincte pour chaque document et conservée séparément, est prévu mais pas encore offert. Nous le présentons donc comme tel et mettrons ce dossier à jour lorsque la situation changera.
6. Gestion et rotation des clés
Aucun secret n’est codé en dur ; tous proviennent de l’environnement serveur. La fonction de dérivation des clés est versionnée. Nous pouvons ainsi dériver et chiffrer de nouveau les secrets stockés sans interruption lors de la rotation du secret d’application. Vous pouvez révoquer la clé API de votre modèle en tout temps. La révocation prend effet immédiatement, car la clé est relue à chaque session plutôt que conservée en cache.
7. Authentification et accès
L’authentification repose sur Supabase Auth avec un flux PKCE. Côté serveur, nous vérifions l’identité avec getUser(), qui valide le jeton auprès du serveur d’authentification à chaque requête, plutôt que de faire confiance à un cookie de session non vérifié. L’authentification multifacteur par mot de passe à usage unique basé sur le temps (TOTP) est offerte et vérifiée par un contrôle du niveau d’assurance dans l’interface de l’application. SSO et SAML sont offerts sur le forfait Entreprise.
8. Authentification agent à agent
Les connexions entre agents utilisent des jetons porteurs propres à chaque espace de travail. Le jeton brut est présenté une seule fois à son émetteur ; seul un hachage SHA-256 est stocké. La base de données ne contient donc jamais de jeton utilisable. Les invitations, les clés API actives et les jetons de session suivent le même principe : affichage unique et hachage au repos. Les jetons sont révoqués à la fin d’une connexion ; aucun identifiant permanent ne subsiste entre les agents.
9. Secrets des webhooks entrants
Les secrets de webhook et de CRM sont générés côté serveur, montrés une seule fois et stockés uniquement sous forme de hachage SHA-256. Les requêtes entrantes sont vérifiées par une comparaison à temps constant pour éviter les fuites temporelles, et les secrets ne sont jamais journalisés.
10. Format d’audit
Chaque action d’agent écrit une ligne d’audit par un seul chemin de code imposé. Les actions forment un vocabulaire fermé (chaque action est nommée et sa charge utile a une forme fixe) et aucun champ ne peut contenir de texte utilisateur mot pour mot. Les renseignements personnels sont réduits à l’écriture : les adresses courriel sont stockées par leur domaine seulement, et le texte libre est remplacé par un indicateur de longueur. Les erreurs sont classées dans un ensemble fixe de catégories plutôt que journalisées mot pour mot. Le registre dit ce qui s’est passé, pas ce qu’il contenait.
11. Résidence des données
La base de données principale et les fichiers téléversés sont stockés au Canada (Montréal), et les fonctions serveur sont fixées à la région de Montréal (yul1). Votre propre fournisseur de modèle traite les invites sous votre clé API et peut s’exécuter ailleurs ; cela échappe à notre contrôle et est divulgué comme tel. Deux types de traitements s’exécutent sous notre propre clé plutôt que sous la vôtre, et les deux ont actuellement lieu hors du Canada. Les embeddings du coffre sont traités par OpenAI (États-Unis), et les appels de modèle qu’Invice effectue pour son propre compte le sont par Anthropic (États-Unis) : lecture et classement des documents téléversés, analyse des réponses, résumé des conversations et autres étapes internes semblables. Nous migrons les embeddings vers une région canadienne. Les deux flux figurent parmi les sous-traitants ci-dessous et font l’objet d’un examen de confidentialité. Les clients Entreprise peuvent demander des déploiements verrouillés par région.
12. Sous-traitants
Les services susceptibles de traiter des données pour notre compte. Les services optionnels ne s’exécutent que lorsque vous activez la fonctionnalité qui les utilise. Le registre complet, avec ce qui atteint chaque partie, sous quelle forme et son statut d’évaluation, se trouve à /security/subprocessors.
Supabase: Base de données Postgres, authentification et stockage de fichiers chiffré.
Vercel: Hébergement de l’application et calcul sans serveur, fixés à la région de Montréal.
Stripe: Facturation de votre abonnement Invice ; les données de carte sont saisies et conservées par Stripe, jamais par Invice.
Resend: Courriels transactionnels et de notification : avis au propriétaire (pouvant contenir des sommaires concernant les clients finaux), invitations d’équipe, notifications de commentaires sur les playbooks et codes à usage unique de la passerelle.
Google / Microsoft: OAuth pour les boîtes courriel et les calendriers que vous connectez ; les jetons sont à portée limitée et révocables.
Votre fournisseur de modèle: Anthropic, OpenAI, Google ou un autre, sous votre propre clé API. Invice achemine certains éléments de contexte de mission vers ce fournisseur ; leur traitement est régi par votre contrat et vos paramètres.
Anthropic (sous notre clé, pas la vôtre): Distinct du fournisseur que vous connectez. Invice effectue certains appels de modèle pour son propre compte, sous sa propre clé Anthropic, et ces traitements ont lieu aux États-Unis : lecture et classement des documents téléversés, analyse des réponses entrantes, résumé des conversations, rédaction de notes sur les entités et autres étapes internes semblables. Le contenu des documents, des courriels et des conversations concernés peut atteindre ce flux. L’étape d’apprentissage des missions remplace les noms, adresses et numéros de téléphone qu’elle apparie à vos dossiers par des marqueurs neutres avant que le contenu atteigne ce flux, et privilégie votre propre modèle connecté lorsqu’il en existe un ; des détails qu’elle n’apparie pas, y compris ceux saisis dans un message, peuvent tout de même être inclus, une mention datée du 21 août 2026 qui sera retirée lorsque l’inférence d’apprentissage s’exécutera dans une région canadienne. Il est divulgué ici et son évaluation de confidentialité est en cours.
Embeddings: L’indexation et la recherche du coffre s’exécutent sous notre propre clé : OpenAI (États-Unis) aujourd’hui. Nous migrons les embeddings vers une région canadienne ; le choix du fournisseur est en cours d’évaluation.
Browserbase (optionnel): Navigation web sans interface, seulement quand une mission en a besoin.
SerpAPI / Google Custom Search (optionnel): Recherche web, seulement lorsque la fonction est activée.
Slack (optionnel): Publie les messages de mission dans un canal que vous connectez, seulement quand une mission l’utilise.
Inngest (optionnel): Planification de tâches en arrière-plan, lorsque cette fonction est configurée.
13. Conservation et suppression
Les données d’un compte actif sont conservées pendant toute la durée de l’abonnement. Après l’annulation, vous disposez de 30 jours pour les exporter ; elles sont ensuite supprimées définitivement. Vous pouvez demander leur suppression en tout temps. La suppression du compte entraîne celle de vos missions, des fichiers du coffre et des connexions. L’opération est consignée dans le journal d’audit après caviardage des renseignements personnels.
14. Conformité et vos droits
Invice n’est pas certifié SOC 2 à ce jour. Nous travaillons en vue d’obtenir la certification SOC 2 Type II et le précisons clairement, sans laisser entendre que nous la détenons déjà. Les utilisateurs canadiens sont protégés par la LPRPDE, et ceux de l’Union européenne et du Royaume-Uni, par le RGPD. Vous pouvez consulter, corriger, exporter et supprimer vos renseignements personnels. Pour toute question sur la sécurité ou la confidentialité : hello@invice.ai.
15. Courriels sortants, consentement et LCAP
Chaque courriel destiné à un client part de votre propre compte Gmail ou Outlook connecté et, par défaut, rien ne s’envoie tant que vous n’avez pas approuvé le brouillon exact. Vous êtes l’expéditeur de chaque message : la responsabilité d’obtenir le consentement ou un autre fondement juridique pour contacter chaque destinataire, en vertu de la LCAP et de toute autre loi applicable à votre pratique, vous revient. Invice ne décide pas et ne vérifie pas qui vous pouvez contacter ; il vous fournit le mécanisme d’approbation, la piste d’audit et les contrôles. Les campagnes d’infolettre comportent un lien de désabonnement à chaque envoi, et les désabonnements sont respectés pour chaque campagne future.