The best secrets manager for AI agents

Roundup·every realistic option

The direct answer has two parts, and ask them in this order. First: if the vendor is breached, what does the attacker get? For most of the options below, a service holds a key that can decrypt what it stores — a root key, an unseal key, a KMS key — so the honest answer is "everything that key protects." Only seekrit answers "ciphertext and names, because no key on our side opens more than one principal's own grant." Second, and only relevant once an AI agent is in the loop: does the agent's own process ever hold the credential, or only a placeholder substituted at the network boundary? Today, that's seekrit or Infisical Agent Vault — nothing else on this page ships it, with one partial exception below. If you already run a different secrets manager and just want agents brokered, pair it with seekrit's or Agent Vault's proxy rather than migrating your whole secrets store. If you're one developer running one agent locally and nothing it touches is untrusted yet, plain environment variables are a reasonable starting point — not a mistake, just a choice with an expiration date.

Below is every option we think is realistic, with when to pick it — including where we think seekrit is the wrong one. Our longer roundup on recent credential disclosures is the broader version of why the first question matters right now: provider-side key exposure, not a clever exploit, is the thing that keeps showing up.

seekrit

If seekrit is breached: ciphertext and secret names, never a value — no seekrit process holds a key able to decrypt more than one principal's own grant. Our security model states that at its real strength (metadata is visible; third-party sync is the one opt-in exception; a leaked token still exposes what that principal held) and no stronger.

Pick seekrit when that answer matters to you, an AI agent is the one holding credentials and its own process should never see the value, and you want that paired with dynamic, auto-expiring credentials and an MCP server that structurally cannot hand an agent a secret value.

Not the right pick when you need dynamic secrets for a database or cloud target we don't cover yet (Vault and Infisical both reach further — see their pages below), you need a compliance attestation in hand today (we hold none — see our trust page), you want to self-host the entire platform yourself (seekrit is hosted SaaS only), or you're not running any agents at all, in which case the credential-broker piece buys you nothing over whichever vendor's plain secret injection you already use.

Infisical (and Infisical Agent Vault)

Two different products from the same company, and worth telling apart. If Infisical is breached: per their own architecture doc, one operator-held root key protects one internal key that protects every organization's data on that instance — self-hosting at least makes that root key yours alone. Infisical is a full, open-source, self-hostable secrets manager — the broadest dynamic-secrets catalog of anything compared on this site, plus PKI. Infisical Agent Vault is their current credential-broker product — a placeholder substituted at the network boundary, the same shape as seekrit's proxy — available on Infisical Cloud or self-hosted, and, by Infisical's own description, currently in preview. (A separate, now-deprecated open-source repo of the same name — its own README calls it "no longer the recommended way to run Agent Vault" — used to be what this entry compared; see our Agent Vault page for that history.)

Pick Infisical when you want to self-host the whole platform — database, dynamic secrets, PKI — with nobody's root key but your own, and you're prepared to run the Postgres and Redis their own docs call for. Pick Infisical Agent Vault when you already run Infisical and want brokering inside that same platform, on whichever of Cloud or self-hosted you're already using.

Doppler

If Doppler is breached: per its security fact sheet, a compromise of the tokenization service is a compromise of whatever per-workplace keys it can reach — HSM-backed, and strong engineering, but the service can decrypt by design. Pick Doppler when that isn't a blocker — most teams' isn't — and you want a mature SaaS secrets manager with broad integrations and SOC 2. It does not ship an agent credential broker, so an agent using a Doppler-sourced value still holds it in its own memory.

HashiCorp Vault

If Vault is breached: once unsealed, it's a central service that decrypts on request for anyone with a permitted token — single-tenant by deployment, but total within that instance. Pick Vault when dynamic secrets are the main event — 15+ database and cloud engines, encryption and PKI as a service — and you can run the storage cluster, unseal procedure, and upgrade drills their own docs call for, or pay for HCP Vault Dedicated to skip that. Worth knowing before you point an agent at it: HashiCorp's own Vault MCP Server docs warn that it may expose Vault secrets to the MCP clients and LLMs talking to it, and say plainly not to use it with untrusted clients or LLMs — an honest acknowledgment of exactly the risk a credential broker exists to remove.

1Password

If 1Password is breached: for the password manager, a well-documented no — the Secret Key never reaches their servers. For Secrets Automation (Service Accounts, Connect), their own docs don't say either way; see our 1Password page for exactly what we couldn't verify. Pick 1Password when your team already runs it for passwords and you'd rather have one vendor and one compliance list — SOC 2, ISO 27001, TISAX, and more. Their Credential Broker is in private beta and, even once GA, hands the workload a real (if scoped and time-limited) credential rather than substituting one at the network boundary — a narrower claim than seekrit's or Infisical Agent Vault's proxy.

AWS Secrets Manager

If a credential in your AWS account is compromised: everything secretsmanager:GetSecretValue and kms:Decrypt let that principal reach — AWS KMS performs the decrypt, gated by IAM, not by a key only you hold. See three hours from one developer token to full cloud admin for how fast that escalates in practice. Pick AWS Secrets Manager when your workloads already authenticate as AWS IAM principals and AWS's compliance programs already cover what you need. It has no credential broker and no dynamic secrets beyond a short list of AWS-native database engines.

Plain environment variables / .env files

If the machine is breached: everything, immediately, in plaintext — there's no vendor to ask the question of, because there's no broker between the value and whatever reads the process's environment. Pick this when it's one developer, one agent, running locally, and nothing it touches yet is untrusted input or an untrusted tool call. This is a genuinely fine starting point, not a mistake — every option above costs more setup than export OPENAI_API_KEY=sk-... does. The real risk is what happens as the agent grows teeth: a value sitting in a process's own environment is a value that process can be talked into printing, logging, or handing to a tool call, and that's exactly the shape of risk that scales with what the agent is allowed to do. The moment an agent runs a tool whose output you don't fully control — browses the web, reads a file someone else wrote, calls another API — is the moment to move the credential out of its process, with seekrit's or Infisical Agent Vault's proxy, rather than after something goes wrong.

Side by side

The bottom line

"Best" here means fit, not a ranking — the table above is rows that each change a real decision, not a scoreboard. If an agent holding the actual credential is the thing keeping you up, seekrit and Infisical Agent Vault — currently in preview, by Infisical's own description — are the two products built around not letting that happen; everything else on this page is a very good secrets manager that still hands the value over.

npx -y @seekrit/cli proxy run --preset openai

Free for one developer, no card — the cheapest way to find out whether a broker is the thing you actually needed.