Who can decrypt your secrets? 18 tools compared

Seven of the 18 tools in this guide can decrypt your secrets on their own servers. HashiCorp Vault, Infisical, Doppler and the secret managers of AWS, Google Cloud and Azure all encrypt values at rest and decrypt them inside the service when an authorized caller asks. A smaller group decrypts only on your devices, machines and CI runners, so the server stores ciphertext it can't open: Bitwarden Secrets Manager, Keeper Secrets Manager, Phase in its default mode, 1Password outside its Credential Broker preview, Akeyless when you hold a key fragment, and Crunu. File tools such as SOPS, Ansible Vault and git-crypt have no server at all; anyone with the file key can decrypt. This guide compares 18 products by that one question, quotes each vendor's own documentation, and explains what each model buys and costs.

Three questions to ask any vault

"Encrypted" on a vendor page can mean only encrypted at rest. That says nothing about who can read the values while the system runs. Three questions do:

1. Where are values decrypted when someone reads them? On the server that stores them, or on the device or machine that asked?
2. Who holds a key that can decrypt them? Only people and machines you granted, or also the service, its operators, or anyone with the right cloud permissions?
3. What does the server still see? Even when values are encrypted on clients, servers usually see names, users, times and sizes.

The answers sort products into three models, with a few hybrids between them.

Three models of decryption

Server-side decryption. The service holds a key, in memory or in a KMS it can call, and decrypts values to answer requests. Access control is a policy the server enforces. This design lets the server do work with values: sync them to other platforms, generate credentials on demand, rotate them, answer a simple API call.

Client-side decryption. Values are encrypted on people's devices and on the machines and pipelines that use them. The server stores ciphertext and keys wrapped to recipients' public keys, which it can't unwrap. Access control is partly cryptographic: a person who was never given a key can't read the data, whatever the server does.

No server. Encrypted files live in your repository or storage, and decryption happens wherever the key is supplied. Access is whoever holds the key, and history keeps every version.

Hybrids blur the lines: a service that keeps key fragments but needs one of yours to finish an operation, an enclave in the vendor's infrastructure that decrypts with a key your workload supplies, or a client-side product with an opt-in server-side mode for integrations.

The comparison

The table lists, for each product, where values are decrypted according to its documentation as of October 30, 2026. "Your side" means your devices, machines and CI runners, which can decrypt in every model because they are where the values get used.

The same data drives the side-by-side comparison of 18 products, which adds hosting, OIDC for CI, offboarding and other properties, each with a source.

Products that decrypt on the server

Cloud secret managers: AWS, Google Cloud, Azure

The three big clouds work the same way at the level that matters here. Values are encrypted at rest under a key managed by the cloud's KMS, and the service decrypts them for any caller that your access rules allow.

AWS is explicit. Secrets Manager uses envelope encryption with AWS KMS, and for GetSecretValue it "decrypts the secret value before returning it to the caller", per its encryption documentation. The same page notes that the secret's name and description, rotation settings, KMS key ARN and tags aren't encrypted. Parameter Store does the same for SecureString values, and keeps parameter names in plaintext.

Google Cloud Secret Manager wraps each data key with a key-encryption key owned by the service, or with your own Cloud KMS key under CMEK. Either way, Google's CMEK documentation says the service identity, rather than the caller, encrypts and decrypts secrets on your behalf. Azure Key Vault encrypts secrets when you add them and decrypts them automatically when you read them, and Microsoft suggests that for highly sensitive data you add another layer, such as encrypting with a separate protection key before storing it in Key Vault, per About Azure Key Vault secrets.

What a customer-managed key changes. It moves control of the key's policy to you: you decide which principals may use it, you see its use in audit logs, and you can disable it, which Google says makes the data encrypted with it unreadable. It doesn't move decryption out of the service. While the key is enabled, the cloud decrypts for whoever your IAM rules allow, and those rules are administered by people in your cloud account. Customer-managed keys don't stop the cloud from decrypting goes into the details.

This can be the right model. If your applications already run in one cloud and its IAM is how you manage access, a native secret manager adds little operational weight. Just describe it accurately: the cloud provider's service, and your account's administrators, can decrypt.

Doppler

Doppler's security fact sheet describes a tokenization design. When Doppler's web servers receive secrets, they send them to an internal tokenization service, which encrypts them with AES-GCM using the workplace's own 256-bit key and returns an opaque token that the web servers store. Workplace keys are themselves encrypted with an HSM-backed key in Google Cloud KMS, and an optional EKM setting adds encryption with your cloud provider's KMS.

The design limits what a breach of the web tier gives away: an attacker who reaches the web servers' database finds opaque tokens. It is still server-side decryption. Doppler's service can decrypt values, which is what lets it sync them to AWS, GCP, Azure, GitHub, Vercel and other platforms.

Infisical

Infisical has been described elsewhere as end-to-end encrypted, for example in EnvKey's 2024 wind-down email, which a customer posted on Hacker News, a secondary source. Its current security documentation describes server-side encryption: once traffic enters the server, sensitive data is encrypted before it is stored, and "before responding to a client request, the server securely retrieves and decrypts requested data from the storage backend." Each organization and project has its own data key. The keys are protected by an internal root key, which is encrypted with a 256-bit root encryption key that the operator provides as an environment variable, or that an HSM holds. The page notes that compromising the database alone isn't enough to decrypt data.

So with Infisical Cloud, Infisical's servers decrypt values; with a self-hosted instance, your server does, and whoever can read its root key or its memory can too. That is the model that makes its secret syncs and dynamic secrets possible. Is Infisical end-to-end encrypted? traces where the other description comes from.

HashiCorp Vault and OpenBao

Vault's encryption layer, the barrier, encrypts data before it goes to the storage backend, which Vault treats as untrusted, per its architecture documentation. After unsealing, Vault holds the encryption key and can decrypt stored data to serve requests. Access is enforced by policies on the server.

When Vault is self-hosted, "the service can decrypt" means "your Vault servers can decrypt", along with anyone who controls them. That is a reasonable trade for what Vault does with the key: dynamic database and cloud credentials, leases and revocation. OpenBao, a community fork, has the same architecture.

Products that decrypt on your side

Bitwarden Secrets Manager and Keeper Secrets Manager

Both come from password managers and keep their client-side design for machine secrets.

Bitwarden's decryption documentation describes the flow for a machine account: the access token contains a key; after authentication, the server returns the organization's symmetric key encrypted under it; the client decrypts that key locally, and then the secrets, which also arrive encrypted. Keeper's encryption model says encryption and decryption take place locally on the client device, and that the Keeper cloud stores and transmits only ciphertext and never possesses the keys required to read the secrets it serves.

1Password

1Password decrypts on your devices; its service doesn't hold the keys to your vaults in normal use. Its newer Credential Broker, for workloads that authenticate with workload identity federation, decrypts inside an attested enclave in 1Password's infrastructure, using a key that only exists inside the enclave and a key that only your workload can supply, per its Credential Broker design. The design states that the workload's key and the key held by 1Password don't work on their own.

One detail matters for teams. Removing someone from a vault "isn't cryptographically enforced" and "cryptographic keys are not changed", per 1Password's security design; its recommended way to give data a new key is to create a new vault and move items into it. The offboarding guide compares how products handle removal.

Phase

Phase is end-to-end encrypted by default. Its security page says that in this mode its servers store only ciphertext and can't decrypt secrets, and that every environment has its own key, wrapped to each account's public key. Server-side encryption is a per-app opt-in for third-party syncs or the REST API, and then the environment key is stored encrypted on the server so it can perform those operations. Phase therefore offers both models, and you choose per application.

Akeyless

Akeyless uses what it calls Distributed Fragments Cryptography. Key material is split into fragments generated in isolated environments, which never combine into a full key, per its DFC overview. Optionally, you hold one fragment yourself, in your own Akeyless Gateway. With a customer fragment, operations can't complete without it, and no party, including Akeyless, can derive the key without it. Without one, the fragments are all on Akeyless's side. The answer to "can Akeyless decrypt?" therefore depends on how you deploy it.

EnvKey

EnvKey described itself as end-to-end encrypted with NaCl, per its README. EnvKey Cloud began a six-month wind-down on August 1, 2024 and shut down on February 1, 2025. It stays in this comparison because teams are still moving off it; see the EnvKey alternative page.

Crunu

Crunu encrypts and decrypts only in the browser and in the crunu agent. The server stores ciphertext, environment keys sealed to each recipient's public key, public keys, HMACs of tokens and signed documents; it has no decryption key at any point. Each environment has its own key, so a person or machine granted development never receives the production key. Machines and CI pipelines decrypt in memory, with their own keys.

Two limits are part of the same answer. The server sees metadata: names of organizations, projects and environments, email addresses, the audit log, sizes and times of versions, and which versions were delivered to whom. And a compromised server could serve a tampered web client to people who sign in through it, which is the main remaining risk for any vault with a web interface. Crunu's defenses are signed releases, a reproducible web build and a local crunu.html file that checks the site against the signature. What the server can't read actually means and What the server sees list both sides precisely.

Products with no server

File tools put encrypted files in Git or storage and decrypt wherever a key is supplied.

• SOPS decrypts files locally with keys from age, PGP or a cloud KMS such as AWS KMS, GCP KMS or Azure Key Vault, per its documentation. With a cloud KMS key, anyone in your cloud account with permission to use that key can decrypt too.
• Ansible Vault decrypts content wherever the vault password is supplied, per the Ansible documentation.
• git-crypt decrypts on checkout for anyone holding the key, and leaves file names and commit messages readable, per its README.
• dotenvx decrypts wherever the private key, such as DOTENV_PRIVATE_KEY, is set, per its README. Its paid Armor plans list server-side decryption among their features, so the answer depends on the plan.

No server means no one else in the path, but also no access control beyond key possession, no record of who read what, and history that keeps old ciphertext readable with old keys.

Where machines and CI pipelines fit

Every model has to put the value somewhere it can be used, so the machine or runner that uses a value can always read it. What differs is how the value gets there and what else can read it on the way.

• Server-side vaults decrypt and send the value over TLS to an authenticated machine or pipeline. Revoking the machine's token stops the next request at once, because access is a server decision.
• Client-side vaults send ciphertext and a key wrapped to the machine's own public key, and the machine decrypts locally. Revoking a machine also means changing the keys it held, so that future versions are sealed only to the remaining recipients. In Crunu, revoking a machine rotates the keys of the environments it had a key for, and its agent wipes those environments from memory within minutes while the machine is online.
• File tools need the decryption key on the machine or in CI settings. If one key opens every environment's file, a CI key leak exposes everything, and removing it means re-encrypting every file.

In all three, a process that receives a value holds it until it exits, and whoever has root on that machine can read it. That is why OIDC-bound, narrowly scoped access for pipelines matters in every model; the CI/CD OIDC guide covers it.

One secret, three answers

Example. Kiteline is a fictional company. Its most sensitive value is STRIPE_SECRET_KEY in payments-api / production. Here is who could decrypt it under three setups.

• In AWS Secrets Manager, the Secrets Manager service, on behalf of any principal allowed to call GetSecretValue on the secret and to use its KMS key: the production role of the payments service, plus administrators of the AWS account who can grant themselves those permissions.
• In a SOPS file in Git encrypted to age keys, everyone whose age key is a recipient, for every version of the file in the repository's history, including people who have since left unless the data key was rotated and the value reissued.
• In Crunu, Priya Natarajan and Amara Okafor, whose keys the environment key is sealed to, and the machine api-prod-1. Jonas Lindqvist, who works on development and staging, can't, and neither can the server.

None of the three is careless. They draw the circle in different places, and the right one is the circle you can describe to an auditor without hesitating.

What server-side decryption buys

It would be unfair to present this only as a weakness. A server that can read values can do useful things with them:

• Generate credentials on demand, such as a database user that exists for an hour. Vault, Doppler, Infisical, Akeyless and Phase (with server-side encryption) offer dynamic secrets.
• Sync values into other platforms without a client in the loop: cloud secret stores, CI variables, hosting providers.
• Rotate values at providers on a schedule.
• Serve a value over a plain API call, which keeps clients simple.

If your team needs those, choose a server-side vault and protect the server accordingly: who has root on it, where its root key lives, and who can change its policies.

What client-side decryption costs

The other side has real costs too, and a vendor that hides them is selling, not informing.

• No dynamic secrets, syncs or provider rotation run by the server, because each needs a key on the server. Crunu doesn't offer them, by design.
• Recovery is harder. A vendor that can't read your data also can't reset your password. Crunu uses a password plus a Secret Key, an Emergency Kit and an optional recovery code; why a vault vendor can't reset your password explains the trade-off.
• The client becomes the target. Whoever controls the code that runs on your device can see what you decrypt. For a web client, that code comes from the server, which is why signed and verifiable clients matter.
• Metadata is still visible. Encryption on clients hides values, not who works with them.

Reading the labels

Words such as "end-to-end encrypted", "client-side encrypted" and "zero-knowledge" are used loosely, sometimes for transport encryption and sometimes for the real thing. Doppler's fact sheet, for example, mentions end-to-end encrypted communication channels while describing a design in which the service decrypts values. That is not a contradiction; it is a different meaning of the phrase. Ignore the label and apply the three questions to the vendor's architecture documentation.

When you evaluate a vendor, ask for these in writing:

• Where are values decrypted when a person, a machine or a pipeline reads them?
• Which keys does the service hold, in memory or through a KMS, and who can use them?
• Which features require the service to decrypt, and can they be turned off?
• What does the service store in plaintext: names, descriptions, tags, paths, audit details?
• When someone is removed, do keys change, or is removal a server policy?
• If the service is compromised, what can an attacker read immediately, and what only after users sign in?

For terms used on this page, see end-to-end encryption, client-side encryption, customer-managed key and server-side encryption. For how the answer changes when you run the server yourself, see the self-hosting guide.