AWS Secrets Manager vs HashiCorp Vault + Vault MCP Server

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.

HashiCorp Vault + Vault MCP Server

Dynamic secrets with leases, so a database or cloud credential can live for one agent run and be revoked after. The MCP server's newest build is 0.2.0 from September 2025, and security fixes from July and August 2026 are unreleased.

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. Use BatchGetSecretValue with a filter when you need several secrets at start-up; it's limited to 100 calls a second
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

HashiCorp Vault + Vault MCP Server

1. Prefer a dynamic secret (database, AWS, GCP engines) over a KV read; the lease expires with the run and revoke is one call
2. Log in with AppRole or Kubernetes auth and keep the token for its TTL. Renew with auth/token/renew-self rather than logging in per request
3. For KV v2, GET /v1/<mount>/data/<path> and read data.data, and pass cas on writes so a retry can't overwrite a newer version
4. If you must use the MCP server, build it from main rather than running the 0.2.0 image, run it over stdio, and give it a token limited to one mount
5. Ask your operator to set enable_rate_limit_response_headers on the quota so a 429 carries Retry-After