seekrit vs 1Password

Comparison·1Password

This page is about 1Password Secrets Automation — Service Accounts, the self-hosted Connect server, and op run — not the password manager most people know 1Password for, though the two share an architecture and a company.

If 1Password is breached, what does the attacker get?

For the password manager, this is one of the better-answered versions of this question in the industry. A device-generated Secret Key combined with your account password derives the encryption key, and 1Password states it is never sent to them. Their security page states: "Our dual-key model ensures that even we can't see exactly what you've saved in 1Password." If their servers are breached, an attacker gets ciphertext and no way to derive the key that opens it, because half of what derives that key was never theirs to lose. That's a real, well-specified answer, and we say so plainly.

What we could not get the same answer to is whether it holds for the surfaces this page is actually about. Service account token creation happens client-side — "nothing sensitive goes to 1Password's servers" for minting the token — but neither that page nor the Connect server docs say where item decryption happens for a token-authenticated API read: client-side only, or reconstructed server-side to answer the request. The self-hosted Connect server holds its own local encrypted copy of your data plus a generated 1password-credentials.json — the right shape for a design that decrypts locally and never in 1Password's cloud, but their docs stop short of stating that outright. On a breach question specifically, that gap matters: we can't tell you whether a compromised 1Password cloud account, or a compromised self-hosted Connect server, yields ciphertext only or something closer to plaintext, because 1Password's own documentation doesn't settle it. We'd rather say that plainly than imply an answer either way.

If seekrit is breached: our answer doesn't depend on which surface you ask about, because there's only one design. Our security model states it at full strength and no stronger — secrets are encrypted client-side, the server stores only ciphertext, wrapped keys, and metadata, and no seekrit process ever holds a key that decrypts more than one principal's own grant, whether that principal is a browser session, a service token, or the egress proxy. Three honest boundaries: metadata is visible — names, versions, and timestamps aren't encrypted. Third-party sync is the one opt-in exception, scoped per environment. And the guarantee covers us being breached — a leaked passphrase or service token still exposes whatever that principal held.

None of this is academic. A service holding the ability to decrypt customer-stored values has been exactly the failure mode behind recent disclosures — Railway's incident described possible access to decrypted customer environment variables, and Northflank told every customer to assume theirs were decrypted. That's why "where exactly does decryption happen" is the first question worth asking any vendor, 1Password included.

What seekrit does that Secrets Automation doesn't — yet

A credential broker, not just env-var injection. op run injects secrets as environment variables into a subprocess, and to 1Password's credit their own docs warn that "processes on your computer can access the environment of other processes run by the same user" — the same honest limitation we document for seekrit run. seekrit's egress proxy substitutes the real value at the network boundary instead, so an agent's own process never holds it. 1Password's answer in this direction, Credential Broker, is in private beta, not yet generally available, and even once it is, delivers a scoped, time-limited existing credential to the workload, not a substitution at the wire.

Dynamic secrets. None found in 1Password's automation docs. seekrit's temporary-access covers seven targets.

Where 1Password is the better pick

A compliance list we can't touch. 1Password's trust center lists SOC 2 Type 2, ISO/IEC 27001:2022, 27017, 27018, and 27701, TISAX, CSA STAR Level 1, TX-RAMP Level 2, and a PCI DSS report. seekrit holds none of that yet.

One vendor for human and machine credentials. If your team already runs 1Password for passwords, Secrets Automation extends the same account and admin console to service accounts and CI.

An MCP server that genuinely matches our design. 1Password's new Environments MCP Server is explicit that "the server can only see the names of your secrets and Environments" and "by design, the server cannot return secret values... even if an agent requests them." That's the same split seekrit's hosted MCP server makes, and we'd rather tell you they got there too than imply we're the only ones.

Maturity and an existing CI/CD footprint. A documented Terraform provider, GitHub Actions, and two separate Kubernetes paths, backed by a company with a much longer track record than ours.

What self-hosting the Connect server costs

Service accounts talk to 1Password's cloud directly and need nothing self-hosted. The self-hosted path is Connect, a tool 1Password's own docs describe as something "you can deploy in your network," and it's worth being concrete about what that deployment is — their docs are notably thin here compared to what they're thin about elsewhere:

• Two containers and a shared volume. connect-sync and connect-api run together and "require a shared volume to store an encrypted copy of your data." The docs don't specify that volume's sizing, backup cadence, or restore procedure.
• A credentials file you protect. A 1password-credentials.json is generated uniquely per Connect server and holds what it needs to run; the docs don't say how to store or rotate it.
• High availability, backups, and upgrades: not addressed. We could not find guidance in 1Password's own docs for any of the three — which may mean Connect is simpler to run than Vault or a self-hosted Infisical, or may just mean it's less documented. We won't guess which.

To 1Password's credit, this is a small, bounded thing to deploy compared to a database-backed secrets platform — two containers and a volume, not a cluster. What we can't tell you, because their docs don't, is what backing that up or upgrading it safely looks like in practice.

seekrit needs none of this: npx -y @seekrit/cli init --org-name "Acme Storefront" --yes signs up and writes a config, with no container or volume of your own to manage, because the security model means there's no local credential cache for seekrit to ask you to protect. The API runs on Cloudflare's global edge, with no cluster for you to size and no server-side component standing between you and "the vendor can't read this" in the first place.

Fair counterweight: seekrit's own customer-side pieces — the egress proxy, seekrit run, the ESO sidecar, and the provisioner — do run in your environment, much like Connect does. They're single binaries or containers with no volume of persistent data behind them, not nothing, just smaller.

Where self-hosting Connect is still the right call: you need secrets served from inside your own network boundary, an air-gapped environment, or a policy that no third party — including 1Password's cloud — ever sees even ciphertext in transit for that access path.

Side by side

When 1Password is the right call

• You already run 1Password for your team's passwords and want one vendor and one admin console for people and machines both.
• A compliance attestation needs to be in hand today.
• You want static secrets, well-integrated, from a mature vendor.

When seekrit is the right call

• You want a credential broker today, not a private beta that still hands the workload a real, if scoped, credential.
• You need dynamic secrets.
• You want "where does decryption happen" answered the same way for every surface, not well-documented for one product line and silent for another.

The bottom line

1Password brought a genuinely strong answer to the breach question to a password manager, and is extending toward infrastructure and agents with real engineering and a compliance list we can't match. What we couldn't find is that same answer, stated with the same confidence, for the automation surfaces this page is about. Until 1Password says so plainly, we'd rather flag that than guess on your behalf.

npx -y @seekrit/cli proxy run --preset openai

Free for one developer, no card, and a security model with nothing left for you to infer.