L'étiquette sur l'identifiant n'est pas son périmètre.

La cryptographie est sans faille. SRP-6a selon la RFC 5054, AES-256-GCM, comparaisons à temps constant, preuve à connaissance nulle. 1Password a correctement implémenté la cryptographie. Ce qu'ils ont raté, c'est l'étiquette sur la boîte.

Ce mois-ci, deux ingénieurs de Token Security ont passé trois jours à rétroconcevoir le protocole d'authentification SRP propriétaire de 1Password. Ils ne cherchaient pas une vulnérabilité. Ils essayaient de remplacer un pont SCIM par un client Python pour des outils d'identité non humaine. Ce qu'ils ont trouvé, c'est un écart entre ce qu'un identifiant déclare pouvoir faire et ce qu'il peut réellement faire [1][2].

Un jeton de compte de service limité à un coffre, avec des autorisations de lecture, peut lister tous les utilisateurs de l'organisation. Tous les groupes. Toutes les appartenances aux groupes. Toutes les autorisations de niveau coffre, pour chaque coffre. Noms, adresses e-mail, états, horodatages de dernière authentification. L'étiquette du jeton indique « un coffre ». L'API dit le contraire [1].

1Password l'a confirmé. Ce comportement est intentionnel. Un découpage fin des périmètres figure sur la feuille de route, sans date [2].

Ce à quoi le jeton a réellement accès

Gil Portnoy et Henry, écrivant pour Token Security, ont documenté cinq points de terminaison d'API qu'un jeton de compte de service « limité à un coffre » peut interroger avec succès [1] :

/api/v2/users renvoie tous les utilisateurs de l'organisation : UUID, nom, adresse e-mail, état, type, horodatage de dernière authentification. /api/v1/groups renvoie tous les groupes avec leurs autorisations et leur état. Les commandes CLI relatives aux appartenances aux groupes, aux utilisateurs et autorisations de coffre, et aux groupes de coffre renvoient toutes des données réelles. /api/v3/account renvoie les métadonnées du compte. /api/v2/vault/{id}/vaultaccess renvoie les informations d'accès au coffre.

Aucun de ces points de terminaison n'est limité au coffre unique pour lequel le jeton a été provisionné. On avait dit au jeton « lire un coffre ». L'API lui a donné la carte de toute l'organisation [1].

Voici le point le plus net : l'énumération ne fonctionne pas via le SDK officiel de 1Password. Ce chemin renvoie UNSUPPORTED ou FORBIDDEN. Elle fonctionne via l'API interne de la CLI, que les chercheurs ont dû rétroconcevoir. Le « périmètre » est une restriction côté client, au niveau du SDK. L'identifiant sous-jacent dispose d'un accès en lecture à toute l'organisation. Un attaquant n'utilise pas votre SDK [1].

Les chercheurs ont construit le client en environ 420 lignes de Python. Cinq points de terminaison d'API. Visibilité complète sur l'organisation. Ils ont publié leur analyse le 16 juillet [1].

Le problème n'est pas la serrure. C'est le trousseau.

Les chercheurs sont prudents sur ce point. La cryptographie est réellement solide. L'implémentation SRP utilise une preuve à connaissance nulle normalisée par la RFC : le serveur ne voit jamais le mot de passe, le client ne voit jamais le sel, et chaque échec d'authentification renvoie le même message d'erreur afin qu'un attaquant n'en apprenne rien. 1Password a documenté ses propres écarts non standard (dont une phrase de la chanson « Penny Lane » des Beatles enfouie dans une constante cryptographique, en guise de clin d'œil) et ces écarts sont neutres en matière de sécurité [1].

Le problème n'est pas la serrure. C'est ce que la clé ouvre. Quand un identifiant est étiqueté « limité à un coffre », les administrateurs provisionnent des agents avec en pensant que le rayon d'impact est étroit. L'agent reçoit un identifiant. L'identifiant reçoit l'organigramme. Personne ne l'a voulu, mais personne ne peut non plus voir que cela se produit [1].

Quand vous donnez à un agent un jeton « limité », l'agent opère dans le périmètre que l'API réellement applique, pas dans le périmètre que décrit l'étiquette. Si l'agent est compromis, par injection de prompt, fichier de conventions empoisonné, attaque de la chaîne d'approvisionnement, ou l'un des vecteurs que les défenses basées sur le texte ne peuvent pas entièrement fermer, l'attaquant n'obtient pas un coffre. Il obtient la topologie de l'organisation : qui est dans quel groupe, qui a accès à quels coffres, quand chaque personne s'est authentifiée pour la dernière fois. C'est la phase de reconnaissance d'une intrusion, livrée en un seul appel d'API [1].

L'écart entre le périmètre documenté et le périmètre effectif n'est pas propre à 1Password. Toute API de gestion d'identifiants prend des décisions d'autorisation implicites que les administrateurs ne voient jamais. Ce que Token Security a prouvé, c'est que cet écart est réel, mesurable et exploitable avec un week-end de travail et un hook Frida [1].

Ce qu'un coffre conçu pour cela fait différemment

Le rôle d'un identifiant est de survivre au monde dans lequel il se trouve. Si un jeton « limité » peut cartographier votre organisation en silence, le périmètre n'a jamais été réel. C'était une étiquette.

Clavitor n'étiquette pas les identifiants et n'espère pas. L'agent reçoit un identifiant explicitement nommé, récupéré en direct à l'instant de l'appel, injecté dans une seule requête, puis effacé. Il n'existe pas de jeton permanent qu'un attaquant pourrait réutiliser. Il n'existe pas de point de terminaison de cartographie d'organisation derrière une étiquette de périmètre que personne n'a vérifiée. Le coffre n'expose pas l'énumération à l'agent. L'agent accède à ce pour quoi il a été nommé, et à rien d'autre.

Chaque accès est journalisé sur l'agent spécifique qui l'a effectué, sur le coffre, et non sur le point de terminaison où l'agent s'exécute. Si un jeton est compromis, le rayon d'impact est le périmètre de cet unique appel, et non la topologie de l'organisation qui se trouve derrière.

Les principes d'un coffre qui applique le périmètre au lieu de l'étiqueter : The Ten Rules of Credential Management

Clavitor (@clavitorai) est le coffre d'identifiants conçu pour les agents d'IA, et contre eux. clavitor.ai

Sources

[1] Token Security (Gil Portnoy, Henry) — Reversing 1Password's Proprietary SRP Authentication Protocol — @TheTokenSec

[2] @TheTokenSec — fil X sur la découverte de l'escalade de périmètre, 16 juillet 2026 — « 1Password confirmed this is by design, to support vault-management workflows »