5 Best Credential Vaults for AI Agents

The best credential vault for an AI agent is the one your security team will actually let you run: it stores the secret, audits the read, rotates it, and fits the identity system you already have. It is not, by itself, the component that should hand that secret to the model. Storage is the vault. Injection at call time is the broker. Teams buy the first and assume they have the second, then find the API key in an agent trace.

This is a short list on purpose — five vaults — and a long explanation of the split, because the split is the whole decision. If you came here for who should hold the token while the HTTP request is sent, the companion article is Best AI Agent Authentication Platforms in 2026. If you came for who runs the OAuth grant and selects the tenant, that is Best Managed OAuth Providers for AI Agents. A vault can sit underneath either of those. It does not replace them.

Vault and broker

A credential vault answers: where is the canonical copy, who may read it, when does it rotate, and what is the audit record of the read. HashiCorp Vault, AWS Secrets Manager, CyberArk, Doppler, and Auth0 Token Vault all answer that, for different kinds of secrets and different buyers.

A broker answers a later question: for this call, for this tenant, is the action allowed, and if it is, attach the right credential on the way out. The process that asked does not receive a bearer token to hold. The model does not have a tool argument named api_key.

You want both. The failure mode is buying only the vault and wiring it like this:

1. Agent starts.
2. Agent, or the service that wraps it, calls the vault.
3. Vault checks the workload identity and returns the secret.
4. The secret lands in an environment variable, a header the application sets, or a tool parameter.
5. The model runs for an hour with that value in reach of logs, traces, and whatever tool is allowed to echo its inputs.

Step 3 is a successful vault deployment. Step 5 is an ungoverned agent that passed a security review because the architecture diagram said "CyberArk" or "Vault" on it. The review measured the read. The incident happens after the read.

The test is one question, asked of a running process: can this process print the provider credential? If yes, you have a vault client. If the only thing it can do is name a method and a tenant, and a policy either sends the call or refuses it, you have a broker in front of the vault.

1. HashiCorp Vault

HashiCorp Vault is the general-purpose secrets manager most platform teams mean when they say vault. KV secrets, dynamic database credentials, cloud IAM, PKI, transit encryption, and a plugin model. The docs are

What it is best at. One audit log of secret access across a lot of systems. Dynamic credentials that expire, so a leaked database password dies. Namespaces and policies that map a workload identity to a path. This is the right system of record when many human and machine clients need secrets and you want one set of controls.

How agents usually integrate it. Vault Agent, the CSI provider, or a direct API read renders the secret into a file or an environment variable. The consuming process then uses it. That pattern is correct for a payment service you wrote and reviewed. It is the wrong end state for a model, because the model is not a reviewed binary with a fixed set of log lines. Dynamic secrets narrow the window. They do not change the fact that the process received the secret.

What to demand if you use it anyway. The workload identity that may read the agent path should not be the same identity the agent can assume inside a tool call. A policy that allows read on secret/data/prod/* from the agent's role is too wide, and Vault will faithfully allow it. Prefer a broker process, with its own role, that reads Vault and makes the vendor call, and an agent role that cannot read that path at all. If the agent role can read it, the vault is not between the model and the key.

Who should buy it. Platform and security teams who need a secrets control plane beyond one cloud account, dynamic credentials, and an audit trail of reads. Buy it as the system of record. Do not tell the board it is the agent control.

2. AWS Secrets Manager

AWS Secrets Manager stores secrets in AWS, encrypts them with KMS, rotates them with a Lambda or a managed rotation, and charges per secret and per API call. The guide is IAM decides who may call GetSecretValue. CloudTrail records the call.

What it is best at. Applications that already run in AWS and need a managed rotator for RDS, Redshift, DocumentDB, and for secrets you rotate yourself. There is no new control plane to operate. The identity story is IAM, which your cloud team already reviews.

How agents usually integrate it. The agent task role is granted secretsmanager:GetSecretValue. The SDK returns the secret string. From that line on, Secrets Manager is out of the conversation. Resource policies and VPC endpoints are real controls on the read. They are not controls on the subsequent POST to Stripe or Salesforce. A CloudTrail event that says the task read the secret is not an event that says the agent was allowed to refund invoice 4412.

What to demand. A separate task role for the broker, GetSecretValue scoped to specific secret ARNs, and no permission on the agent role. Rotation enabled, so a secret that did leak expires. If the agent framework and the tool-calling loop share one task role, you do not have this separation, regardless of how tidy the secret's resource policy looks.

Who should buy it. Teams standardized on AWS IAM who need rotation and a managed store. It is the default vault inside one cloud. It is not a multi-cloud secrets plane (that is Vault or CyberArk), and it is not an OAuth refresh engine for a hundred SaaS providers.

3. CyberArk

CyberArk is the privileged access platform enterprises already use for human administrators and for machine identities: vaulting, session isolation, rotation, and checkout of privileged credentials. Product docs live under Conjur (and Conjur Cloud) is the secrets side aimed at workloads and pipelines. Secrets Hub and the various credential-provider integrations push secrets into target platforms.

What it is best at. The control plane a bank or a large IT organization already trusts for privileged accounts. Checkout workflows, dual control, rotation of infrastructure credentials, and a vendor your assessors recognize. If the secret is a domain admin password or a root database account, this is the list you should be on, and the other four are the wrong comparison.

How agents usually integrate it. A credential provider or a Conjur sidecar retrieves the secret into the workload. Some patterns isolate the session so a human never sees the password. An agent is closer to the workload pattern than the human pattern: something retrieves the secret and the process uses it. Privileged session monitoring records a human clicking in a browser. It does not automatically record every HTTP call a model decides to make with a retrieved API key.

What to demand. Machine identity for the broker, not for the agent. Retrieval scoped to the specific credential. No "the agent can check out any secret in this safe." Dual control and approval in CyberArk are for the checkout. They are not a substitute for a per-method policy on the API call after checkout. Use CyberArk for the privileged secret's lifecycle. Use an execution policy for the action.

Who should buy it. Enterprises that already run CyberArk for privileged access and need machine credentials in the same audit regime. Do not stand up CyberArk only because an agent project needs OAuth to Gmail. That is a managed OAuth problem.

4. Auth0 Token Vault

Auth0 Token Vault is a vault for a specific kind of secret: third-party OAuth tokens obtained when a user connects Google, Slack, or another identity Auth0 federates. Refresh stays with Auth0. The documented way to use the secret is a token exchange that returns the provider's access token to your application or agent. The two pages that state this are Call third-party APIs on a user's behalf and Access token exchange with Token Vault.

What it is best at. You already run Auth0. The human is an Auth0 user. The APIs are OAuth connections in that tenant. You want refresh handled, and your backend is an environment you accept holding a short-lived provider access token. This is a better fit than putting refresh tokens in Secrets Manager yourself.

Why it is still a vault, not a broker. The exchange response body contains the external access token. Your code is then responsible for calling the third-party API and for keeping that token out of the model context. Auth0's docs describe the agent performing that exchange. If the agent is the process that receives access_token, the vault has done its job and the broker step was skipped. You can put a backend you trust between Auth0 and the model. That backend is the broker. Token Vault does not become one because the secret spent time inside Auth0.

Who should buy it. Auth0 customers connecting a limited set of OAuth providers on behalf of Auth0 users. Confirm current connection coverage in the dashboard. Nango's 28 September 2026 roundup described the surface as OAuth-only and on the order of 30 APIs; do not plan a long tail of API keys on that sentence, and do not ignore it without checking. API keys and arbitrary B2B connectors belong in a managed OAuth catalog or in the execution runtime's own connect flow.

5. Doppler

Doppler is a developer-focused secrets manager. Projects and configs map to applications and environments. The integration model is sync: Doppler injects secrets as environment variables into a runtime, a CI job, or a platform (the docs start at ). Access is audited. Rotation and sharing across a team are the product, not an HTTP policy engine.

What it is best at. A company that is tired of .env files in Slack and wants one place developers and CI read configuration from, with per-environment access and an audit log. For that job it is often a better buy than standing up Vault. The operational weight is lower, and the integration you will actually maintain is "the process starts with the right env."

Why that integration is the problem for agents. Environment injection is the feature. The process environment is exactly where an agent framework, a shell tool, and a careless log line can see the value. Doppler can restrict which config a service token may read. It cannot restrict what a model does after the variable exists. Treat Doppler as the store for secrets your *reviewed* services need. Do not point the agent's service token at the production config that contains vendor keys, then call the agent governed because Doppler's activity log shows a read.

Who should buy it. Engineering teams who need shared, environment-scoped secrets for services and CI, and who will keep agent workloads on a token that cannot read those configs. Infisical and similar developer vaults sit in this same column; the selection among them is hosting, price, and whether the sync integrations match your platform. The column does not include "safe for the model to hold."

The broker next to the vault

Swytchcode is not a replacement for Vault, Secrets Manager, CyberArk, or Doppler. It does not offer a KV v2 mount, a KMS-backed rotation Lambda, or a privileged session recorder. If a procurement checklist says "credential vault," Swytchcode will fail that checklist, and it should. The checklist is about storage.

What it does is the step after storage, on the agent path:

• You connect a provider once, with `swy auth connect`, or an end user connects with --tenant.
• The agent calls a method. The exec reference is explicit that credentials are not inputs. Swytchcode adds the credential itself, including when the tool schema has a token field.
• Policy runs first. A deny does not open the connection. The rules and the order are in the policies overview and in policy guardrails.
• For your own customers, tenant_id selects which connected account is attached. The Python SDK states that a call for an end user never falls back to your account. A missing connection is tenant_not_connected.

That is injection at call time. The model can print its tool arguments and still not print the OAuth access token, because the token was never an argument. A vault read log will not show the agent reading prod/stripe, because the agent role should not be able to.

Enterprise is the deployment where this matters most to a vault program. Swytchcode Enterprise runs in your AWS, Azure, or GCP account, and application data and API keys stay in that environment. The description is on the enterprise page and in pricing. Your vault can remain the system of record for human and workload secrets. The execution path is what the agent is allowed to invoke.

Managed OAuth apps on the Free plan, and your own OAuth apps from Pro upward, are how provider grants are created. That is the OAuth half of credential handling, covered in the managed OAuth article. It is still not "the agent called GetSecretValue."

What to stop doing

These are the integrations that look governed and are not.

• Vault Agent template into the environment of the agent process. The template succeeded. The model shares the environment with a shell tool.
• `GetSecretValue` in the tool-calling loop, with the secret passed back into the model as a tool result "so it can set the header." The model is now the HTTP client.
• Auth0 token exchange inside the agent, because the documentation said the agent can exchange. Move the exchange, or skip it and call through a broker that never returns the provider token.
• One Doppler service token on the agent host that syncs the production config, because that was the fastest way to get the demo to send mail.
• A CyberArk checkout at the start of a session that drops a password into a file the agent can read.

The replacement is dull. The agent names the method discover returned, and the arguments that method expects. The runtime checks the policy, selects the tenant, attaches the key, sends the request, and returns the refund object with the key redacted. Connect fintech APIs to Claude is that pattern on payment processors. How to build a GitHub AI agent is the same pattern where the thing you must not put in the model is a token that can delete a repo.

Side by side

How to choose

1. If the secret is privileged infrastructure, shortlist CyberArk if you already run it, otherwise Vault. Scope machine identity to a broker.
2. If the secret is an AWS-hosted application secret, Secrets Manager, with the agent role denied.
3. If developers need shared env-scoped config, Doppler or a similar developer vault, and do not mount the production vendor keys into the agent.
4. If the secret is a user's OAuth grant and you live in Auth0, Token Vault, with the exchange in a backend you control, or skip the exchange and let an execution runtime hold the call.
5. If the agent must call the API, add the broker regardless of which row above you picked. Swytchcode is that broker on the CLI, MCP, and SDK path. The map of those entry points is Different ways to use Swytchcode.

Frequently asked questions

What is the best credential vault for AI agents?

For a multi-system secrets plane, HashiCorp Vault. For AWS-only workloads, Secrets Manager. For an existing privileged-access program, CyberArk. For Auth0 customers connecting third-party OAuth, Token Vault. For developer and CI configuration, Doppler. None of those five make an agent safe on their own. The best *program* is one of those vaults plus a broker that never returns the provider credential to the model.

Is a credential vault the same as managed OAuth?

No. A vault stores what you put in it. Managed OAuth runs the consent flow, stores the resulting tokens per tenant, and refreshes them under that provider's rules. Some products do both. A KV store with a pasted refresh token is only the first.

Should the agent be allowed to read the vault?

No. Give read access to the process that sends the HTTP request and is not the model. If that process is Swytchcode, the agent calls a method and a tenant id. If you later find GetSecretValue in the agent's role, the separation is gone.

Does Swytchcode replace HashiCorp Vault or CyberArk?

No. Those products remain the system of record for secrets, dynamic credentials, and privileged access. Swytchcode is the execution path for the API call. Enterprise deployment keeps API keys in your cloud account; it does not import your Vault policies.

Where does the token live during a Swytchcode call?

On the connected provider account for that project or that tenant. The exec command does not accept it as an input. Policy either allows the runtime to use it or stops the call first. See exec and authentication.

Where to go next

• Best AI Agent Authentication Platforms in 2026
• Best Managed OAuth Providers for AI Agents
• How to build a GitHub AI agent
• Connect fintech APIs to Claude
• Documentation