Agent vaults compared, honestlyPick storage, pick delivery, pick operational fit.

Most secret managers were not built for coding agents. They were built for human developers, CI pipelines, or Kubernetes workloads. Agents are a different threat model, and picking the wrong tool for that model is how you get incidents that a secret manager was supposed to prevent.

A coding agent reads your entire ambient environment by default. It writes state files back to disk. It can exfiltrate values through tool calls, through its context window, through model outputs scraped by a compromised MCP server. The February 2026 Knostic disclosure found Claude Code shipping live environment variables into npm tarballs via settings.local.json, present in roughly 1 in 13 published packages. That incident happened because the agent saw the entire shell environment and wrote what it saw to a predictable path. The secret manager in use was irrelevant. The delivery model was wrong.

Two layers matter here: storage model (where the secret sits at rest) and delivery model (how the value reaches the process that needs it, and what else in your environment it reaches along the way). Picking well on one while ignoring the other is how incidents happen.

What to know in 60 seconds

• "Secret management" covers at least four distinct architectures. Pick the wrong shape and you add operational complexity without improving the threat model.
• Process-scoped delivery (inject into a child process rather than your shell session) is the property most developers skip. Most tools support it. Most teams do not use it by default.
• Ask "what is secret zero?" before buying anything. If your agent needs a long-lived credential to fetch its secrets, you moved the problem, you did not solve it.
• The cloud-native options (AWS, Doppler, Infisical) all require your agent to have network access and a service account credential at startup. That credential is secret zero.
• On-call burden and switching cost matter as much as the feature list. A tool that costs 40 hours to rotate out of your stack is a liability when the category evolves fast.

The shapes of the answer

Four architectural categories cover the eight tools below, and the category choice matters more than any individual feature.

Enterprise vaults (HashiCorp Vault) are full credential lifecycle systems: dynamic secrets, PKI, database credential brokering, policy as code. The feature surface is vast. The operational surface matches it. These make sense when you already have platform engineers running them.

Cloud-native secret managers (AWS Secrets Manager + IAM Identity Center, Doppler, Infisical) push the trust boundary to the cloud provider. Your agent gets a service identity, your cloud grants secrets based on that identity. The trade is operational simplicity against a required network hop and a secret zero (the service account credential or IAM role binding).

CLI-native password managers (1Password CLI, op) began as human credential stores and grew CLI and service-account primitives. They work reasonably well for small teams already on the platform. The agent delivery story is op run -- <command>, which is process-scoped and decent.

File-based, GitOps-friendly (SOPS + age) encrypt secret files at rest, check them into git encrypted, decrypt at runtime. The threat model is different from a vault: the ciphertext lives in version control, the private key (age identity) is the trust anchor. Works well for teams where secrets drift between branches and IaC files need to stay in sync with the repo.

Process-tree brokers (hasp, and a category of smaller startups building adjacent tooling) sit between the agent and the credential store. The agent calls through the broker at exec time, the broker injects values into a child process, and nothing persists in the ambient environment. This architecture maps most directly to the agent threat model and is the most recent category to emerge.

Comparison matrix

Each option, assessed

HashiCorp Vault

Vault is the right answer for enterprise secret management, and that same depth makes it expensive to run for most agent workloads. Dynamic secrets (database credentials that expire after 10 minutes, AWS creds that rotate per lease) are the feature that justifies the infrastructure cost. For production-grade agent pipelines where an agent touches a database and you want provable time-bounded access, Vault has no peer in this list.

The operational cost is real. You need a Vault cluster, or HashiCorp Cloud Platform. You need AppRole or Kubernetes service account auth wired up. You need Vault Agent running as a sidecar if you want transparent injection into processes. For a solo developer or five-person team, this is weeks of infrastructure work before you can give an agent a database credential.

Vault's audit log is excellent and multi-sink. The BSL 1.1 license matters if you are building a product on top of Vault, less so if you are using it as infrastructure. The agent-delivery story exists but requires vault agent configuration. If you already run Vault for human access, adding agent pipelines is a natural extension. If you are starting from scratch for agents, start somewhere else.

1Password CLI (op)

1Password is the least-friction option for teams already paying for 1Password. op run -- <your-command> injects secrets from a named vault as env vars scoped to that child process. The agent subprocess gets the values; your shell session does not accumulate them.

The audit log is per-vault activity, visible in the 1Password web UI. It is adequate but not structured for programmatic analysis. The service account model works: you create a bot account with read access to a specific vault, store the service account token in your CI or your local keychain, and op authenticates with it.

The weaknesses are the same as any password manager with an agent overlay: you cannot express "this agent profile gets these secrets and no others" at any finer granularity than vault ACLs. You also pay for a SaaS product. There is no offline mode once the service account token is provisioned. And the biometric unlock on op assumes a human is nearby; in unattended pipelines you need the service account flow.

Doppler

Doppler has the cleanest developer experience in this category if you want a SaaS-managed store with a CLI that does not require infrastructure to run. doppler run -- <cmd> is the delivery primitive, same shape as op run. You map a Doppler config (project + environment) to a command, and the injected values are process-scoped.

The strong point is the UI: Doppler's web interface makes it fast to see which secrets exist across environments, who changed what, and when. The audit log is per-config. Syncing secrets to Vercel, GitHub Actions, and AWS Parameter Store is built in.

The weak points: you need network access at agent exec time. Every doppler run makes an outbound API call. If your agent runs in an air-gapped environment, Doppler does not work without a self-hosted relay. The service token is secret zero, and Doppler's short-lived tokens require periodic rotation. At scale, you pay for per-seat pricing that adds up faster than AWS Secrets Manager. Doppler's platform has had service disruptions; when the API is down, your agents cannot fetch secrets.

Infisical

Infisical is an open-source alternative to Doppler with a self-host option that functions without a managed relay. The MIT-licensed core covers the local secrets server, the CLI, and the API. Enterprise features (SAML, audit log forwarding, secret versioning with approval workflows) are proprietary.

infisical run -- <cmd> is the delivery primitive. Same model as Doppler and op. Machine identities (their term for service accounts) use short-lived JWT tokens via OIDC, which is cleaner than long-lived service tokens. The self-host path removes the network dependency: your Infisical server runs in your VPC, agents talk to it over the local network.

The catch is operational overhead. Running Infisical self-hosted means you are responsible for the database, upgrades, and availability. The cloud-managed option brings back the Doppler trade: you depend on Infisical's uptime. For a startup that wants self-hosted secret management and is willing to own the ops, Infisical is the best open-core option in this list. For teams who are not staffed to run databases and keep a server patched, the overhead often exceeds the benefit.

AWS Secrets Manager + IAM Identity Center

If your infrastructure already runs in AWS and your agents run on EC2, ECS, or Lambda with instance roles, AWS Secrets Manager is the natural fit. The IAM role is the trust anchor. The instance metadata service issues temporary credentials, and Secrets Manager checks the role. Secret zero is the role binding itself, which IAM manages.

The delivery story is weak by default. There is no aws run -- <cmd>. You call aws secretsmanager get-secret-value, parse the JSON response, and wire the value into env vars yourself. For teams building custom agent pipelines on Lambda, this is fine: you write the wrapper. For teams running Claude Code or Cursor on developer laptops, this is the wrong tool.

CloudTrail captures every Secrets Manager API call. For compliance teams, that is valuable. The storage cost is $0.40 per secret per month plus $0.05 per 10,000 API calls, which is not the budget concern it sounds like until you have hundreds of secrets with high call volume. Cross-region replication and automatic rotation to RDS and Redshift are useful for production database credential management. This is enterprise infrastructure, and it is correctly priced for that.

SOPS + age

SOPS (Secrets OPerationS, from Mozilla) encrypts YAML/JSON/ENV files and stores the ciphertext in git. age replaces PGP as the encryption backend: simpler key format, faster operations, no key server dependency. The workflow is: encrypt a .env.enc file with your age public key, commit it, decrypt at runtime with your private key.

For GitOps workflows where secrets need to track branches alongside IaC, SOPS + age is the right shape. The secret lives in the same PR as the config change that needs it. Code review sees the diff in encrypted form (meaning reviewers see which keys changed, not the values). The age private key is the trust anchor.

For agent delivery, the model requires extra work. You decrypt the file to a temp location, source the values into the agent process, then clean up. No built-in command handles this end to end; you write the wrapper script. For unattended agent pipelines, the private key also needs to be available, which means storing it somewhere (the developer's keychain, a KMS-backed key, hardware tokens). The threat model is "protect the key" rather than "authenticate to a service."

SOPS + age does not have an audit log beyond git history. You can see who committed what when, but not who decrypted what. For most small teams that is acceptable. For compliance audits, it is a gap.

hasp

hasp is a process-tree broker. It keeps secrets in a local encrypted vault (Argon2id, 64 MB memory, 3 iterations, 4 lanes, AEAD at rest) and injects values into child processes at exec time. The agent subprocess gets the values; the parent shell does not accumulate them. When the subprocess exits, the values are gone from memory.

The delivery model is the strongest argument for hasp in an agent context. hasp run -- claude code starts a Claude Code session with exactly the secrets bound to that project, using one of six first-class agent profiles (claude-code, codex-cli, cursor, aider, hermes, openclaw, plus a generic fallback). The 11-output-encoding redactor scans streaming output for secrets and strips them. The HMAC-chained audit log at ~/.hasp/audit.jsonl records every grant; hasp audit --verify confirms the chain has not been tampered with since the last entry. Grants expire at 24 hours ceiling.

The limitations are real: hasp runs only on macOS and Linux. There is no Windows support. There is no team sync, no SaaS UI, no shared vault across developers. The FCL-1.0 license is source-available (not OSI-approved open source) until 2027, when it converts to Apache 2.0. For a solo developer or a very small team where each person runs their own local vault, hasp fits. For a team that needs shared secret access and centralized management, it does not. Local-first is a design choice, not a workaround for that gap.

Broker-of-the-week startups

The agent-native secret broker category is new. Several small startups are building in this space. Most of them are SaaS-first, which means service account credentials (secret zero exists), network dependency, and proprietary storage. The "agent-aware" claims vary. Some products do process-scoped injection correctly. Some inject into a shell script that then exports to the ambient environment, which is the same failure mode as a sourced .env file.

If you are evaluating a startup in this category, the questions below apply more directly than to the established tools. The space is worth watching. At the time of writing, none of the smaller entrants have shipped a verifiable audit trail or a published threat model document. That may change.

Decision matrix: who should use what

Solo developer, macOS or Linux: 1Password CLI if you already pay for it. hasp if you want process-tree isolation and a verifiable local audit log and you're willing to set it up. SOPS + age if your secrets live in git-tracked config files.

5-person startup, mixed platforms including Windows: Doppler or Infisical (cloud). The CLI delivery model is consistent across platforms, the audit log covers the team, and neither requires infrastructure work. Use doppler run -- or infisical run -- for every agent invocation, not the .env download. Infisical self-hosted if you want the cost ceiling.

50-person scale-up, already on AWS: AWS Secrets Manager with IAM role-based access. Write a thin wrapper that fetches secrets and injects them into agent processes. CloudTrail is your audit log. Add Doppler or Infisical as a developer-facing layer if engineers complain that the AWS CLI workflow is too slow.

Enterprise, Kubernetes, compliance requirements: HashiCorp Vault with Vault Agent sidecar injection. Dynamic database credentials for any agent that touches a production database. The operational investment is justified by the feature set.

GitOps team, secrets need to track branches: SOPS + age, with a wrapper script that decrypts and injects. Pair with a check in your CI pipeline that verifies no plaintext secrets appear in committed files.

Team that needs audit trails without cloud dependency: hasp for individuals, and either Infisical self-hosted or Vault for the team-wide layer.

The matrix leaves out the hard part

The comparison table tells you what each tool does. It does not tell you what it costs to be wrong.

Switching cost is asymmetric. Getting secrets into a new system is a half-day of work. Getting them out, across every agent profile, CI pipeline, and developer laptop with cached service tokens, often takes weeks. Doppler's API is clean going in. Migrating a 200-secret project off Doppler requires exporting, reformatting, and re-importing into whatever you choose next, then rotating every service token that pointed at Doppler's API.

On-call burden varies. Vault's audit log is excellent when the cluster is running. During a cluster outage, that same audit log is unavailable, which is exactly when you need to verify whether a compromised agent made an unauthorized request. The same applies to cloud-managed tools: a Doppler service disruption leaves agents unable to fetch secrets for the duration. "The audit log is in the cloud" and "the cloud is unreachable right now" can describe the same moment.

Delivery model beats storage model. GitGuardian's 2026 State of Secrets Sprawl found AI-assisted commits leak roughly twice as often as the baseline. The vector is almost always ambient environment exposure: the agent reads a DATABASE_URL from a shell variable set in .zshrc weeks ago and forgotten. No secret manager prevents that failure if you source a .env file into your shell before launching the agent. Process-scoped delivery prevents it structurally.

"No cloud" and "no account" are operational properties. Every cloud-backed tool is a dependency in your critical path. Debugging an agent incident at 2am while waiting to authenticate to Doppler is a different experience from running hasp audit --verify locally and reading JSONL. Both are reasonable choices. Most comparison write-ups skip the operational experience under pressure, which is when the trade-off lands.

A checklist before you adopt any of these

## Secret manager evaluation checklist

Storage model
- [ ] Does the tool store secrets at rest, or proxy access to a store I already run?
- [ ] Where does the ciphertext live if I terminate my account or the SaaS shuts down?
- [ ] What is the key derivation function and memory cost? (Argon2id preferred over PBKDF2)

Secret zero
- [ ] What credential does the agent need to fetch secrets? Where does that credential live?
- [ ] What happens if that credential is compromised?
- [ ] Can I bind access to an instance identity (IAM role, OIDC) rather than a static token?

Delivery model
- [ ] Can secrets be injected into a child process without polluting the parent shell?
- [ ] Does the tool have a documented "run a command with secrets" primitive?
- [ ] Is there a way to confirm which secrets were injected into a given process?

Audit trail
- [ ] Is the audit log append-only and tamper-evident?
- [ ] Can I query "what did the agent access between 3pm and 5pm Tuesday"?
- [ ] Is the audit log available when the primary service is down?

Operations
- [ ] What does key rotation look like? Who has to touch what?
- [ ] What is the migration path off this tool in 18 months?
- [ ] Is there a self-host option? What does it require to operate?

Agent-specific
- [ ] Has the vendor published a threat model for agent workloads?
- [ ] Does the tool have first-class profiles for the specific agents my team runs?
- [ ] Does output from the agent session get scanned for inadvertent secret exposure?

What this means for your stack

The minimum change is switching from ambient env injection to process-scoped delivery. op run -- <cmd>, doppler run -- <cmd>, infisical run -- <cmd> all do this. Stop sourcing .env into your shell before launching an agent.

Past that, the question is whether you want a delivery model specifically designed for agent workloads: one where the agent receives a reference instead of a value, where streaming output is scanned before it reaches your terminal, and where the audit log records every grant in a form you can verify offline.

hasp is one working implementation of that model. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, hasp project bind, and the next agent session runs with process-tree-scoped secrets, 11-encoding output redaction, and an HMAC-chained local audit log. Source-available (FCL-1.0), macOS and Linux, no account, no telemetry by default.

The durable takeaway is simpler than any specific tool: the difference between "we have a secret manager" and "our agents cannot exfiltrate credentials" is the delivery model. Storage is solved. Delivery to agents is still where most teams have open risk.