lodos.md

Alternative à 1Password

lodos vs 1Password

Gardez le coffre où il est. lodos prend le moment où l'on s'en sert.

Vérifié le

Ne changez pas, et nous le mettons en haut plutôt qu'en bas. Posez les quatre questions que ce site pose à chaque produit et 1Password en répond trois exactement comme lodos : ses serveurs ne détiennent qu'un chiffré qu'ils ne peuvent pas ouvrir, la clé est la vôtre, et son travail sur l'IA a été bâti pour que le modèle ne reçoive jamais la valeur non plus. Le coffre n'est pas la différence. La différence tient en une phrase de leur propre documentation : partez du principe que les processus de votre machine peuvent lire l'environnement les uns des autres. lodos ferme exactement cela, refuse shells et clients HTTP généralistes comme point d'entrée avant tout déchiffrement, et garde le runbook, le tableau et le calendrier dans le même stockage chiffré que la clé.

Le coffre fait son travail jusqu'au moment exact où le travail commence

Un gestionnaire de mots de passe garantit le stockage, et 1Password le garantit aussi bien qu'on peut le garantir. Mais un identifiant ne compte qu'au moment où quelque chose l'utilise, et à cet instant précis il quitte le coffre. Ce n'est pas une faille du produit. C'est le produit qui fonctionne.

Pendant quinze ans, de l'autre côté de ce moment, il y avait une personne. Une personne lit le runbook, ouvre le coffre, copie la clé, lance la commande et remarque quand la commande semble étrange. La personne était le garde-fou, et personne n'avait besoin de l'écrire.

De plus en plus, ce n'est plus une personne. C'est un modèle qui tient votre terminal, quatre minutes après avoir lu une page web. C'est pour ce côté-là du moment que lodos est construit, et tout ce qui suit parle des quelques choses que cela change.

Ce que 1Password fait mieux que lodos

Cette page défend un point étroit. En dehors de ce point, 1Password est devant sur presque tout, et sur une partie nous n'avons aucune intention de rivaliser.

  • Le remplissage automatique dans tous les navigateurs, les passkeys, les alertes de fuite Watchtower, le mode Voyage, jusqu'à une app Watch. lodos n'a rien de tout cela : ce n'est pas là que vivent vos identifiants.

  • Des rapports SOC 2 Type 2 depuis 2018, ISO 27001, des tests d'intrusion publiés et un programme de bug bounty ouvert. lodos n'a encore rien de tout cela. Ce qu'il a à la place est décrit deux sections plus bas, et ce n'est pas un substitut à un audit.

  • Quinze ans de savoir-faire, et un endroit pour les trois cents identifiants qui ne sont pas des clés d'API, partageables avec des gens qui n'ouvrent jamais un terminal. lodos n'est construit pour rien de tout cela.

lodos n'est pas un meilleur coffre. C'est la moitié qui vient après.

Gardez 1Password. Ce qui suit, un gestionnaire de mots de passe n'a aucune raison de l'avoir : la page qui explique l'identifiant, la tâche qu'il clôt, le calendrier sur lequel il tourne, et un agent qui tient les trois sans pouvoir lire la valeur.

  • Leur propre phrase, et notre réponse

    La documentation de 1Password est franche : "vous devez partir du principe que les processus de votre ordinateur peuvent accéder à l'environnement des autres processus lancés par le même utilisateur". Pour un outil généraliste, c'est honnête et juste. lodos, lui, n'hérite d'aucun environnement. Chaque processus qu'il lance est bâti à partir d'une liste blanche, avec une liste de blocage des identifiants par-dessus : une variable ANTHROPIC, AWS ou STRIPE présente dans votre shell n'existe tout simplement pas dans l'enfant. Cinq endroits du code lancent des processus et les cinq passent par la même fonction ; si un sixième la contournait, une vérification à la compilation ferait échouer la publication. Le répertoire personnel peut être remplacé par un répertoire éphémère à chaque appel. Rien n'est jamais passé en argument de ligne de commande, donc rien n'apparaît non plus dans une liste de processus.

  • Le refus, pas le chiffrement

    Voilà la vraie différence, et elle est petite, donc disons-la précisément. `op run` est un injecteur généraliste : il exécute le binaire que vous nommez, vers l'hôte que ce binaire appelle, et c'est le bon comportement pour un outil piloté par un humain. lodos suppose que l'appelant peut ne pas être humain. Avant tout déchiffrement, le point d'entrée est confronté à une liste de refus qui écarte tout client HTTP généraliste, tout interpréteur et tout shell : curl, wget, node, python, ruby, sh, bash, env, xargs, nc, ssh. Les outils qui font une seule chose passent. Vous déclarez aussi les hôtes que la commande peut atteindre, et un joker nu est rejeté. Volontairement moins capable.

  • Le modèle reçoit un code de sortie, et le build le prouve

    La valeur est déchiffrée dans le processus de bureau, injectée dans un sous-processus isolé sous forme de variable d'environnement ou de fichier temporaire en mode 0600, et retirée de tout ce qui revient, y compris de ses formes base64 et hex. Ce qui atteint le modèle, c'est stdout, stderr et un code de sortie. Aucun outil de lodos ne renvoie un secret en clair à l'IA, et une vérification à la compilation fait échouer la publication si quelqu'un en ajoute un. Quarante et une de ces vérifications tournent à chaque build, et chacune a été prouvée en la cassant exprès pour voir le build passer au rouge.

  • Un champ peut dire quels outils ont le droit d'y toucher

    La sensibilité, dans lodos, se déclare par champ et non par entrée, et un champ peut aller plus loin en nommant les outils autorisés à s'en servir. Ne déclarez rien et il se comporte comme avant ; déclarez une liste vide et le champ devient consultable seulement, plus rien ne peut l'injecter dans une commande. La vérification tourne avant que la section soit déchiffrée, et c'est ce qui compte : un refus ici arrive pendant que le chiffré est encore chiffré. C'est une restriction que vous activez, pas une règle générale, et la plus étroite de ces garanties, donc décrite étroitement.

  • Certaines choses ne peuvent pas entrer dans lodos

    Une clé privée, un fichier de credentials AWS, un .netrc, une configuration Docker, un bloc PEM : collez l'un d'eux dans une page, une mémoire, une compétence ou un workflow et l'écriture est refusée, comme tout ce qui porte la forme d'un secret. Cette porte est posée sur vingt chemins d'écriture différents, et c'est la couche qu'un gestionnaire de mots de passe n'a aucune raison d'avoir, puisqu'un coffre range ce que vous lui donnez. Ici, le pare-feu de contenu tourne avant tout stockage et avant que quoi que ce soit atteigne le modèle.

  • La clé vit à côté de la page qui l'explique

    Un coffre détient des identifiants. Il ne sait pas à quoi ils servent. Dans lodos, le runbook référence l'identifiant comme du code référence une variable, sous la forme {{secrets.stripe.sk_live}} : la page se lit par n'importe qui pendant que la valeur reste là où la page n'est jamais. Faites tourner la clé et rien n'est à modifier, puisque rien n'en détenait de copie. Et l'agent qui lit le runbook tient déjà la référence dont il a besoin pour agir.

  • Un tableau qui se clôt tout seul, à l'heure dite

    Des tâches kanban qu'un agent lit, planifie et déplace, à côté d'un wiki qui s'entretient : posez une question, obtenez une réponse rédigée avec des citations [[wikilink]], pendant qu'un passage nocturne fait cinq contrôles en SQL pur, sans coût d'IA. Quand un travail se répète, il devient un workflow déclaratif : rédigé par l'IA, approuvé par vous, exécuté selon un calendrier, appelant vos propres API avec l'identifiant injecté au seul moment de l'usage. C'est là qu'un secret stocké devient du travail réellement effectué.

  • Un journal maintenant, un historique partagé plus tard

    Chaque accès ajoute une entrée : ce qui s'est passé, qui a demandé, quel outil, avec le chemin du champ sous forme de hachage, pour que le journal note qu'une clé de production a servi sans devenir une deuxième liste de vos clés de production. Les entrées sont signées avec une clé que seul votre mot de passe maître peut dériver, et chaînées à la précédente, si bien qu'aucune ne peut être modifiée ou retirée sans casser la chaîne. Tout reste sur votre machine. Plusieurs personnes peuvent vérifier le même historique les unes contre les autres, et la chaîne peut être ancrée à un horodatage externe, de sorte que son ancienneté est prouvable hors de votre machine. Quand quelqu'un part, lodos fait tourner la serrure et dit franchement ce qu'il ne peut pas faire : le secret derrière, vous seul pouvez le faire tourner.

Que peut-il voir ?

Les deux produits sont décrits avec les mêmes quatre réponses. Il n’existe pas de formulation plus flatteuse pour le même comportement, donc aucune colonne ne peut se noter à part.

Que peut-il voir ?1Passwordlodos
Où vivent vos donnéesSur ses serveursSur votre appareil, sync facultative
Ce que l’éditeur peut lireSeulement un chiffré qu’il ne peut pas ouvrirSeulement un chiffré qu’il ne peut pas ouvrir
Ce que son IA peut lireLa structure, jamais la valeur d’un secretLa structure, jamais la valeur d’un secret
Qui détient la cléVousVous
À partir de$8.99 par membre et par moisRelevé chez l’éditeur le 2026-08-03$0

L'IA de 1Password peut-elle voir mes mots de passe ?

Non, et ils l'ont conçue ainsi, ce qui mérite d'être dit clairement sur une page à qui l'inverse arrangerait. Leur serveur MCP, selon leurs propres mots, "ne voit que les noms de variables et ne renvoie jamais au client les valeurs de secrets stockées dans 1Password". 1Password for Claude injecte l'identifiant au niveau du navigateur et précise que "le mot de passe et le code à usage unique MFA ne sont jamais accessibles au modèle, à son contexte ou aux systèmes d'Anthropic". C'est la même garantie que donne lodos, atteinte par l'autre côté, et quiconque vous dit que 1Password donne votre coffre à manger à un modèle vous vend quelque chose.

La question ouverte n'a jamais été le modèle. C'est l'outil que le modèle appelle, et ce dont cet outil hérite. `op run` ne restreint ni le binaire exécuté ni sa destination réseau, et l'environnement qu'il transmet se trouve exactement dans l'espace contre lequel leur documentation met en garde. Rien de tout cela n'est un défaut ; c'est ce que doit faire un outil généraliste pour un humain au clavier. lodos n'a jamais qu'un seul type d'appelant, il peut donc se permettre de refuser la plupart des binaires, de construire l'environnement à partir de rien et de vous faire nommer les hôtes.

Ce que lodos refuse d'exécuter

C'est le seul endroit où lodos est délibérément moins capable que l'outil auquel on le compare, donc soyons concrets sur l'ordre des opérations.

  1. 01

    Votre page référence l'identifiant comme une variable : {{secrets.stripe.sk_live}}. C'est cette référence qui est stockée, et c'est tout ce que le modèle voit un jour.

  2. 02

    Avant tout déchiffrement, trois choses sont vérifiées : le point d'entrée face à la liste de refus, la liste d'hôtes que vous avez déclarée, et si ce champ autorise cet outil. Un shell, un interpréteur ou un client HTTP généraliste est écarté ici, un joker nu pour la sortie réseau aussi. À ce stade, le coffre n'a pas encore été ouvert.

  3. 03

    Alors seulement la valeur est déchiffrée, injectée dans un sous-processus isolé dont l'environnement a été bâti depuis une liste blanche au lieu d'être hérité du vôtre, et retirée de tout ce qui revient.

Rien de tout cela ne fait de lodos un meilleur endroit pour un mot de passe. Cela en fait un endroit où "injecte la clé AWS, puis envoie-la ailleurs avec curl" n'est pas un coup disponible.

Trois tâches, deux façons

Même fondateur, même semaine, mêmes trois choses à faire.

Faire tourner la clé Stripe

1Password

Vous la changez dans Stripe et mettez l'entrée à jour. Puis vous partez chercher partout où elle a atterri : le .env, le script de déploiement, le runbook, le message envoyé à quelqu'un en mars.

lodos

Vous changez un champ. Chaque page et chaque workflow continue de fonctionner, parce qu'aucun ne détenait la valeur. Ils en détiennent une référence.

Un agent a besoin d'un identifiant pour finir la tâche

1Password

Vous ouvrez un terminal et lancez la commande vous-même sous `op run`, ou vous collez la clé là où l'agent peut la lire et vous vivez avec.

lodos

Vous décrivez le travail. L'agent nomme la référence, le bureau déchiffre et injecte dans un processus bâti depuis une liste blanche, et ce qui revient au modèle est un code de sortie et une sortie nettoyée.

Qui a utilisé la clé de production, et pour quoi ?

1Password

1Password Business envoie les événements vers votre SIEM, la bonne réponse si vous en exploitez un.

lodos

Le journal est déjà sur votre machine, à côté de la tâche concernée, signé et chaîné, avec le chemin du champ en hachage pour qu'il ne devienne pas une seconde liste de vos secrets.

Faire venir vos identifiants

  1. 01

    Exportez votre coffre 1Password en .1pux et pointez lodos dessus. Les coffres arrivent en sections, les champs en clés, et tout ce que vous marquez comme sensible est chiffré sur votre appareil au passage. Le même chemin accepte les fichiers .env, les exports Bitwarden et LastPass, ou un bloc collé.

  2. 02

    En pratique vous avez rarement besoin de tout. Ce qui compte ici, c'est la poignée que l'automatisation touche vraiment : la clé Stripe, l'URL de la base, le jeton de la tâche cron. Pour la plupart des fondateurs, moins d'une douzaine.

  3. 03

    Référencez-les depuis la page qui les explique, sous la forme {{secrets.stripe.sk_live}}, et demandez à l'agent de faire le travail.

Votre coffre 1Password reste exactement tel qu'il était : rien n'est déplacé, rien n'est supprimé. Pour les trois cents identifiants qui ne sont pas des clés d'API, 1Password reste la bonne réponse. Ce qui traverse, c'est la part que dépense autre chose que vous.

Alors que faire, concrètement ?

  • Gardez 1Password. Nous l'avons dit en haut et cela tient encore en bas : vos identifiants ont leur place là-bas et nous n'essayons pas de les prendre.

  • Ajoutez lodos quand une part croissante de vos identifiants est dépensée par autre chose que vous, et quand garder le runbook, la tâche et la clé dans trois apps différentes commence à vous coûter des après-midis.

  • Passez votre chemin si votre semaine se résume à des mots de passe et des navigateurs. Nous préférons que vous gardiez un outil qui vous va plutôt que d'en adopter un bâti pour un autre problème.

Les questions qu'on nous pose vraiment

Quelle est la meilleure alternative à 1Password pour les développeurs ?

Pour stocker des mots de passe, honnêtement : 1Password. Si ce que vous cherchez est un endroit pour les identifiants que votre automatisation dépense, afin qu'un agent IA puisse les utiliser sans les lire, c'est lodos, et c'est un produit différent plutôt qu'un remplaçant. La plupart des gens qui tapent cette recherche veulent le second et finissent par comparer le premier.

lodos remplace-t-il mon gestionnaire de mots de passe ?

Non. Pas d'extension de navigateur, pas de remplissage automatique, pas de passkeys et pas de générateur de mots de passe, et rien de tout cela n'arrivera. lodos garde la douzaine d'identifiants que vos workflows et votre agent dépensent, à côté des pages et des tâches qui les dépensent.

Puis-je importer mon coffre 1Password dans lodos ?

Oui. Exportez un .1pux et pointez lodos dessus : les coffres deviennent des sections, les champs des clés. Le même chemin gère les fichiers .env, le JSON Bitwarden et le CSV LastPass, ou un bloc collé directement. Votre coffre d'origine reste intact, et en pratique la plupart des gens ne font venir que les identifiants que leur automatisation dépense.

lodos est-il zero-knowledge comme 1Password ?

La même classe de garantie. Les valeurs que vous marquez comme sensibles sont chiffrées sur votre appareil avec une clé par section dérivée de votre mot de passe maître, et avec la synchronisation activée nos serveurs ne détiennent qu'un blob qu'ils ne peuvent pas ouvrir. Nous n'allons pas prétendre être plus zero-knowledge que 1Password, parce qu'ils le sont vraiment et que l'affirmation serait fausse.

op run est-il sûr avec un agent IA ?

Avec précaution. Il ne montre jamais la valeur au modèle, c'est la partie difficile et 1Password l'a résolue. Ce qu'il ne fait pas, volontairement, c'est restreindre le binaire exécuté ou sa destination réseau, et leur documentation note que les variables d'environnement sont lisibles par les autres processus lancés sous votre compte. Si un humain choisit la commande, très bien. lodos suppose que l'appelant peut ne pas en être un : il refuse shells, interpréteurs et clients HTTP généralistes comme point d'entrée, bâtit l'environnement de l'enfant depuis une liste blanche au lieu d'hériter du vôtre, et vous fait déclarer les hôtes.

lodos tient-il un journal des accès aux secrets ?

Oui, en local. Chaque accès ajoute une entrée notant ce qui s'est passé, qui a demandé et quel outil, avec le chemin du champ en hachage plutôt qu'en clair, signée avec une clé dérivée de votre mot de passe maître et chaînée à la précédente. Tout reste sur votre machine et ne part nulle part. Plusieurs personnes peuvent vérifier le même historique les unes contre les autres, et la chaîne peut être ancrée à un horodatage externe.

lodos est-il gratuit ?

L'app est gratuite et sans compte : coffre, wiki, graphe, tâches, workflows, vingt-quatre compétences intégrées, documents, graphiques et l'agent intégré. Seule la sauvegarde chiffrée est payante, neuf dollars par mois pour toute l'installation, pas par siège. À titre de comparaison, 1Password Business coûte 8,99 dollars par utilisateur et par mois, et un pack Teams jusqu'à dix personnes 24,95 dollars forfaitaires. L'IA tourne sur votre propre compte Claude, nous ne vous revendons donc pas de jetons.

Les lignes qui diffèrent vraiment

Pas une liste de fonctionnalités. 1Password n'a jamais prétendu avoir un tableau kanban et le noter là-dessus ne vous apprendrait rien. Voici les cinq endroits où les deux produits se rencontrent sur le même travail et répondent différemment.

1Passwordlodos
Qui choisit la commandeN'importe quel binaire que vous nommez, vers n'importe quel hôte qu'il appelle.Shells, interpréteurs et clients HTTP généralistes refusés. Vous déclarez les hôtes, et un joker nu est rejeté.
Héritage de l'environnementHérité. Leur documentation conseille de supposer que les autres processus du même utilisateur peuvent le lire.Non hérité. L'environnement de l'enfant est bâti depuis une liste blanche, avec une liste de blocage des identifiants par-dessus.
Limite d'outils par identifiantAucune restriction au niveau de l'identifiant.Un champ peut nommer les outils autorisés à y toucher, vérifié avant que la section soit déchiffrée.
Coller une clé privée dans une noteStockée telle que donnée. Le stockage est le métier.Refusée. Blocs PEM, clés SSH, .netrc et fichiers de credentials AWS n'atteignent jamais une page, une mémoire ou un prompt.
Ce que reçoit le modèleJamais la valeur. Injectée hors canal, par conception.Jamais la valeur. Un code de sortie et une sortie nettoyée, et une vérification de build échoue si un outil en renvoie une.

Gardez le coffre. Ajoutez la moitié qui travaille.

Mettez une vraie clé d'API dans lodos, référencez-la depuis une page qui explique à quoi elle sert, et demandez à l'agent de l'utiliser. Ouvrez ensuite la transcription et cherchez la valeur.

Télécharger pour MacTélécharger pour Linux

Apple Silicon · macOS 13+ · notarisation en cours

Voir tout le produit
Alternative à 1PasswordSecrets pour agents IACoffre zero-knowledgeLocal-first

Si cette page décrit 1Password de façon inexacte, c’est un bug. Dites-le-nous et nous le corrigerons. 1Password. Source: 1password.com/pricing/business