AI projects accumulate powerful credentials quickly: model-provider keys, MCP OAuth grants, database URLs, deployment tokens, SSH keys, and service accounts. Putting all of them in one shared .env file or chat message creates a large, invisible blast radius.

The right tool depends on who needs the secret and where it is used. A developer password manager is not automatically a production secrets platform, and a cloud vault is not always the best place for a human login.

Some product links are affiliate links and may earn AI Made Tools a commission without changing your price. Verify current features and pricing with each provider.

Quick decision

Need	Appropriate starting point
Personal logins, SSH keys, recovery codes	Password manager such as 1Password or Bitwarden
Local development API keys	Password manager CLI or encrypted developer-secret workflow
Hosting-platform deployment	Platform’s encrypted environment/secrets feature
Production services across cloud infrastructure	Cloud secret manager or Vault-style system
Agent access to a user’s third-party account	OAuth grant with narrow scopes—not a copied password
High-scale machine identity	Short-lived workload identity where supported

The four layers

Password managers

1Password and Bitwarden are designed primarily around people and teams. They can store logins, API keys, SSH keys, secure notes, and recovery material. Their CLIs can also inject values into development commands.

They are useful for:

• assigning ownership to human-managed credentials;
• sharing development secrets without plaintext chat;
• protecting SSH keys and recovery codes;
• onboarding and offboarding team members;
• keeping provider keys out of repositories.

They are less suitable as the only runtime dependency for a large production fleet. Evaluate availability, audit, rotation, service identity, and automation requirements separately.

Deployment-platform secrets

Vercel, Railway, GitHub Actions, Cloudflare, and other platforms provide encrypted configuration for their own workloads. This is convenient and usually appropriate for a small number of deployed services.

The limitation is fragmentation: the same key can be copied into multiple platforms, making rotation and inventory difficult. Prefer separate credentials per environment and service when providers allow it.

Cloud secret managers

AWS Secrets Manager, Google Secret Manager, Azure Key Vault, and similar services integrate with cloud identity, audit logs, and runtime access. They are a natural fit when your application already runs in that cloud.

Use workload identity instead of another permanent bootstrap key when possible. The service should prove who it is and receive only the secrets it is authorized to read.

Vault-style systems

HashiCorp Vault and similar products can centralize policy, dynamic credentials, leases, revocation, and audit. They provide powerful control but also introduce an operational system that must itself remain available and secure.

Do not self-host a vault merely to avoid paying for a simpler managed solution. Operational complexity is part of the security model.

What AI agents change

An agent can turn a credential into actions. Treat its identity separately from the user who started it.

For each agent, define:

• allowed tools;
• allowed accounts and resources;
• read versus write permissions;
• per-run and per-day budgets;
• credential lifetime;
• actions requiring confirmation;
• an audit record;
• an emergency revocation path.

For third-party accounts, prefer OAuth with narrow scopes. Do not give an agent a user’s password or permanent personal token when delegated access exists. Read AI agent authentication, OAuth for agents and MCP, and the MCP authentication guide.

Development workflow

Keep a committed template containing names, not values:

MODEL_PROVIDER_API_KEY=
DATABASE_URL=
MCP_CLIENT_SECRET=

Load real values from an approved local mechanism. Block .env files from source control, add secret scanning, and assume a committed key must be revoked—not merely removed from the latest commit.

Some password-manager CLIs can inject values for a single process:

op run --env-file=.env.tpl -- npm run dev

This reduces plaintext copies but does not eliminate endpoint security or shell-history risks. Review the tool’s current behavior and your team’s threat model.

Rotation that works

A rotation procedure should answer:

1. Who owns the credential?
2. Which services use it?
3. Can old and new values overlap during deployment?
4. How is the new value distributed?
5. How do we verify traffic uses it?
6. How is the old value revoked?
7. What breaks if rotation fails halfway?

Provider keys used by several unrelated services are difficult to rotate safely. Issue separate keys and budgets where possible.

Product comparison criteria

Do not choose on vault count alone. Compare:

• CLI and developer workflow;
• SSH support;
• service accounts or machine access;
• audit events;
• access policies;
• sharing and recovery;
• SSO and offboarding;
• secret rotation;
• hosting and data-region requirements;
• export and migration options.

1Password can be a strong developer workflow, Bitwarden offers an open-source and self-hostable option, and cloud secret managers fit production workloads already inside their identity systems. Vault earns its complexity when dynamic credentials and centralized policy solve a demonstrated need.

Minimum safe architecture

• Human credentials live in an approved password manager.
• Local API keys are injected without committing plaintext.
• CI and hosting use encrypted secrets with access limited by project.
• Production services use separate identities and credentials.
• Agents receive scoped, revocable access.
• Logs redact secrets and sensitive tool arguments.
• Rotation and incident procedures are tested.

Continue with AI Security & Credentials, API authentication, and environment variables from local to production.