lodos.md

1Password alternative

lodos vs 1Password

Keep the vault where it is. lodos takes the moment it gets spent.

Checked

Do not switch, and we will put that first rather than bury it. Ask the four questions this site asks every product and 1Password answers three of them exactly as lodos does: its servers hold ciphertext they cannot open, the key is yours, and its AI work was built so the model never receives the value either. The vault is not the difference. The difference is one sentence in their own documentation, which says to assume processes on your machine can read each other environments. lodos closes that, refuses shells and generic HTTP clients as entry points before it decrypts anything, and keeps the runbook, the board and the schedule in the same encrypted store as the key.

The vault does its job right up until the work starts

A password manager guarantees storage, and 1Password guarantees it about as well as it can be guaranteed. But a credential only matters at the moment something uses it, and at that moment it leaves the vault. That is not a gap in the product. That is the product working.

For fifteen years the thing on the other side of that moment was a person. A person reads the runbook, opens the vault, copies the key, runs the command, and notices when the command looks wrong. The person was the guard, and nobody had to write the guard down.

Increasingly it is not a person. It is a model holding your terminal, four minutes after reading a web page. lodos is built for that side of the moment, and everything below is about the handful of things that changes.

What 1Password does better than lodos

This page argues one narrow point. Outside it, 1Password is ahead of us on nearly everything, and part of that we do not intend to compete on at all.

  • Autofill in every browser, passkeys, Watchtower breach alerts, Travel Mode, even a Watch app. lodos has none of that: it is not where your logins live.

  • SOC 2 Type 2 opinions since 2018, ISO 27001, published penetration tests and a public bug bounty. lodos has none of that paperwork yet. What it has instead is described two sections down, and it is not a substitute for an audit.

  • Fifteen years of vault craft, and somewhere to keep the three hundred logins that are not API keys, shared with people who never open a terminal. lodos is not built for any of that.

lodos is not a better vault. It is the half that comes after one.

Keep 1Password. What follows is what a password manager has no reason to have: the page that explains the credential, the task it closes, the schedule it runs on, and an agent holding all three that still cannot read the value.

  • Their own sentence, and our answer to it

    1Password’s documentation is candid: “You should assume that processes on your computer can access the environment of other processes run by the same user.” That is honest and correct for a general-purpose tool. lodos does not inherit an ambient environment at all. Every process it starts is built from a whitelist with a credential blocklist applied on top, so an ANTHROPIC or AWS or STRIPE variable that exists in your shell simply is not there in the child. Five places in the codebase start processes and all five go through that one function, and a check at build time fails the release if a sixth ever skips it. A home directory can be swapped for an ephemeral one per call. Nothing is ever passed as a command-line argument, so it does not appear in a process list either.

  • The refusal, not the encryption

    This is the actual difference and it is small, so it is worth stating precisely. `op run` is a general-purpose injector: it runs whatever binary you name, to whatever host that binary dials, which is correct behaviour for a tool a human drives. lodos assumes the caller may not be human. Before anything is decrypted, the entry point is checked against a denylist that refuses every generic HTTP client, every interpreter and every shell: curl, wget, node, python, ruby, sh, bash, env, xargs, nc, ssh. Tools that do one job go through. You also declare which hosts the command may reach, and a bare wildcard is rejected outright. Deliberately less capable.

  • The model gets an exit code, and the build proves it

    The value is decrypted in the desktop process, injected into an isolated subprocess as an environment variable or a mode-0600 temporary file, and stripped out of everything that comes back, including its base64 and hex forms. What reaches the model is stdout, stderr and an exit code. No tool in lodos returns a plaintext secret to the AI, and a build-time invariant fails the release if anyone ever adds one. Forty-one of those checks run on every build, and each was proved by breaking it on purpose and watching the build turn red.

  • A field can say which tools may touch it

    Sensitivity in lodos is per field, not per item, and a field can go further and declare the tools allowed to use it at all. Declare nothing and it behaves as before; declare an empty list and the field becomes reveal-only, so nothing can ever inject it into a command. The check runs before the section is decrypted, which is the part that matters: a refusal here happens while the ciphertext is still ciphertext. It is opt-in rather than a blanket rule, and it is the narrowest of these guarantees, so it is described narrowly.

  • Some things cannot be written into lodos at all

    A private key, an AWS credentials file, a .netrc, a Docker config, a PEM block: paste any of them into a page, a memory, a skill or a workflow and the write is refused, along with anything else that carries a secret shape. That gate sits on twenty different write paths, and it is the layer a password manager has no reason to have, because a vault stores what you give it. Here the content firewall runs before anything is stored and before anything reaches the model.

  • The key lives next to the page that explains it

    A vault holds credentials. It does not know what they are for. In lodos the runbook references the credential the way code references a variable, as {{secrets.stripe.sk_live}}, so the page can be read by anyone while the value stays somewhere the page never is. Rotate the key and nothing needs editing, because nothing ever held a copy. It also means the agent reading the runbook already holds the reference it needs to act on it.

  • A board that closes itself, on a schedule

    Kanban tasks an agent reads, plans and moves, next to a wiki that maintains itself: ask a question and get a written answer with [[wikilink]] citations, while a nightly pass runs five checks in plain SQL at no AI cost. When a job starts repeating it becomes a declarative workflow, drafted by the AI, approved by you, run on a schedule, calling your own APIs with the credential injected only at the moment of use. This is where a stored secret turns into work that actually happened.

  • A record now, shared history later

    Every access appends an entry: what happened, who asked, which tool, with the field path stored as a hash so the log records that a production key was used without becoming a second list of your production keys. Entries are signed with a key only your master password can derive and chained to the one before, so one cannot be edited or removed without breaking the chain. It stays on your machine. Several people can check the same history against each other, and the chain can be pinned to an external timestamp so its age is provable outside your own machine. When someone leaves, lodos rotates the lock and says plainly what it cannot do: only you can rotate the secret behind it.

What can it see?

Both products are described with the same four answers. There is no kinder phrase available for the same behaviour, so neither column can be graded on a curve.

What can it see?1Passwordlodos
Where your data livesOn their serversOn your device, sync optional
What the vendor can readOnly ciphertext it cannot openOnly ciphertext it cannot open
What its AI can readStructure, never a secret valueStructure, never a secret value
Who holds the keyYouYou
Starts at$8.99 per member, per monthRead from the vendor on 2026-08-03$0

Can 1Password’s AI see my passwords?

No, and they engineered it that way, which is worth saying plainly on a page that would find it convenient to say otherwise. Their MCP server, in their own words, “only sees variable names, and never returns secret values.” 1Password for Claude injects the credential at the browser and states that “the password and the MFA one-time code are never accessible to the model, its context, or Anthropic’s systems.” That is the same guarantee lodos makes, reached from the other side, and anyone telling you 1Password feeds your vault to a model is selling you something.

The open question was never the model. It is the tool the model calls, and what that tool inherits. `op run` does not restrict which binary runs or where it connects, and the environment it hands over sits in the same space their documentation warns about. None of that is a flaw; it is what a general-purpose tool for a human at a keyboard should do. lodos only ever has one kind of caller, so it can afford to refuse most binaries, build the environment from nothing and make you name the hosts.

What lodos refuses to run

This is the one place lodos is deliberately less capable than the tool it is being compared to, so it is worth being concrete about the order things happen in.

  1. 01

    Your page references the credential like a variable: {{secrets.stripe.sk_live}}. The reference is what gets stored, and it is all the model ever sees.

  2. 02

    Before anything is decrypted, three things are checked: the entry point against the denylist, the host list you declared, and whether that field allows this tool at all. A shell, an interpreter or a generic HTTP client is refused here, and so is a bare wildcard for egress. The vault has not been opened at this point.

  3. 03

    Only then is the value decrypted, injected into an isolated subprocess whose environment was built from a whitelist rather than inherited from yours, and stripped out of everything that comes back.

None of this makes lodos a better place to keep a password. It makes it a place where “inject the AWS key, then curl it somewhere” is not an available move.

Three jobs, both ways

Same founder, same week, same three things to get done.

Rotating the Stripe key

1Password

You rotate it in Stripe and update the item. Then you go looking for everywhere else it ended up: the .env, the deploy script, the runbook, the message you sent someone in March.

lodos

You change one field. Every page and workflow keeps working, because none of them ever held the value. They hold a reference to it.

An agent needs a credential to finish the task

1Password

You open a terminal and run the command yourself under `op run`, or you paste the key somewhere the agent can read it and decide to live with that.

lodos

You describe the job. The agent names the reference, the desktop decrypts and injects into a process built from a whitelist, and what comes back to the model is an exit code and redacted output.

Who used the production key, and what for?

1Password

1Password Business streams events to your SIEM, which is the right answer if you are the kind of company that runs one.

lodos

The record is already on your machine, next to the task it was for, signed and chained, with the field path stored as a hash so the log does not become a second list of your secrets.

Bringing your credentials across

  1. 01

    Export your 1Password vault as a .1pux file and point lodos at it. Vaults arrive as sections and fields as keys, and everything you mark sensitive is encrypted on your device on the way in. The same path takes .env files, Bitwarden and LastPass exports, or a pasted block.

  2. 02

    In practice you rarely need all of it. What matters here is the handful automation actually touches: the Stripe key, the database URL, the token the cron job needs. For most founders that is under a dozen.

  3. 03

    Reference them from the page that explains them, as {{secrets.stripe.sk_live}}, and ask the agent to do the job.

Your 1Password vault stays exactly as it was: nothing is moved and nothing is deleted. For the three hundred logins that are not API keys, 1Password remains the right answer. What comes across is the part something other than you spends.

So what should you actually do?

  • Keep 1Password. We said it at the top and it still holds at the bottom: your logins belong there and we are not trying to take them.

  • Add lodos when a growing share of your credentials is spent by something that is not you, and when keeping the runbook, the task and the key in three different apps has started costing you afternoons.

  • Skip lodos entirely if your week is passwords and browsers. We would rather you kept a tool that fits than moved to one built for a different problem.

Questions people actually ask

What is the best 1Password alternative for developers?

For storing passwords, honestly: 1Password. If what you want is somewhere to keep the credentials your automation spends, so an AI agent can use them without reading them, that is lodos, and it is a different product rather than a replacement. Most people searching this phrase want the second thing and end up comparing the first.

Does lodos replace my password manager?

No. There is no browser extension, no autofill, no passkeys and no password generator, and none of those are coming. lodos holds the dozen or so credentials your workflows and your agent spend, next to the pages and tasks that spend them.

Can I import my 1Password vault into lodos?

Yes. Export a .1pux and point lodos at it: vaults become sections, fields become keys. The same path handles .env files, Bitwarden JSON and LastPass CSV, or a block you paste straight in. Your original vault is untouched, and in practice most people only bring across the credentials their automation spends.

Is lodos zero-knowledge like 1Password?

The same class of guarantee. Values you mark sensitive are encrypted on your device with a per-section key derived from your master password, and with cloud sync switched on our servers hold a blob they cannot open. We are not going to claim to be more zero-knowledge than 1Password, because they genuinely are and the claim would be false.

Is op run safe to use with an AI agent?

With care. It never shows the value to the model, which is the hard part, and 1Password solved it. What it does not do, by design, is restrict which binary runs or where it connects, and their docs note that environment variables are readable by other processes running as you. If a human picks the command that is fine. lodos assumes the caller might not be one, so it refuses shells, interpreters and generic HTTP clients as entry points, builds the child environment from a whitelist instead of inheriting yours, and makes you declare the hosts.

Does lodos keep an audit log of secret access?

Yes, locally. Each access appends an entry recording what happened, who asked and which tool, with the field path stored as a hash rather than in the clear, signed with a key derived from your master password and chained to the entry before it. It stays on your machine and streams nowhere. Several people can verify the same history against each other, and the chain can be anchored to an external timestamp.

Is lodos free?

The app is free with no account: vault, wiki, graph, tasks, workflows, twenty-four built-in skills, documents, charts and the built-in agent. The only paid part is encrypted cloud backup at nine dollars a month for the whole install, not per seat. For comparison 1Password Business is $8.99 per user per month, or $24.95 flat for a Teams pack of up to ten. The AI runs on your own Claude account, so we are not reselling you tokens.

The rows that actually differ

Not a feature checklist. 1Password never claimed to have a kanban board and scoring it on one would tell you nothing. These are the five places where the two products meet on the same job and answer differently.

1Passwordlodos
Who chooses the commandAny binary you name, to any host it dials.Shells, interpreters and generic HTTP clients refused. You declare the hosts, and a bare wildcard is rejected.
Environment inheritanceInherited. Their docs say to assume other processes of the same user can read it.Not inherited. The child environment is built from a whitelist, with a credential blocklist on top.
Per-credential tool limitNo restriction at the credential level.A field can declare which tools may touch it, checked before the section is decrypted.
Pasting a private key into a noteStored as you gave it. Storage is the job.Refused. PEM blocks, SSH keys, .netrc and AWS credential files never reach a page, a memory or a prompt.
What the model receivesNever the value. Injected out of band, by design.Never the value. An exit code and redacted output, and a build check fails if a tool ever returns one.

Keep the vault. Add the half that does the work.

Put one real API key in lodos, reference it from a page that explains what it is for, and ask the agent to use it. Then open the transcript and go looking for the value.

Download for MacDownload for Linux

Apple Silicon · macOS 13+ · notarization pending

See the whole product
1Password alternativeSecrets for AI agentsZero-knowledge vaultLocal-first

If this page describes 1Password incorrectly, that is a bug. Tell us and we will fix it. 1Password. Source: 1password.com/pricing/business