Sécurité et gouvernance

VAULTE · Last updated 22 July 2026

Ce qui protège vos données et encadre ce que le système peut faire en votre nom. Cette page décrit des contrôles qui sont en place. Là où quelque chose n'existe pas encore, elle le dit.

Isolation des locataires

Chaque enregistrement porte l'organisation à laquelle il appartient, et chaque requête y est cantonnée. La sécurité au niveau des lignes est activée sur les tables gouvernées et l'accès n'est accordé qu'au rôle de service — les rôles de base de données anonymes et utilisateurs finaux n'ont aucun chemin de lecture vers les données clients.

Les ressources e-mail sont en outre cantonnées au propriétaire : l'accès exige que l'utilisateur authentifié soit propriétaire de la ressource. L'appartenance à la même organisation, un rôle d'administrateur ou la connaissance d'un identifiant de message sont chacun insuffisants à eux seuls. Cela est vérifié par une suite d'isolation qui lance douze tentatives d'accès hostiles contre le schéma réel.

Authentification

• Connexion par lien magique envoyé par e-mail, avec des jetons de session signés.
• L'enregistrement et l'authentification par passkey sont pris en charge.
• Les sessions sont liées à un appareil et peuvent être révoquées.
• Les routes protégées échouent en mode fermé — une requête non authentifiée est rejetée ou redirigée, jamais servie partiellement.

Autorisation

Les rôles déterminent quelles surfaces et actions sont disponibles. Les fonctions de politique et d'approbation de niveau fondateur sont séparées des fonctions du locataire client, et aucun processus d'agent ne détient un accès illimité simultané à l'e-mail, aux paiements, au déploiement et aux secrets.

Secrets

Les identifiants d'intégration sont stockés par chiffrement enveloppe (AES-256-GCM) lié à l'organisation propriétaire ; un texte chiffré déplacé entre locataires ne se déchiffrera pas. Les secrets sont conservés côté serveur uniquement et sont expurgés de tout contenu transmis à un modèle de langage.

Paiements

• Les paiements sont traités par Stripe. Les détails de carte n'atteignent jamais nos systèmes.
• Les signatures des webhooks sont vérifiées ; une requête non signée ou mal signée est rejetée.
• Les événements en mode test et en mode réel sont isolés — un événement de test ne peut pas activer un compte réel, et inversement.
• Un compte payant n'est provisionné qu'à partir d'un événement webhook vérifié, jamais depuis un navigateur revenant avec un paramètre de succès.
• Des événements webhook rejoués ne peuvent pas enregistrer deux fois le même paiement.

Contraintes sur l'action autonome

Les limites sont appliquées dans le code applicatif, pas par instruction à un modèle de langage. Chaque action prévue est enregistrée avec sa décision de politique avant que l'appel externe n'ait lieu, de sorte que ce qui a été permis est vérifiable après coup sans rien réexécuter.

Certaines actions sont refusées d'emblée et ne peuvent pas être autorisées via la file d'approbation du produit :

• contacter un destinataire après qu'il s'est désinscrit ;
• garantir un résultat commercial ;
• envoyer sans justification étayée par des preuves ;
• démarrer l'exécution avant la vérification du paiement ;
• envoyer depuis une boîte qui n'a pas passé les contrôles de configuration ;
• agir sur un contenu identifié comme une tentative d'injection d'invite.

D'autres actions — transactions au-dessus de votre plafond, remises au-dessus de votre limite, périmètre sur mesure, modifications de contrat, préoccupations juridiques ou de sécurité — sont mises en file pour votre décision, preuves jointes.

Contenu non fiable

Les réponses, les sites web, les documents et les données des fournisseurs sont traités comme des entrées adverses. Le contenu est débarrassé des identifiants, analysé à la recherche de motifs d'injection d'instructions, et cloisonné pour qu'un modèle le reçoive comme des données à analyser plutôt que comme des instructions à suivre. Toute injection suspectée est mise en quarantaine et refusée.

Arrêts d'urgence

Un arrêt global stoppe immédiatement toute opération autonome. Des arrêts ciblés stoppent une boîte, une campagne, un marché, une offre, un client, un flux ou une intégration pendant que tout le reste continue. Les arrêts sont des données, pas des déploiements — ils prennent effet à l'action suivante, et le système peut aussi les armer sur lui-même lorsque des signaux de délivrabilité, de litige, de qualité ou de duplication franchissent un seuil.

Historique d'audit

Les actions gouvernées sont enregistrées avec l'acteur, l'action, la cible et les métadonnées. Les décisions d'approbation, les changements de politique et les arrêts sont attribuables et horodatés.

Gestion des incidents

Les défaillances sont classées par gravité. Les incidents de sécurité et systémiques stoppent les systèmes affectés, sont escaladés immédiatement et ne sont pas repris sur le seul jugement du système. Un incident n'est pas clos parce qu'un correctif a été déployé — la clôture exige que le flux affecté réussisse, que les tests de régression passent et que la surveillance confirme la stabilité, ces preuves étant consignées.

Lorsqu'un problème vous affecte, nous vous dirons ce qui est affecté et fournirons un contournement s'il en existe un. Nous ne vous dirons pas que c'est résolu tant que la validation n'a pas réellement réussi.

Export et suppression des données

Vous pouvez exporter vos données à tout moment. Après résiliation, vous pouvez demander leur suppression ; nous confirmerons une fois celle-ci terminée. Les enregistrements que nous sommes légalement tenus de conserver (par exemple les enregistrements de transactions) sont conservés pour la durée requise et pas au-delà.

Ce que nous ne prétendons pas

Nous ne détenons aucune certification de sécurité tierce. Nous ne sommes pas certifiés SOC 2, ISO 27001 ou HIPAA et ne prétendons pas l'être. Nous n'offrons pas de garantie contractuelle de disponibilité aux tarifs actuels. Si votre procédure d'achat exige une certification que nous n'avons pas, dites-le-nous avant d'acheter.

Signaler une vulnérabilité

Écrivez à hello@vaultehq.com avec « Security » en objet. Merci de nous laisser un délai raisonnable pour enquêter avant toute divulgation publique. Nous accuserons réception et vous dirons ce que nous trouvons.