Bitwarden Secrets Manager vs Keeper Secrets Manager

Bitwarden Secrets Manager

End-to-end encrypted, decrypted only on the client that holds the token. No release since 22 May 2026, and the npm SDK is still 1.0.0 from September 2024.

Keeper Secrets Manager

Each client device signs requests with its own key, is locked to an IP address by default and can be revoked alone, and secrets decrypt only on the client. The add-on has no public price, no request limits were found in the reviewed documentation, and a person must create the application and device in the vault.

Bitwarden Secrets Manager

1. Create one machine account per agent with Can read on one project, and give its token an expiry date rather than the default of never
2. Run the agent under bws run -- <cmd> so secrets arrive as environment variables and aren't written to disk or into the context
3. Fetch with bws secret list <project-id> --output json once per run; bws secret get needs the secret's UUID, not its name
4. Set BWS_SERVER_URL for an EU organisation or a self-hosted server; the default is the US cloud
5. Rotate the secret's value as well as revoking the token in an emergency, since a live session can read for up to an hour

Keeper Secrets Manager

1. Ask the vault owner for a new device on an application that holds only the folders the task needs. Use the Base64 configuration, not the first one-time token
2. Run commands under ksm exec so secrets arrive as environment variables and stay out of the model's context
3. Expect HTTP 403 with {"error":"throttled"} under load. The Python SDK retries five times from 11 seconds, so allow for long waits
4. A device is locked to the IP address it first connects from unless it was created with --unlock-ip. Check this before running from a dynamic address
5. Leave --auto-approve off on the MCP server. It removes confirmation for deletes and for unmasking values