1Password service accounts, SDKs and Environments MCP vs Bitwarden Secrets 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.

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.

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

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