AWS Secrets Manager vs Keeper Secrets Manager

AWS Secrets Manager

IAM roles support access without long-lived credentials on AWS compute services. Each API call is billed, making caching relevant to frequent reads.

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.

AWS Secrets Manager

1. Give the agent's task or instance role secretsmanager:GetSecretValue on the specific secret ARN, not a wildcard
2. Cache the value for the run, or read through the Workload Credentials Provider on localhost; each GetSecretValue is billed and logged
3. In Claude Code or Codex, install the aws-core plugin from the Agent Toolkit for AWS and pass secrets as {{resolve:secretsmanager:...}} references through asm-exec so values stay out of context
4. Pass a ClientRequestToken on PutSecretValue so a retry can't create a second version, and don't write more than once every 10 minutes
5. Read VersionStage AWSPREVIOUS if a rotation lands mid-run and the new credential isn't live yet

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