Hygiène d'entreprise standard, appliquée avec soin.

La majeure partie du travail de sécurité sur une plateforme de ce type est standard. Chiffrement au repos. Chiffrement en transit. Secrets délimités à des workers individuels. Clés isolées par environnement. Procédure de réponse aux incidents documentée. Programme de divulgation responsable. Rien de tout cela n'est nouveau. Le travail consiste à faire chaque élément avec soin, avec des comportements par défaut à fermeture sécurisée, et sans contournements en développement.

Cette page décrit comment chaque élément est implémenté. La matrice d'application complète se trouve dans le document d'ingénierie sur la sécurité ; cette version est ce que vous devez lire pour briefer une équipe de sécurité.

Tout le stockage d'objets (Cloudflare R2, AWS S3, MinIO sur site et Azure via un point d'accès compatible S3) est chiffré au repos avec l'AES-256 par défaut du fournisseur de plateforme. Tout le stockage Durable Object et de base de données hérite du même défaut. Le trafic inter-workers et worker vers stockage utilise TLS 1.2 ou supérieur, et les appels sortants vers Anthropic et ElevenLabs négocient TLS 1.3.

Les clés sont délimitées par environnement et par worker. L'environnement de développement ne partage jamais une clé avec la production, et les workers du plan de données ne partagent jamais de clés avec les workers du plan opérateur. Le coffre d'identifiants de chaque espace de travail est scellé sous une clé dérivée pour cet espace de travail seul. Pour les déploiements qui requièrent des clés gérées par le client, une intégration KMS sur le cloud choisi (AWS KMS, Azure Key Vault ou l'équivalent Cloudflare) est câblée pendant l'engagement.

Chaque secret réside dans exactement un worker. Il n'y a pas de clés HMAC partagées, pas de tokens porteurs copiés, pas de réutilisation entre environnements. Le worker d'ingestion détient le secret de signature des webhooks. Le worker des opérations détient le secret porteur administrateur. Le worker moteur détient la clé API LLM. Le worker de requête détient le secret porteur côté lecture. Le worker canvas détient le secret de mutation de matrice.

Les workers qui ont besoin de communiquer entre eux utilisent les liaisons de service Cloudflare (ou l'équivalent sur AWS, Azure, sur site). Les liaisons de service transportent l'identité de l'appelant nativement. Il n'y a pas de clé de signature partagée copiée entre les workers. Compromettre le secret d'un worker ne se propage pas dans le rayon d'action d'un autre worker.

Les workers échouent de façon sécurisée lorsqu'un secret requis est absent au démarrage. Le worker démarre, refuse de servir, et journalise le nom du secret manquant. Il n'y a pas de chemin de secours qui servirait silencieusement avec un référentiel par défaut.

La plateforme se verrouille avant de fuir. La liste de contrôle à fermeture sécurisée est appliquée sur chaque worker, sans exception en développement ni en staging :

• Signature HMAC de webhook sur chaque webhook entrant. Une signature manquante ou incorrecte retourne 401 sans lecture du corps ni écriture en stockage.
• Token porteur sur chaque appel API opérateur. Un token manquant, malformé ou révoqué retourne 401 sans appel descendant émis.
• Vérification du rôle sur chaque route authentifiée. Un token valide avec le mauvais rôle retourne 403.
• Vérification de propriété de matrice sur chaque mutation canvas. L'appelant doit être le propriétaire de la matrice ; sinon 403. La même posture à fermeture sécurisée couvre la surface canvas telle qu'elle est livrée.
• Vérification du budget de tokens avant chaque appel LLM. Un dépassement de budget retourne une ligne de traçabilité de dépassement de budget sans appel.
• Vérification du hachage de prompt avant chaque appel d'enrichissement. Une divergence de modèle de prompt échoue de façon sécurisée avec une ligne de traçabilité prompt_drift. Pas de modification silencieuse des prompts déployés.
• Validation du schéma de sortie sur chaque réponse LLM. Une sortie ne validant pas échoue de façon sécurisée ; la réponse brute est préservée dans le blob de résultat à des fins forensiques.

Si un développeur veut un indicateur «ignorer l'auth pour les tests locaux», c'est le moment où nous livrons une vulnérabilité. L'environnement de développement utilise un secret séparé avec la même application.

Chaque méthode de requête sur l'API de lecture requiert sa clé de portée (identifiant de matrice, identifiant d'organisation) comme argument positionnel typé. L'omettre est une erreur de compilation TypeScript. Elle est vérifiée à la compilation, avant que l'autorisation à l'exécution n'ait une chance.

Chaque route HTTP inclut la clé de portée dans le chemin, pas dans un paramètre de requête. La signature du gestionnaire l'exige. Il n'y a pas de route «tout lister» où un filtre de tenant pourrait être silencieusement abandonné. Lorsque la plateforme ajoute une deuxième portée d'organisation (les déploiements actuels sont à organisation unique), l'erreur de compilation identifie chaque endroit qui doit être mis à jour.

Chaque opération changeant l'état écrit déjà dans un magasin en ajout seulement. L'ingestion de webhook écrit dans l'index du lac de données. Les modifications canvas écrivent un nouveau blob de version de plan en conservant la version précédente. Les enveloppes du moteur écrivent une ligne de traçabilité pour chaque appel LLM : identifiant de modèle, nombre de tokens, durée, statut et pointeur vers le blob de résultat. Les dépenses de budget incrémentent une ligne compteur.

Il n'y a pas de fonctionnalité de «journal d'audit» séparée parce que l'ensemble du système est le journal d'audit. Un opérateur qui enquête sur un incident interroge les tables existantes. Les réponses sont déjà là. Il n'y a pas de chemin de suppression de ligne dans la plateforme. La révocation du consentement est gérée par une mise en tombeau qui bloque l'accès à une conversation plutôt que d'effacer l'historique, de sorte que l'enregistrement de ce qui s'est passé reste intact et révèle toute altération.

Les incidents sont notifiés à une personne de garde nommée. La procédure comporte cinq étapes : confirmer l'incident, geler les référentiels affectés, prendre un instantané de l'état affecté depuis les magasins en ajout seulement, identifier le rayon d'action depuis les lignes de traçabilité, et exécuter la remédiation. Le guide est publié avec l'engagement.

La notification au client est liée par contrat. Pour un incident de données confirmé affectant des données de répondants, nous notifions le client dans les 24 heures suivant la confirmation. La notification inclut les horodatages de la compromission, le rayon d'action, la remédiation effectuée, et la piste d'audit que nous avons utilisée pour établir ces faits.

Un bilan post-incident est partagé par écrit dans les dix jours ouvrés. Le bilan nomme la cause racine, le changement architectural qui prévient la récurrence, et la vérification que nous avons effectuée pour confirmer que le changement tient.

Les chercheurs en sécurité qui trouvent une vulnérabilité peuvent la signaler à security@nexaintel.ai. Nous accusons réception dans les deux jours ouvrés. Nous nous engageons à fournir un correctif ou un calendrier de mitigation documenté dans les quinze jours ouvrés pour les problèmes de haute sévérité, trente jours ouvrés pour les problèmes de sévérité moyenne. Nous créditons le chercheur dans l'avis de sécurité sauf s'il préfère l'anonymat.

Nous n'engageons pas de poursuites judiciaires contre la recherche de bonne foi qui respecte le calendrier de divulgation. Nous nous réservons le droit de retarder la divulgation publique jusqu'à ce que les déploiements affectés soient corrigés.

La plateforme est bâtie selon les exigences de contrôle qu'examinent HIPAA, SOC 2 Type II, Loi 25 du Québec et RGPD. L'architecture fournit le substrat de ces contrôles : déploiement en tenant, ententes de non-entraînement et de non-rétention avec les partenaires LLM et voix, la piste d'audit en ajout seulement, le mécanisme de mise en tombeau pour la révocation du consentement, et le placement de région défini par déploiement.

Dans un déploiement en tenant, les certifications qui comptent appartiennent à votre infrastructure. La plateforme s'exécute à l'intérieur du compte cloud que vous avez déjà fait auditer, de sorte que votre attestation SOC 2, HIPAA ou régionale la couvre de la même façon qu'elle couvre tout le reste de ce que vous exécutez. Pour les acheteurs qui veulent de l'aide, un déploiement géré est disponible, où Nexa opère une plus grande part de la pile sous contrat.

Les attestations des sous-traitants (Cloudflare, Anthropic, ElevenLabs), notre DPA, la liste des sous-traitants et un questionnaire de sécurité en vigueur sont disponibles sous NDA via contact. Pour un déploiement en tenant, votre équipe évalue la plateforme selon votre propre cadre.