Mathématiques, pas une politique.

Trois éléments rendent cela possible.

Tier 1 — Vault encryption

Tout est chiffré au repos.

Every record in your vault — every field, every entry, every byte — is encrypted at rest with AES-256-GCM. The encryption key is 8 bytes, derived from a 32-byte master secret that was randomly generated when your vault was created. That master secret is never stored on disk. It exists only inside a WL3 file, wrapped with the output of your hardware key.

Si quelqu'un vole le fichier du coffre-fort — 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 robuste pour que le déchiffrement par force brute soit pratiquement impossible, et même dans ce cas, les champs internes sont chiffrés à nouveau à 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.

Tier 2 — Credential encryption

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

Au-dessus de la couche du coffre-fort, 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. Indéchiffrable par calcul.

Vos agents IA reçoivent cette clé pour qu'ils puissent faire leur travail. C'est par conception — 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 :

Jetons à portée limitée. 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 d'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 sa portée. Il obtient ce pour quoi il a été nommé et ne peut pas trouver ce qu'il n'a pas.

Distance. Votre coffre-fort n'est pas sur votre ordinateur portable. Il s'exécute sur une infrastructure distincte que votre agent ne peut pas toucher. L'agent interagit via une API étroite 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 à piller. Si le coffre-fort vivait sur la même machine que l'agent, une compétence compromise pourrait accéder au 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 les deux cas, il s'arrête.

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

Le résultat : le rayon d'explosion d'un agent compromis est limité à sa portée, 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é sont intacts.

Tier 3 — Identity encryption

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-fort. Vous ne connaissez pas cette clé. Nous ne l'avons pas. Elle n'a jamais existé sur aucun serveur.

The key lives inside a WL3 file, wrapped with the 32-byte output of your hardware key's PRF extension (WebAuthn PRF). To unwrap it, you need the physical device — your fingerprint reader, your face sensor, or your YubiKey. The unwrapping happens in your browser. The plaintext key exists in browser memory for the duration of one operation, then it's gone.

Aucun agent ne reçoit cette clé. Aucun point d'API ne la transmet. 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-forts. 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 à forcer 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 transmis vers des jetons d'agent à portée limitée 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 nous cache vos secrets nous les cache également à 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 pour y répondre.

Menace	Comment nous nous défendons	Résultat
Hameçonnage d'identifiants	Les utilisateurs ne connaissent pas leurs mots de passe (aléatoire de 32 octets, jamais affiché). L'extension ne remplit que si l'URL correspond. L'utilisateur ne peut pas taper ce qu'il ne connaît pas.	Structurellement bloqué
Hameçonnage OTP / 2FA	TOTP réside dans le coffre-fort, à portée limitée du vrai domaine. Domaine incorrect — pas de code. Même défense que pour le mot de passe.	Structurellement bloqué
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 automatiquement mis à jour en rotation — le texte en clair divulgué expire en quelques heures.	Dommages limités
Agent IA compromis	Chaque agent a un jeton à portée limitée. La compromission n'expose que la portée de l'agent — pas votre coffre-fort complet.	Rayon d'explosion limité
Malware sur point d'extrémité	Le coffre-fort 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.	Atténué
Attaque interne	Les champs d'identité sont mathématiquement inaccessibles pour nous. Nous ne pourrions pas produire de texte en clair sous contrainte légale.	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.