1Password is widely used among developers and has spent the last several years expanding from password management into infrastructure secrets: the SecretHub acquisition in 2021, Secrets Automation, self-hosted Connect Servers, and in March 2026 the Unified Access platform, which adds discovery, vaulting, and audit for credentials used by AI agents alongside integrations with Anthropic, Cursor, GitHub, Vercel, and Perplexity. For organizations already standardized on 1Password, the case for using op and op run as the secrets layer too is strong: one vault, one auth flow, one admin surface.
Capy and 1Password are aiming at different problems. 1Password is building a unified credential layer across humans, machines, and AI agents: a single product that holds your engineers’ passwords, your service accounts’ API tokens, and the credentials your AI tools use to act. Capy is built for one specific surface: the developer-and-team .env workflow, with git-aligned branches, a committable manifest, and ciphertext-only storage on the service. Both can be the right answer; the choice depends on which problem you are actually trying to solve.
At a glance
How the trust models differ
1Password’s user vault uses a strong design. The encryption combines a user-chosen Master Password with a Secret Key generated on-device, and 1Password’s documentation states that they cannot decrypt user vault items without both. The Secret Key never leaves the user’s devices. For interactive op use from an engineer’s laptop, this is closer to client-side encryption than most managed products.
The CI/CD path uses a different model. 1Password Service Accounts are token-authenticated: the account presents a token, 1Password validates it, and 1Password’s infrastructure provides access to the vault items that account is permitted to read. Self-hosted Connect Servers can cache decrypted material in your infrastructure to avoid rate limits. In both cases, the trust boundary for machine workloads includes 1Password’s service in a way that the user-vault model does not.
For cloud and BYOC profiles, Capy encrypts values on the producing client and decrypts them on the consuming client. Ordinary local key files require the service’s outer-wrap operation and client-held inner key. A Transport v4 package can move that local material only in an encrypted envelope; the service cannot open it from storage alone. Endpoint security remains a separate responsibility.
How the workflow differs
1Password treats secrets as items in a vault. You add a value through the 1Password app or the CLI; you reference it from your code via a secret reference like op://vault/item/field; op run -- ./your-app resolves those references and injects them. The mental model is the password manager extended to env vars.
Capy treats secrets as values in a .env file. You edit the file directly and run capy; Capy encrypts each plaintext value on your machine, rewrites .env with capy:… snippets, and syncs the ciphertext through the service. You run your app with capy run -- ./your-app and the values land in the child process’s environment. Capy gitignores .env and commits the keep.lock manifest instead; keep.lock lists hash references rather than values, so a PR diff shows which secrets changed without exposing them; Capy has its own branches, switched with capy checkout, tracked independently of your git branches — keep.lock travels with the repo and Capy’s post-checkout and post-merge hooks run capy status so drift surfaces when you move around the tree.
Neither model is universally better. The vault model centralizes everything in 1Password’s product surface; the file model keeps the engineering workflow the way developers already work.
On the AI-agent question
1Password’s Unified Access positions AI agent security as discover, vault, audit: find credentials sitting in plaintext .env files, vault them, audit which agent used which credential when. The strategy is governance-oriented and fits a security or platform team that wants visibility into how AI agents use credentials across the organization. The partnership posture in March 2026 (Anthropic browser extension and Claude Code, Cursor agent hooks, GitHub Actions, OpenAI IDE integrations) is a real strength.
Capy’s client-side encryption keeps stored .env content and service-held data as ciphertext. It does not defend against an agent that can run Capy with your authenticated local access: that agent can invoke commands that decrypt values your account can use. The comparisons overview explains the boundary.
The two approaches are not exclusive. A team can use 1Password Unified Access to discover and audit credential usage across the organization, and use Capy for the engineering team’s .env workflow specifically, much as most teams already use 1Password for human passwords regardless of what they use for .env.
How to choose
1Password fits when one vault for humans, machines, and AI agents is the goal: when the buying decision sits with a security or IT team that wants centralized governance, and when 1Password is already standard in your organization. The integrations, audit, and partnership work they have shipped in 2026 are genuine strengths.
Capy fits when the engineering team’s .env workflow is the surface you are trying to improve: when you want secrets to live as values in a .env file and a keep.lock manifest in git rather than as items in a vault, when ciphertext-only storage on the service is a built-in property rather than a configuration choice, and when removing a teammate should be a single command that doesn’t require rotating values or revoking tokens. Teams that use both typically run Capy for the engineering workflow and 1Password for human passwords, with no overlap between the two. Last modified on October 2, 2026
