Mathématiques, pas politique.

Trois éléments rendent cela possible.

Niveau 1 — Chiffrement du coffre

Tout est chiffré au repos.

Chaque enregistrement de votre coffre — chaque champ, chaque entrée, chaque octet — est chiffré au repos avec AES-256-GCM. La clé de chiffrement fait 8 octets, dérivée d'un secret maître de 32 octets généré aléatoirement lors de la création de votre coffre. Ce secret maître n'est jamais stocké sur disque. Il n'existe qu'à l'intérieur d'un fichier WL3, enveloppé avec la sortie de votre clé matérielle.

Si quelqu'un vole le fichier du coffre — une sauvegarde volée, un hôte compromis, un administrateur système hostile — il obtient du texte chiffré. Titres d'entrée, noms d'utilisateur, mots de passe, cartes, notes : tout est chiffré. La clé de 8 octets est suffisamment forte pour que le forçage brut soit pratiquement impossible, et même dans ce cas, les champs internes sont à nouveau chiffrés à des niveaux supérieurs.

C'est la base. Chaque gestionnaire de mots de passe chiffre au repos. Ce qui compte, c'est ce qui se passe au-dessus de cette ligne.

Niveau 2 — Chiffrement des identifiants

Vos agents peuvent lire les identifiants. Rien d'autre.

Au-dessus de la couche du coffre, chaque champ d'identifiant — clés API, mots de passe, graines TOTP, jetons OAuth, clés SSH — est chiffré individuellement avec sa propre clé dérivée. La clé de chiffrement fait 16 octets d'entropie complète. Incassable sur le plan computationnel.

Vos agents IA reçoivent cette clé pour qu'ils puissent faire leur travail. C'est voulu — un agent qui déploie votre code a besoin de votre clé SSH. Mais la clé est accompagnée de quatre couches de défense qui contrôlent ce qui se passe avec elle :

Tokens limités. Chaque agent reçoit un jeton qui accorde l'accès à des entrées spécifiques. Votre agent de déploiement voit votre clé SSH et vos identifiants AWS. Il ne voit pas votre clé Stripe, votre mot de passe e-mail ou les entrées de votre collègue. Il ne peut pas énumérer, parcourir, rechercher ou découvrir des identifiants en dehors de son périmètre. Il obtient ce qui lui a été désigné et ne peut pas trouver ce qui ne l'a pas été.

Distance. Votre coffre n'est pas sur votre ordinateur portable. Il s'exécute sur une infrastructure séparée que votre agent ne peut pas toucher. L'agent interagit via une API restreinte qui sert ou refuse — il n'y a pas de système de fichiers à lire, pas de mémoire de processus à inspecter, pas de cache local à exploiter. Si le coffre résidait sur la même machine que l'agent, une compétence compromise pourrait fouiller le système et extraire ce qu'elle veut. La distance élimine complètement cette option.

Limitation de débit. Un agent qui accède à plus de trois identifiants uniques par minute, ou dix par heure, est limité. Une deuxième violation dans les deux heures déclenche un verrouillage strict — l'agent est gelé et nécessite votre clé matérielle pour être déverrouillé. Un agent normal a besoin de deux ou trois identifiants. Un agent qui en lit dix est soit mal configuré, soit compromis. Dans tous les cas, il s'arrête.

Liste blanche IP. Chaque jeton d'agent est lié à une adresse IP source lors du premier contact. Un jeton volé utilisé depuis une IP différente est refusé au niveau du middleware avant l'exécution de tout gestionnaire. L'attaquant possède la clé mais ne peut pas l'utiliser depuis un autre endroit que la machine à laquelle elle a été émise.

Le résultat : le rayon d'impact d'un agent compromis est limité à son périmètre, depuis son IP, à un rythme qui déclenche un verrouillage avant qu'une exfiltration significative ne puisse se produire. Vos autres agents, vos autres identifiants et vos champs d'identité restent intacts.

Niveau 3 — Chiffrement d'identité

Vos données les plus sensibles sont chiffrées avec votre appareil. Nous ne pouvons pas les lire.

Cartes de crédit, CVV, numéros de passeport, SSN, codes de récupération, notes privées, clés de signature — ce sont des champs d'identité. Ils sont chiffrés avec une clé de 32 octets générée aléatoirement lors de la création de votre coffre. Vous ne connaissez pas cette clé. Nous ne l'avons pas. Elle n'a jamais existé sur aucun serveur.

La clé réside dans un fichier WL3, enveloppée avec la sortie de 32 octets de l'extension PRF de votre clé matérielle (WebAuthn PRF). Pour la déballer, vous avez besoin de l'appareil physique — votre lecteur d'empreintes digitales, votre capteur facial ou votre YubiKey. Le déballage se fait dans votre navigateur. La clé en clair existe dans la mémoire du navigateur pendant la durée d'une opération, puis elle disparaît.

Aucun agent ne reçoit cette clé. Aucun point d'API ne la diffuse. Aucun processus côté serveur ne peut la dériver. Les champs d'identité sont du texte chiffré sur chaque serveur, dans chaque sauvegarde, dans chaque cible de réplication, à chaque instant. Une violation de notre infrastructure — totale, complète, chaque octet exfiltré — produit du texte chiffré pour chaque champ d'identité dans tous les coffres. La clé de déchiffrement ne se trouve pas dans les données exfiltrées. Elle ne peut pas y être, car elle n'y a jamais été.

Nous ne pouvons pas déchiffrer vos champs d'identité. Nous ne pouvons pas être contraints de produire une clé que nous ne possédons pas. Ce n'est pas une promesse de politique. C'est une propriété mathématique du système.

Personne d'autre que vous n'a accès

Et il n'y a pas de mot de passe maître.

Il n'y a rien à oublier, rien à hameçonner, rien à casser lors d'une violation. Votre appareil — empreinte digitale, visage ou clé de sécurité — est le seul chemin d'accès. Chaque connexion est TLS 1.3 avec des chiffrements modernes et HSTS. Les identifiants sont diffusés vers des jetons d'agent limités via des points d'API restreints, jamais enregistrés. Même notre support IA ne peut pas voir vos identifiants — le même chiffrement qui cache vos secrets de nous les cache également de nos outils de support.

Modèle de menace

Ce contre quoi nous nous défendons.

Chaque plateforme d'identifiants fait face à la même surface d'attaque. Voici comment Clavitor est conçu contre chacune d'elles.

Menace	Comment nous nous défendons	Résultat
Hameçonnage d'identifiants	Les utilisateurs ne connaissent pas leurs mots de passe (aléatoire 32 octets, jamais affiché). L'extension ne se remplit que sur correspondance d'URL. L'utilisateur ne peut pas taper ce qu'il ne connaît pas.	positif: Bloqué structurellement
Hameçonnage OTP / 2FA	Le TOTP réside dans le coffre, limité au vrai domaine. Domaine incorrect — pas de code. Même défense que pour le mot de passe.	positif: Bloqué structurellement
Violation de serveur	Les champs d'identité sont chiffrés avec des clés dérivées du matériel que nous ne détenons jamais. Les champs d'identifiants sont auto-rotatifs — les textes chiffrés divulgués expirent en quelques heures.	négatif: Dommages limités
Agent IA compromis	Chaque agent a un jeton limité. Une compromission n'expose que le périmètre de l'agent — pas votre coffre complet.	positif: Rayon d'impact limité
Malware de point d'extrémité	Le coffre est distant, pas local. Les jetons de session sont limités dans le temps. Les défis WebAuthn sont liés à l'origine — le malware ne peut pas signer pour l'utilisateur.	avertissement: Atténué
Attaque interne	Les champs d'identité sont mathématiquement inaccessibles pour nous. Nous ne pourrions pas produire de texte clair sous contrainte légale.	positif: Hors de notre portée

Faites confiance à la plateforme, pas seulement à la cryptographie.

Le chiffrement n'est qu'une des trois garanties. Les deux autres concernent ce qui se passe en cas d'échec — du service, ou de votre propre accès à celui-ci.