Google Cloud Secret Manager vs HashiCorp Vault + Vault MCP Server

Google Cloud Secret Manager

Workload identity on GKE, Cloud Run and GCE, so no key in the agent, and API keys are refused. Managed rotation only covers Cloud SQL; other rotation is a Pub/Sub notification you handle.

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.

Google Cloud Secret Manager

1. Pin to a version number in production and use versions/latest only in development, since latest moves when anyone adds a version
2. Grant roles/secretmanager.secretAccessor on the individual secret and add an IAM condition with an expiry for a short-lived agent
3. Turn on Data Access audit logs for secretmanager.googleapis.com if you need a record of each read
4. Read once per run and cache; accesses past 10,000 a month are metered
5. Use a regional secret (projects/*/locations/*/secrets/*) when the data must stay in one place, and note the higher write quota there

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