TL;DR
- Give each client a separate credential boundary, service identity and offboarding record. A folder of environment files owned by one operator is a fragile agency operating system.
- Infisical fits teams wanting identity/project controls across human and machine access. Doppler is a practical application-configuration candidate. Vault suits teams needing dynamic credentials and deeper infrastructure control. AWS Secrets Manager fits an AWS estate with IAM and supported rotation paths.
- Rotation must update the provider and every consumer. Changing only the stored value does not invalidate the old credential or make applications use the new one.
- Price people, machine identities, secret count, API retrievals and operating effort. One hundred client credentials do not necessarily require one hundred paid human seats.
The client boundary comes first
An agency may operate CRM enrichment, outreach, research and reporting for several customers. Each workflow needs credentials, but its operator should not automatically inherit access to every client's systems. Separate production and test environments, assign service identities and grant only the project access the job needs.
Keep an inventory containing provider, client owner, authorised scope, consumer, rotation method and last verified recovery procedure. Store the secret value in the manager, not the inventory or repository. A screenshot of a token page is another copy of the credential, not useful handover evidence.
Our MCP gateway guide covers central tool access. Secrets management concerns the underlying credential lifecycle, including jobs that never use MCP. The GTM coding-agent guide covers the environment in which operators may build those jobs.
Decide ownership before implementation. The client should know which account owns the provider subscription and who can revoke access. An agency-owned key for a client-owned CRM can become an awkward dependency when the engagement ends. Document that dependency rather than hiding it behind the automation's success status.
Four secret-management routes
| Route | Strong fit | Meter to inspect | Non-fit |
|---|---|---|---|
| Infisical | Cross-environment human/machine access | Identity entitlements and deployment | No capacity to maintain policy and integration |
| Doppler | Application configuration and scoped consumption | Seats and plan controls | Expecting stored tokens to rotate every external API automatically |
| Vault | Dynamic secrets and infrastructure policy | Edition, hosting and operations | Small agency without infrastructure expertise |
| AWS Secrets Manager | AWS workloads and IAM governance | Secrets, API calls and rotation services | Multi-cloud estate with no shared AWS operating model |
Infisical
Infisical's secrets management description documents project/environment access for humans and machine identities, with rotation policies. Its pricing distinguishes non-human identities and commercial features. Count the identities your implementation really needs rather than treating secret count as the sole tariff unit.
It is a useful candidate when an agency wants a consistent boundary across clients and deployment environments. Use separate project and service access, then test a machine identity attempting to read another client's configuration. Keep policies versioned and make the operator's access temporary where that is practical.
The limitation is operational discipline. A manager cannot stop someone pasting a retrieved key into an ungoverned file. Choose it when the team will integrate secret retrieval into deployment and runtime processes. Check self-hosted and cloud terms, rotation support for the actual provider, audit retention and enterprise access requirements before pricing.
Doppler
Doppler's service token documentation describes read-only access to a specific project configuration. Its service accounts separate programmatic access from a particular human. That is useful when an operator leaves but the client workflow must keep running.
Choose it for a clear application-configuration model with projects and environments. A workflow can retrieve only its needed configuration instead of copying an agency-wide environment file. The pricing page describes seat-based purchasing and plan controls; obtain the current package for the team and service-access requirement.
Do not confuse read-only access to the manager with read-only access at the underlying provider. A retrieved API key can still have administrator privileges. Scope the original credential and check whether the chosen provider offers automatic rotation or requires a separately maintained procedure.
HashiCorp Vault
Vault's secrets engines can store values or generate credentials through supported integrations. HashiCorp's dynamic secrets guidance notes the network access needed to the managed resource. This route is valuable when short-lived infrastructure credentials and detailed policy are actual requirements.
It fits a technically mature agency or client estate with staff who can operate availability, access and upgrades. Dynamic credentials can reduce reliance on shared long-lived values, but only where the service supports the integration. A static CRM API key does not become dynamic merely because Vault stores it.
Avoid Vault for a small team that would create a new critical service without reliable ownership. Price the current edition/deployment and support, not an old hosted product's tariff. The open implementation, hosted service and enterprise purchase have different operating responsibilities.
AWS Secrets Manager
AWS documentation describes storage and rotation, with rotation functions potentially adding Lambda charges. The pricing page lists a $0.40 per-secret monthly storage basis in its examples, with API requests and other services separate. Confirm region and current rates before publication.
This is an economical starting point for workloads already using AWS IAM. Restrict retrieval to the workload role and client resource boundary. Choose it when the rotation integration is supported or the team can maintain the required function.
The non-fit is assuming that an inexpensive secret store supplies an agency-wide operations console and automatic rotation for every SaaS key. Logs, policies, notifications and cross-client support remain work. Retain a documented owner for the underlying provider and its revocation path.
Rotate without breaking the client workflow
Treat rotation as a change sequence: create or update the provider credential, store the new version, make consumers use it, verify a bounded operation and revoke the old value. Where a provider allows overlapping keys, use the overlap intentionally and remove it afterwards. Where it does not, schedule a controlled interruption.
Find every consumer first. A weekly reporting job may still use a cached value while the daily enrichment job has already changed. Keep last successful use and configuration version in operational records without logging the secret itself. Test rollback before relying on it during a customer incident.
For agency email infrastructure, distinguish sending credentials, DNS access and the platform API. Rotating one does not revoke the others. Keep client-specific suppression and mailbox ownership intact during a credential change.
Use the ABM Account Scoring Template as a non-secret description of the account workflow and owner. The handover should explain what the credential enables, while the value remains in the authorised store.
Cost twenty clients
Twenty clients with five service credentials each produce 100 stored credentials. At the observed AWS storage basis, 100 secrets cost $40 monthly, before retrievals, rotation functions, logs and regional differences. If five workers per client fetch five values once an hour, that is 360,000 retrievals in a 30-day month. Caching and refresh policy change that count, but should not compromise revocation.
Assume access/rotation administration takes four hours at $60 per hour and supporting cloud services cost $20. AWS examples also list $0.05 per 10,000 API calls: 360,000 retrievals add $1.80 at that basis. Storage plus those assumptions is $301.80 monthly, before taxes, additional rotation calls and regional differences. If manual handling takes twelve hours instead, labour alone is $720. The largest saving can be repeatable ownership and offboarding, rather than a cheaper storage unit.
For seat/identity-priced services, count operators and workload identities separately. Obtain the tier granting necessary client isolation, audit and access controls. Do not pack unrelated client keys into one secret merely to reduce a tariff if it forces every reader to receive all values.
Offboard with evidence
Remove the operator's access, transfer valid client ownership, revoke old provider credentials and stop agency jobs. Confirm that a retired machine identity cannot retrieve the store and that an old cached key no longer works at the provider. Save the completion record without the credential values.
Choose the simplest manager that meets the client boundary and rotation requirement. Doppler or Infisical can reduce application-secret handling work; AWS fits an existing cloud estate; Vault earns its complexity for deeper infrastructure controls. The purchase succeeds when the client can understand and revoke the agency's access without depending on one departing person.
FAQ
Is an encrypted environment file enough?
It can protect storage, but access, versioning, rotation and offboarding still need a process. Once decrypted, copies can spread. A manager is useful when retrieval and revocation can be attached to named identities and client boundaries.
Should every client have a separate manager account?
Not necessarily. A shared service may provide adequate tenant/project isolation, while some clients require their own estate. Test the actual boundary and contractual ownership. The agency's convenience should not obscure who can read or revoke a client's credentials.
Does rotation revoke the old API key?
Only if the procedure changes or revokes the credential at its provider. Updating a stored string alone leaves the old key valid. Verify consumers and provider-side revocation as separate steps.
Can we put credentials in a handover document?
Use references to the authorised store, owners and recovery steps. Avoid values, screenshots and copied tokens. The receiving operator should gain access through the identity policy so that retrieval and later revocation remain controllable.
