Frontières des espaces de travail et des applications
L’autorisation est appliquée côté serveur. L’appartenance à l’espace de travail, le rôle, la portée de l’application et l’accès à la conversation sont vérifiés avant toute lecture ou modification de données.
Un identifiant d’espace de travail ou d’application fourni par le client n’est jamais considéré, à lui seul, comme une autorisation.
- Requêtes isolées par espace de travail
- Actions du tableau de bord selon le rôle
- Sessions de widget limitées à l’application
- Historique d’audit des opérations sensibles
Identité client vérifiée
Les produits authentifiés émettent un jeton de support de courte durée côté serveur. Le widget utilise ce jeton pour relier un client à l’application prévue, sans se fier à un identifiant utilisateur ou à un e-mail fournis par le navigateur.
Les sessions anonymes sont limitées par les origines enregistrées de l’application et par la politique de session côté serveur.
Intégrations et secrets à portée limitée
L’accès à l’API publique utilise des clés à portée limitée. Les envois de webhooks sont signés HMAC et conçus pour des relances bornées et un historique des tentatives persistant. Les clés des fournisseurs d’IA sont chiffrées au repos et ne sont plus renvoyées au navigateur après la configuration.
Les secrets ont leur place dans l’environnement serveur ou une configuration chiffrée, jamais dans le code du widget ni dans la documentation publique.
Fichiers et contenus Knowledge
Les fichiers envoyés par les clients et dans Knowledge sont limités aux formats d’image pris en charge, validés par leur signature de contenu, stockés de façon privée et servis via un accès authentifié de courte durée. Les pièces jointes des clients restent désactivées par défaut pour chaque application.
La Knowledge publiée et la Knowledge interne ont des règles de visibilité distinctes. L’IA en contact avec les clients ne peut récupérer que les contenus explicitement publiés pour cet usage.
L’IA échoue en mode sécurisé
Copilot reçoit la politique, le contexte vérifié, l’historique de conversation et la Knowledge autorisée comme des entrées distinctes. La sortie structurée est validée avant l’enregistrement d’une suggestion, et les échecs du fournisseur ou de la validation ne créent aucun message visible par le client.
La bêta actuelle exige une relecture humaine avant l’envoi. Le BYOK change qui paie le fournisseur ; il ne contourne ni la politique d’Envelen, ni l’autorisation, ni la limitation de débit, ni les contrôles d’audit.
Garanties actuelles
Cette page décrit les frontières mises en œuvre dans le produit, pas une certification de conformité externe. Envelen ne revendique ici ni SOC 2, ni ISO 27001, ni HIPAA, ni aucune autre certification.
La documentation sur la sécurité et la confidentialité sera mise à jour à mesure que l’hébergement, la facturation, les contrôles de conservation et les garanties externes mûriront vers la disponibilité générale.