1Password service accounts, SDKs and Environments MCP vs Google Cloud Secret Manager

1Password service accounts, SDKs and Environments MCP

Service accounts scoped per vault to read, write or share, with an optional expiry and permissions that can't be changed after creation. Teams, Families and Individual get 1,000 service account reads an hour per token, and the 429 carries no Retry-After.

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.

1Password service accounts, SDKs and Environments MCP

1. Read secrets by reference (op://vault/item/field) with client.secrets.resolve or resolveAll, and keep the reference, not the value, in config
2. On Teams or personal plans budget for 1,000 reads an hour per token and cache resolved values for the run; a 429 means wait for the hourly window, there's no Retry-After
3. Create the service account with only read_items on one vault and --expires-in set to the job length, since permissions can't be narrowed later
4. Set integrationName and integrationVersion in createClient so the usage report shows which agent read what
5. Don't ask the Environments MCP server for a value. Use it to find the variable name, then load it with op run or the SDK

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