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

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.

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

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