Skip to content

Your Vault, Your Rules: Password Managers, Sovereignty, and Agents

By Bri Stanback 15 min read

I used Buttercup for years. Not because it was the best password manager — it wasn't — but because of what it represented: an encrypted vault file that lived on my hard drive, synced through my cloud storage, and could be moved, backed up, or abandoned on my terms. No account. No subscription. No server between me and my passwords. Just a .bcup file and a master key.

Buttercup is dead now. The project shut down and the repos are archived. I'd been seeing the writing on the wall for a while — slow updates, mobile app falling behind, browser extension getting flaky. It was a solo maintainer's passion project that quietly ran out of steam. The usual open-source story, and I don't hold it against anyone. But it left me looking for a new home for ~400 credentials, and more importantly, looking for the same feeling.

That feeling has a name, I think. I'd call it vault sovereignty — the principle that your secrets should be a file you own, not a row in someone else's database.

This isn't a side-by-side comparison. Those exist, and honestly, the best way to choose a password manager is to try a few yourself — they're all free or cheap enough to test. This is more about the philosophy underneath the choice, and why sovereignty keeps showing up as the thing I can't stop thinking about.

#The Sovereignty Lineage

Buttercup didn't invent this idea. It inherited it from a lineage of tools that share the same instinct:

pass (the Standard Unix Password Manager) is the purest expression. Each password is a GPG-encrypted file in a directory tree. That's it. ~/.password-store/Email/gmail.com.gpg. Version-controlled with Git. Decrypted with your GPG key. The "database" is your filesystem. The "sync" is git push. The "backup" is whatever you do with your home directory. It's beautiful in its refusal to be anything more than what it is — and if you're comfortable with GPG and the command line, it's arguably still the best option.

VeraCrypt (and its predecessor TrueCrypt) applied the same philosophy to disk encryption: your encrypted volume is a file. Mount it, use it, dismount it. No service. No account. The file is the thing. Move it to a USB drive, put it in Dropbox, copy it to a NAS — the encryption travels with the data, not with the vendor.

KeePass and its derivatives (KeePassXC, KeePassDX) — the .kdbx file format became the de facto standard for portable encrypted vaults. Not pretty, but indestructible. The format has outlived multiple GUI clients. That's sovereignty: when the container survives the tool.

What connects all of these is a shared architectural choice: the vault is a file, not a service. Your secrets live in a container you can hold, move, back up, and — critically — walk away from without asking permission.

I should caveat this honestly, because the more I think about it, the less clean the argument is. That vault file? In practice, it usually lives on someone else's infrastructure anyway. My Enpass vault syncs through iCloud Drive. It could just as easily be Dropbox, Google Drive, OneDrive — all someone else's servers. So what am I actually gaining over trusting 1Password directly?

I think the real distinction is separation of trust, not elimination of trust. With 1Password, you trust one entity with the full vertical stack — the encrypted vault, the decryption software, the key derivation, and the infrastructure. If they fail, it's all one failure. With the vault-as-file model, you're splitting the trust: Apple holds an opaque encrypted blob they can't read, and Enpass provides the software that decrypts it but never sees the file in transit. Neither party alone has the full picture. It's separation of concerns applied to trust — independent failure modes instead of a single point.

Is that better? Honestly, I'm not sure. 1Password's security team is almost certainly more sophisticated than my ad-hoc trust layering. Their Secret Key architecture means even a server breach doesn't expose usable vault data — which is more than LastPass could say. The vertical integration lets them ship things like Watchtower and secure remote password protocol that a decoupled architecture simply can't do. Sometimes trusting one very competent party is safer than trusting two adequate ones.

But there's a difference between security and sovereignty, and I think that's what I'm actually reaching for. I touched on this in Pervasive AI: What Happens When Your Assistant Never Logs Off — people overwhelmingly choosing to run their AI agents on local hardware they can unplug, not cloud instances. Same instinct, different domain. Sovereignty isn't "my data never touches a cloud." It's "I can change my mind." I can move the file. I can switch the sync layer. I can export and start over. The relationship between me and my password manager doesn't depend on a subscription remaining active or a company remaining solvent. Maybe that's not a security argument. Maybe it's a dignity argument. I'm still working it out.

It's the same instinct behind Obsidian and Joplin for notes. Local-first. Files you own. Sync is your problem, which means sync is your choice. The data format is the contract, not the vendor relationship.

#Where I Landed: Enpass

After Buttercup died, I switched to Enpass. It's not open source — which matters, and I'll get to that — but it carries the same ethos:

The tradeoff is real: closed source means you're trusting Enpass's claims about encryption without being able to verify them. They've published security audits and use SQLCipher (which is open and well-reviewed), but you can't read the application code. You can't verify there's no telemetry, no silent phone-home, no future update that changes the deal. The published audits are vendor-commissioned and time-bound — a snapshot, not a guarantee. Then again, open source isn't a panacea either — the xz backdoor proved that. A patient attacker spent years earning trust as a maintainer of a critical compression library, then slipped a backdoor that almost shipped in every major Linux distro. "You can audit it" assumes someone actually does, and for most open-source projects, that someone is a burnt-out solo maintainer. (Sound familiar? That's how Buttercup died too — different failure mode, same structural vulnerability.) It's a calculated risk either way: I'm trading auditability for the combination of local-file architecture and cross-platform polish that no fully open-source option has nailed yet. If I stop trusting Enpass tomorrow, I can export my data and leave. The lock-in is minimal. That's the sovereignty test: not "is it open source?" but "can I leave?"

Enpass doesn't actually have an official CLI — it's been a feature request for years. But a community member built enpass-cli, a Go binary that reads your vault file directly. It does what you'd expect: enp list twitter, enp copy reddit.com, password=$(enp pass github.com) for scripting. JSON output, non-interactive mode, even a PIN-based quick unlock. It's not a first-class developer tool like 1Password's op, but the fact that someone could build it — because the vault is just a SQLCipher file on disk — is kind of the point. The architecture enables third-party tooling even when the vendor doesn't provide it.

#The Elephant: 1Password

1Password is the best password manager. I should just say that clearly, because it is. The UX is polished, the security model is strong (the Secret Key alongside your master password is genuinely clever), the browser extension works beautifully, the family sharing is well-designed, and the developer tooling is in a league of its own.

And yet.

It's $36/year for an individual — well, it was. 1Password just announced a 33% price hike effective March 27, 2026: $47.88/year individual, $71.88/year family. Bitwarden raised prices recently too. The trend is clear. That's still not expensive by any reasonable standard. But there's something about paying a subscription for a password manager that creates a low-grade, persistent discomfort — the same feeling as subscribing to a notes app or a to-do list. It's not that the price is wrong. It's that the category feels wrong for rent-seeking. A password vault is a box with a lock. I don't want to rent a box. I want to buy one and put it on a shelf.

This is probably irrational. 1Password employs a security team. They run infrastructure. They ship updates. The subscription funds real, ongoing work that protects real people. I know this. The feeling persists anyway.

Where 1Password genuinely earns its premium — and where the sovereignty tools can't compete — is the developer and agent story. The op CLI is exceptional:

# Read a single secret
op read "op://Personal/GitHub/token"

# Inject secrets into a process without exposing them in env
op run --env-file=.env.tpl -- npm start

# Use in MCP server configs without hardcoding tokens
op run -- node mcp-server.js

That op run pattern is the important one. It injects secrets into a child process's environment at runtime, scoped to that process, without the secrets ever touching your shell history, your .env files, or your global environment variables. When the process exits, the secrets evaporate. 1Password has leaned into this hard — they've published guides specifically for securing MCP server configurations and integrating with AI agents via their SDK. Their pitch: credentials should be injected on behalf of agents, never seen by the agent or the LLM.

This is the right architecture. And right now, only 1Password has it in a polished, production-ready form.

#The Agent Credential Problem

This is where password managers intersect with the always-on agent world, and it's messier than anyone's admitting.

When you run an AI agent like OpenClaw, it needs credentials. API keys for Anthropic. OAuth tokens for Gmail. SSH keys for servers. And the default pattern is horrifying: dump everything into environment variables, a .env file, or worse, directly into a system prompt. Every credential is one prompt injection away from exfiltration. Every API key in an env var is visible to every process on the machine.

The responsible approach has layers:

  1. Never export secrets globally. Don't export ANTHROPIC_API_KEY=sk-... in your shell profile. Every process on your machine can read it.
  2. Use process-scoped injection. op run (1Password), passage with pass, or similar — secrets exist only in the child process's environment.
  3. Prefer short-lived tokens. OAuth refresh flows over long-lived API keys. Rotate aggressively.
  4. Scope narrowly. An agent that checks your email doesn't need your SSH keys. An agent that deploys code doesn't need your email credentials.
  5. Audit access. Know which secrets an agent touched and when.

pass is surprisingly good for this — arguably better than any GUI password manager for the agent use case. Because each secret is a file, you can:

# Read a single secret into a variable, scoped to this command
GITHUB_TOKEN=$(pass show tokens/github) gh pr list

# Or use pass with a wrapper script for Claude Code
ANTHROPIC_API_KEY=$(pass show api/anthropic) claude --dangerously-skip-permissions "task"

The GPG agent caches your passphrase, so you authenticate once and subsequent reads are transparent. It's not pretty, but it's correct — each secret is individually encrypted, individually accessible, and never written to disk in plaintext. And because it's just files and GPG, it works with any tool that can read an environment variable. No SDK. No vendor integration. Just Unix.

There's a whole parallel universe of infrastructure secrets managers — HashiCorp Vault, Google Secret Manager, AWS Secrets Manager, Doppler — designed for the same problem but at the service level: database credentials, TLS certs, service-to-service API keys. The principal isn't a human; it's a workload with an IAM role. These are fundamentally readable stores — you authenticate, you get the secret back as plaintext. They protect secrets at rest and gate access via IAM, but the secret itself is a string that ends up in your process's memory. Same model as a password manager, just for machines instead of humans.

HSMs (hardware security modules) are a different beast entirely. They're not storing secrets you read back — they hold keys that act on your behalf. An HSM is essentially a tamper-resistant mini-computer with its own processor, memory, and OS. You send it an instruction ("sign this transaction with key X"), it executes internally, and sends back the result. The private key never comes out — you authenticate through some other channel, and the HSM does the cryptographic work for you. If someone physically tampers with the device, it zeroes itself. Cloud KMS services (Google Cloud KMS, AWS KMS) can optionally be backed by HSMs, though it's opt-in and costs more — the default is software-based key storage.

The sovereignty tension is different for each. Secrets managers are about access control: who gets to read this? HSMs are about physical containment: this key cannot leave, period. That's what makes them secure — and what makes them terrifying. I worked with HSMs for cloud-deployed crypto payment automation, and the feeling was both at once: reassuring because the key was actually safe inside tamper-resistant hardware, and unsettling because the HSM was opaque. You can import a key you already hold (and keep your copy), but the purist approach is generating the key inside the hardware — it never exists in software, ever. For those keys, if something happened to the HSM, the key was gone. Not "reset your password" gone. Gone gone. And even for imported keys, the opacity is real — you can't inspect the HSM's state, can't verify the key is still there, can't peek inside. You just trust the black box.

An HSM-backed cloud KMS is arguably more secure than your local SQLCipher file, but it's the opposite of sovereignty — your key cannot leave their hardware, and that's both the security guarantee and the lock-in, simultaneously.

Crypto wallets live in the same tension. "Not your keys, not your crypto" is the sovereignty thesis applied to money. When Ledger added Recover in 2023 — opt-in cloud backup of your seed phrase — the hardware wallet community revolted, because the mere capability of extracting the key from the secure element broke the trust model, even if you never used it. Crypto's answer to the HSM recovery problem is HD wallets (BIP-32) — a master seed phrase that can re-derive every child key. The seed is your sovereignty layer; the HSM is your operational security layer. But the core tension remains: the more secure the containment, the higher the stakes of losing access.

Agents sit awkwardly between these worlds. Not quite a human (no biometrics, no interactive auth). Not quite infrastructure (conversational, ad-hoc, not deployed via Terraform). But needing credentials like both.

The gap in the market is obvious: nobody has built a good, sovereignty-respecting credential broker for AI agents. 1Password is closest with op run and their SDK, but it requires their subscription and their infrastructure. pass is correct but requires GPG comfort. Enpass's community CLI exists but isn't widely adopted. Bitwarden has a CLI but the UX story is rough.

What I'd want in the near term: something with pass's file-based architecture, Enpass's cross-platform GUI for daily use, and 1Password's op run semantics for agent credential injection. Maybe that's a pass frontend. Maybe it's an Enpass plugin. Maybe someone builds it from scratch. The pieces are all there.

Longer term, though, the answer probably isn't better password managers for agents — it's moving past passwords entirely. The patterns already exist elsewhere. Blockchain solved delegated agent authority with account abstraction — session keys with spending limits that expire, so an agent can transact without ever holding the master private key. Cloud infrastructure solved it with workload identity federation — no stored credentials at all, just short-lived tokens exchanged on the fly via OIDC. Both point at the same principle: scoped, short-lived, delegated authority instead of "here's the password, good luck." The future isn't giving agents better access to your secrets. It's a world where agents authenticate through delegated identity and never see a credential at all. We're just not there yet for most services.

#The Landscape, Honestly

Here's where things actually stand, as someone who's used most of these:

The top tier:

The sovereignty tier:

The declining:

The gone:

Just this month, researchers at ETH Zurich published a study that put a dent in the "zero-knowledge" promises of cloud-based managers. They demonstrated 12 attacks on Bitwarden, 7 on LastPass, and 6 on Dashlane — including full vault compromise under a malicious-server threat model. Even 1Password wasn't immune to all classes of attack. These are advanced-adversary scenarios, not mass-exploitation vectors, but they undermine the core confidence that "even if the server is compromised, your data is safe." The question isn't whether vulnerabilities exist (they will). It's how quickly they're found, disclosed, and fixed — and whether your architecture limits the blast radius when they are. It's also, quietly, an argument for the sovereignty model: if there's no server to compromise, the malicious-server threat model doesn't apply.

#The Ethos

What I'm really circling around isn't a product recommendation. It's an architectural preference — maybe a philosophical one.

The tools I gravitate toward share something: they treat your data as yours. Not hosted. Not synced through the vendor's servers. Not contingent on a subscription remaining active. A file. Encrypted. On your machine. Yours to move, yours to back up, yours to lose if you're careless.

This is the same instinct that makes people run OpenClaw on a Mac Mini instead of a cloud VPS. The same instinct behind Obsidian over Notion. Local-first over cloud-first. Ownership over convenience. The sovereignty section of my agent post touched on this — people want their AI agent close, on a machine they can unplug. Password vaults have been in this territory for a decade longer. The pattern is the same: the more personal the data, the stronger the pull toward physical control.

It's not always the practical choice. 1Password's cloud sync is seamless in a way that "sync your own vault file through iCloud Drive" just isn't. Apple Passwords works without thinking about it at all. Convenience is a feature. I'm not pretending otherwise.

But there's something about a world where every service wants a subscription, every tool wants a cloud account, every piece of software wants to be the intermediary between you and your data — there's something about a .kdbx file on a USB drive that feels like a small act of resistance. Maybe not a smart one. But an honest one.

The next question — the one I don't have a good answer to yet — is how to extend that sovereignty to the agent world. When my AI assistant needs my GitHub token to push a commit, I want it to have exactly that credential, for exactly that task, for exactly as long as it needs it, with a clear audit trail. Not a global env var. Not a plaintext config file. Not "just put it in the system prompt."

1Password is building this. The open-source world hasn't caught up yet. But the pieces — pass, GPG, process-scoped injection, credential brokers — are all there, waiting for someone to assemble them into something that feels as natural as op run but doesn't require a subscription to use.

I'll be watching for it. In the meantime, my Enpass vault sits on my iCloud Drive — a SQLCipher file, encrypted, portable, mine. It's not perfect. But it's here, and that counts for something.

Tagged

  • tools
  • ai
  • systems
On the trail: Designing for Agents