Doppler, Infisical Cloud, AWS Secrets Manager, and GCP Secret Manager all encrypt server-side: their staff, their infrastructure, and any party with legal compulsion to that infrastructure can in principle reach plaintext if compromised. 1Password’s user vaults use a Master Password + Secret Key model that is also client-derived; their Service Accounts (the typical CI/CD path) use a token model that is closer to the server-side products.
SOPS encrypts client-side too; you manage its recipient keys and access policies.
At a glance
¹ 1Password’s user vault is client-derived (Master Password + Secret Key); Service Accounts and Connect Servers use a server-mediated token model. ² SOPS leaves recipient-key management to you. The Capy entries describe stored data and its normal client cryptography; they do not claim to defend an unlocked device or browser running attacker-controlled code.
A different design philosophy
Capy treats secrets the way developers already treat code. The CLI mirrors git:capy checkout, capy push, capy deploy, per-branch secret sets you switch the way you switch code branches, and a keep.lock manifest that lives in your repo and shows up in PR diffs. The homepage puts it directly: “Like GitHub, but for secrets.”
Most tools in this category extend either the password-manager metaphor (vault items, RBAC dashboards, web UIs you log in to) or the cloud-runtime metaphor (IAM-scoped fetches at request time). Capy starts from a different question: what would secrets management look like if it followed the same disciplines you already apply to source code? How do we enable that while maintaining a secure identity-scoped storage and retrieval mechanism?
The answer produces specific design choices. A branch model borrowed from git, plus post-checkout and post-merge hooks that run capy status so drift surfaces as you move around the tree. Diffs that show up in PR review. A kick command that reads as cleanly as git revert. None of these is decorative; each is the answer to “how would a developer expect this to work?” applied to a domain that has historically been answered with dashboards and access policies. The team writes about wanting to “simplify to the point of invisibility”; the goal is for secrets to feel like the rest of the toolchain, not a separate one.
The corollary is intentional narrowness. There is no vault for human passwords (use 1Password). There is no rotation hook for AWS-managed RDS credentials (use ASM). There is no dashboard for non-engineering stakeholders to browse secrets in. Capy does the engineering team’s .env workflow, with the cryptographic and operational properties that workflow would have if it had been designed natively for it.
How each tool fits
1Password CLI (op / op run) is a strong fit for teams already standardized on 1Password company-wide who want a single vault for humans, machines, and AI agents. 1Password’s recent Unified Access launch pushes that direction further. Reach for it when one centralized vault across your whole organization is the goal.
Doppler is an established managed product with server-side encryption and a long list of built-in integrations. Reach for it when the trusted-vendor model is acceptable and a hosted dashboard for non-engineers is part of the buying criteria.
Infisical is the leading open-source platform; reach for it when self-hosting (and the platform team to run a stateful service in production) is the right fit for your org. Worth knowing: Infisical’s client-side end-to-end encryption mode was deprecated in their June 2023 product update. Encrypt-at-source has not been the default since.
AWS Secrets Manager is the AWS-runtime store: IAM-scoped fetches from inside Lambda / ECS / EC2 and automatic rotation hooks for AWS-managed credentials. ASM is the right place for an RDS password. It is not the right place for a developer’s daily loop.
SOPS is the file-encryption primitive most platform engineering teams already know. Reach for it when your team owns KMS or Vault and is already operating the recipient-key plumbing around it.
Capy is what you reach for when client-side encryption needs to be the default rather than an opt-in mode, when removing a teammate should be a single command rather than a rotate-everything event, and when you want secrets branched and reviewed the way the rest of your code already is. The architectural commitments are documented in zero-trust and cryptography; the team mechanics are in kicking and inviting.
Why this matters more with AI agents in the dev loop
For most of the last decade, the choice between client-side and server-side encryption was a defensible-but-academic distinction. AI coding agents have made it more practical. Claude Code, Cursor, Cline, and Copilot run on developer machines, read environment variables, and increasingly execute shell commands and HTTP requests on the engineer’s behalf. That changes an old threat: a successful prompt injection now means the attacker has whatever the agent process can read, fetch, or run. The credentialed-agent failure mode is not theoretical. The Comment-and-Control attack (CVSS 9.4, disclosed by Legit Security) exfiltrated a developer’sANTHROPIC_API_KEY via a prompt-injected pull-request title that an agent picked up while reviewing PRs. Check Point’s research on Claude Code Hooks (CVE-2025-59536, CVE-2026-21852) showed remote code execution and API-token exfiltration through the same surface. InjecAgent’s ACL 2024 benchmark of indirect prompt injections found roughly a quarter of agent runs against GPT-4 followed embedded malicious instructions, climbing to nearly half under reinforcement. GitGuardian’s State of Secrets Sprawl 2026 reports AI-service secrets leaking at +81% year-over-year, with commits carrying Claude Code’s co-author trailer leaking at roughly twice the baseline rate.
Client-side encryption changes this in a specific way. Under a server-side product, the developer’s machine continuously holds credentials that can fetch any project secret on demand, meaning a compromised agent process, a compromised CI step, or a subverted shell hook can pull the full set, encrypted-at-rest by the vendor or not. Under Capy’s cloud and BYOC profiles, ordinary files on disk are ciphertext bound to a two-party key. Exfiltrating an .env file, backup, or git object yields ciphertext rather than credentials. An agent that can run commands as you on an already-signed-in machine can still invoke Capy to decrypt values your account can use.
This is not a claim that any tool makes AI agents safe to use. An agent that legitimately needs a secret will hold it in memory while it works, and that surface is the same under every product in this category. It is a claim that the architectural choice (where encryption happens) controls which parts of the supply chain can read plaintext when something else fails. With server-side encryption, a compromised agent reaches everything the developer’s machine has authority to fetch. With client-side encryption, stolen or intercepted files are ciphertext—an agent with code-execution capability still reaches the same plaintext you do, since capy run and capy edit authenticate silently on your already-signed-in machine. The security property worth paying attention to in 2026 is the file-exfiltration and vendor-compromise surface, not a reduced code-execution blast radius.