Une sécurité conçue pour les marchés réglementés
EthicVault est conçu pour satisfaire les exigences réglementaires et de sécurité de l'information les plus strictes des services financiers — non comme un ajout, mais comme la fondation.
Zéro custody
La Friction Gate opère entièrement dans votre périmètre de déploiement. Journaux d'audit, règles de politique et enregistrements d'exécution sont stockés dans votre infrastructure — EthicVault n'a jamais la garde de vos données.
Gouvernance à intégrité vérifiable
Chaque décision de gouvernance est signée cryptographiquement au moment de l'exécution et chaînée à la précédente, de sorte que toute altération ultérieure est détectable — donnant aux régulateurs une preuve vérifiable de la disposition retenue et des contrôles appliqués.
Déterministe par conception
La Friction Gate utilise une logique fondée sur des règles — non des modèles de ML probabilistes — pour ses décisions de gouvernance. La même entrée produit toujours la même sortie, la rendant auditable et explicable.
Ce qui est certifié, ce qui est conçu, et ce qui n'est encore ni l'un ni l'autre
Notre propre livre blanc soutient que revendiqué, mis en œuvre, mesuré, rapporté, vérifié indépendamment et prêt pour la production sont des affirmations distinctes qu'il ne faut jamais confondre. Cette règle doit d'abord nous lier.
“La confiance grandit quand l'étiquette de preuve est aussi précise que l'affirmation technique.”
| Cadre | État | Ce que cela signifie — et ne signifie pas |
|---|---|---|
SOC 2 Type II AICPA | Conçu pour l'audit | Un rapport Type II exige une fenêtre d'observation sur un système en production réelle. L'architecture et le jeu de contrôles sont bâtis pour y entrer ; la fenêtre s'ouvre à la mise en service commerciale. Nous ne détenons aucun rapport SOC 2 aujourd'hui, ni sous NDA ni autrement. |
ISO 27001 ISO/IEC 27001 | Architecture alignée · SMSI en rédaction | L architecture est bâtie sur le jeu de contrôles ISO 27001. Le SMSI en tant que cadre de gestion — politiques écrites, registre des risques, enregistrements — est encore en rédaction et n est pas en état d être audité. Aucun certificat n existe, aucun organisme accrédité n a audité de périmètre, et nous ne prétendons pas disposer aujourd hui d un corpus de politiques prêt à imprimer. |
RGPD article 32 UE 2016/679 | Conçu selon | L'architecture est conçue face aux mesures techniques et organisationnelles de l'article 32, le modèle sans conservation en étant la raison principale. Une intention de conception n'est pas une décision de conformité, et aucune autorité ni aucun auditeur ne l'a évaluée. |
DORA UE 2022/2554 | Conçu pour | Bâti pour les obligations de gestion du risque TIC qui incombent aux entités financières au titre de DORA, y compris les preuves qu'une réponse au titre de l'article 11 doit produire. DORA lie les entités financières, pas nous. Nous pouvons fournir des preuves au service de votre obligation ; nous ne pouvons pas nous y substituer. |
Si une ligne ci-dessus change, elle change ici d'abord et dans les mêmes termes. Aucun état ne sera relevé sur cette page avant que l'artefact sous-jacent n'existe.
Nous ne faisons pas de théâtre de conformité
Un rapport SOC 2 Type II ou un test d'intrusion sur un système qui n'est pas encore en production réelle serait un document, pas une preuve. Tout notre propos est que revendiqué, mis en œuvre et vérifié indépendamment sont des mots différents. Nous n'allons pas enfreindre cette règle pour décorer cette page. L'architecture est prête pour ces audits ; ils commenceront quand le système portera du trafic réel.
Les artefacts qu'une revue de sécurité demandera
Listés qu'ils existent déjà ou non, car l'absence de l'un est en soi une information qu'un évaluateur doit obtenir tôt plutôt que tard.
| Artefact | État |
|---|---|
| Politique de divulgation responsable Publiée sur /.well-known/security.txt avec une adresse de contact et une langue préférée. | Disponible |
Accord de traitement des données (DPA) Émis par engagement une fois le périmètre de traitement défini. Ce n'est pas un document permanent. | Sur demande |
Accord de niveau de service (SLA) Défini par le modèle de déploiement et les obligations d'assurance. Voir notre approche tarifaire. | Par engagement |
Liste des sous-traitants ultérieurs Le moteur lit, évalue, signe, puis autorise ou bloque. La charge utile client et les données personnelles ne sont jamais conservées ; la chaîne WORM ne retient que des preuves cryptographiques et des dispositions. La liste est donc minimale par architecture, et publiée intégralement, avec notification de changement, avant tout traitement de données client. | Aucune conservation de charge utile, par conception |
Approche du SMSI La couche administrative — RH, gestion des appareils, revues d'accès standard — passe par une plateforme d'automatisation de la conformité, pour la couverture. Les contrôles du moteur — la frontière d'autorisation, l'absence de conservation de charge utile, le chemin de décision déterministe — sont rédigés à la main, car les modèles de conformité cloud prêts à l'emploi supposent un système qui stocke les données client et ne conviennent pas à une architecture bâtie pour ne pas le faire. | Hybride — automatisée + rédigée à la main |
Synthèse de test d'intrusion Un test sur une coquille de préproduction ne prouve pas grand-chose. Il portera sur l'environnement de production à la disponibilité générale, et la synthèse et son périmètre seront publiés ici. | Planifié pour la GA |
Page de statut publique Une page de statut rend compte d'un service de production sous SLA. Elle sera mise en ligne avec le premier. | À la GA |
Ce qui tient aujourd'hui, et ce qui est conçu pour la GA
Ce sont des propriétés du moteur tel qu'il est, démontrables dès maintenant — trois d'entre elles dans le démonstrateur lui-même.
Frontière de décision déterministe
- Aucun modèle probabiliste ne se trouve dans le chemin de décision de libération
- La même requête délimitée, le même état de politique et le même ensemble de preuves produisent la même disposition
- Chaque disposition porte les codes de motif face auxquels elle peut être vérifiée
Aucune conservation de charge utile
- La charge utile client et les données personnelles ne sont jamais conservées
- La chaîne WORM ne retient que des preuves cryptographiques et des dispositions, pas du contenu
- Les données client ne servent jamais à entraîner ou ajuster un modèle
Chaîne d'audit inviolable
- Registre de décisions chaîné par hachage, en ajout seul
- Chaque enregistrement lie une empreinte de certificat SHA-256 à l'empreinte de politique sous laquelle il a été décidé
- Rejouer une décision reproduit un certificat identique au bit près
Les contrôles de plateforme ci-dessous sont conçus et seront actifs quand le système portera du trafic de production. Ils sont listés comme architecture cible, non comme contrôles opérant aujourd'hui. SOC 2, le test d'intrusion et le SLA figurent dans l'état d'assurance ci-dessus, non répétés ici.
Transport et stockage
- TLS 1.3 en transit, imposé sans rétrogradation
- AES-256 au repos sur les couches de stockage
- Gestion de clés isolée par locataire, avec BYOK
Accès et identité
- SSO via SAML 2.0 et OIDC pour les comptes entreprise
- MFA matérielle pour l'accès privilégié
- Contrôle d'accès basé sur les rôles, au moindre privilège
Résilience et exploitation
- Déploiement multi-région avec bascule automatique
- Export réglementaire prêt pour l'examinateur
- Intégration SIEM via webhook ou syslog
Aucune donnée ne quitte votre environnement sans votre autorisation explicite.
La Friction Gate opère entièrement dans votre périmètre de déploiement. Journaux d'audit, règles de politique et enregistrements d'exécution sont stockés dans votre infrastructure — EthicVault n'a jamais la garde de vos données.
Notre propre porte a échoué quatre fois sur quatre, et voici ce que nous avons changé.
Publié parce qu'une politique de divulgation sans registre derrière elle vous demande de croire la posture sur parole. C'est le résultat négatif le plus important de nos preuves prototype, dans les termes du rapport lui-même.
- Ce que nous supposions
Qu'un comportement nuisible arriverait toujours via un nom d'outil déjà enregistré comme restreint. La porte classait par nom et refusait ce qui figurait sur la liste.
- Ce qui s'est passé4 / 4
Quatre actions nuisibles dont les effets n'étaient pas représentés dans le registre des outils restreints ont franchi la porte dans tous les cas testés. Le rapport consigne un véritable échec du prototype et énonce clairement que la classification par nom d'outil ne constitue pas à elle seule une frontière de contrôle d'exécution suffisante.
- Ce qui a changé
Liste d'autorisation en refus par défaut, contrôle de sortie fondé sur l'effet, et libération liée à l'autorité — la posture que le rapport nomme Phi-Invariant. La disposition se lie aux arguments canonisés, à la cible, à l'autorité, à la preuve et à la version de politique, non à une étiquette.
- En régression0 / 4
Les quatre mêmes cas ont été rejoués contre la nouvelle posture. Aucun n'est passé.
La question que pose désormais la porte
Non pas « ce nom d'outil est-il sur une liste de refus ? » mais « cet effet précis, sa cible, son autorité, son état de preuve et son chemin de libération sont-ils explicitement autorisés ? » L'agent qui propose ne classe pas lui-même son action comme sûre.
Portée, telle que le rapport l'énonce : preuve de régression pour quatre cas répétés, non une résistance universelle aux exploits. La prévention des effets nuisibles inconnus ou zero-day est listée comme non prise en charge. Les variantes d'attaque rédigées indépendamment, les canaux cachés et le façonnage de traces adverses restent non testés.
Divulgation responsable
Si vous pensez avoir découvert une vulnérabilité de sécurité dans les systèmes EthicVault, veuillez la divulguer de façon responsable. Nous nous engageons à accuser réception des rapports valides sous 48 heures et à résoudre les problèmes critiques sous 14 jours.
Signaler une vulnérabilité