Secret managers in 2026Eight tools. One honest matrix.

GitGuardian's State of Secrets Sprawl 2026 puts AI-service token leaks at 81% year-over-year growth. The primary culprit is not a new attack vector. It is the same surface that existed in 2018, now hit by something that generates credentials-bearing commits at far higher velocity: AI coding agents running in developer environments.

Picking a secrets tool used to be simpler. You compared UI, vault backend, and whether your CI platform had a native integration. Now there is a second axis that most comparison posts ignore: what happens when a coding agent, rather than a human, is the runtime consumer? The agent inherits your shell environment, has write access to your repo, and may persist state files anywhere in the project tree. Knostic found this in practice when they disclosed that Claude Code's settings.local.json was capturing environment variables and shipping them in npm packages, roughly 1-in-13 scanned in February 2026. Cursor had the same shape of problem three weeks earlier.

This matrix covers eight tools. The frame is AI-agent runtime, not human operator convenience. Tools that score well on the former may score poorly on the latter. I will note which is which.

What to know in two minutes

• Cloud-managed managers (Doppler, Infisical) are convenient but require network access on every secret pull and hand a third party your secret-zero.
• Self-hosted HashiCorp Vault solves the cloud-dependency problem but adds significant ops overhead most small teams underestimate.
• SOPS is powerful but decrypts to plaintext files on disk. Those files get committed.
• 1Password CLI is excellent for individual developers and poor for CI performance at scale (no server-side caching, per-op latency adds up).
• Agent Vault takes the forward-proxy approach, which solves injection but introduces a MITM in your agent's HTTP stack.
• secretless-ai is purpose-built for agents but has thin audit and is source-available but not OSI-approved yet.
• hasp is local-first, process-tree-scoped, works offline, and ships an HMAC-chained audit log. Its scope is narrower than Vault.
• Secret-zero handling and blast radius when an agent goes wrong are the two questions that separate these tools in 2026. Most marketing materials do not address either.

The frame that matters for AI agents

Conventional secret manager evaluation asks: can I pull secrets into my app at startup? That question fits a web server that boots once and reads config. It does not fit a coding agent that runs for eight hours across many subprocesses, writes files into the repo tree, and sends tokens into tool calls you did not explicitly authorize.

The questions that actually matter for an AI coding agent runtime:

Secret-zero handling. How does the agent get its first credential? If the bootstrap token lives in an environment variable or a .env file in the project directory, an agent that persists state (all of them do) has a direct path to it.

Blast radius. If an agent receives a secret and then behaves unexpectedly, what is the maximum scope of damage? Can it exfiltrate the production database key while fixing a typo?

Per-agent scoping. Can you issue a grant for one agent profile, for one session window, for one set of paths, without affecting other grants?

Audit trail. Can you answer "did the agent touch the prod token between 2pm and 4pm Tuesday?" in under ten seconds, without pulling logs from three services?

Runtime injection. Does the secret appear as an environment variable inside a specific child process, or does it sit in a file the agent can read at will for the duration of the session?

Offline operation. Does secret retrieval fail when the team's VPN is down or the SaaS is degraded?

The matrix below scores each tool on these six dimensions.

The 2026 matrix

Tool	Secret-zero	Blast radius	Per-agent scope	Audit	Injection mode	Offline
Doppler	SaaS API token	Broad (project-level)	Service tokens, not agent-specific	Dashboard, webhook	Env pull at startup	No
Infisical	SaaS API token	Broad (project-level)	Machine identities, not agent-specific	Activity log, cloud	Env pull at startup	Partial (cache)
HashiCorp Vault	AppRole or platform auth	Lease-bounded	Path policies, fine-grained	Full audit log (syslog)	Dynamic secrets, env, API	Yes (HA setup)
Mozilla SOPS	KMS key or GPG	Unlimited (decrypted file)	Per-file keys only	None on disk	Decrypt to plaintext	Yes
1Password CLI	Account key + device trust	Account-level	Vaults per project	Event logs (Teams+)	op run env injection	No (server required)
Agent Vault	Configured API token	Proxy scope	Forward-proxy rules	Proxy logs	HTTP intercept	No
secretless-ai	Config-file credential	Connector scope	Per-connector	Limited	Process env	Yes
hasp	Local vault + passphrase	Process-tree only	Per-profile, per-session	HMAC-chained local	Env var, temp file, dotenv	Yes

Each row hides nuance. The sections below go deeper on the tools where that nuance changes the decision.

Doppler

Doppler solves the "stop committing .env files" problem and does it well. The developer experience is genuinely smooth. CLI pulls are fast, the dashboard is legible, and the Vercel/Render/Railway integrations mean you can stop writing deployment secrets docs entirely.

The tradeoff for AI-agent contexts: every secret pull goes through Doppler's API. The secret-zero is a DOPPLER_TOKEN that your agent inherits from your shell. If the agent persists state to a file (and most do), that token is now at risk. Doppler's service tokens are project-scoped, not agent-session-scoped. There is no built-in mechanism to say "this Claude Code session gets read access to DATABASE_URL for the next four hours only."

Audit is dashboard-based. For a team that wants to answer "what did the agent pull during yesterday's session?" the answer requires cross-referencing Doppler activity logs with your agent session log. It works. It takes manual effort.

Doppler is the right choice when your team already uses it, your agents run in CI (where ephemeral runners reduce the blast radius), and you accept the cloud dependency. It is a poor choice for air-gapped environments or for teams that need per-agent scoping at the session level.

Infisical

Infisical is the open-source competitor to Doppler. You can self-host it, which eliminates the cloud dependency for secret retrieval (though you now own the ops for the Infisical cluster). The feature set is close enough to Doppler that the decision between them usually comes down to self-host preference and price.

For AI-agent runtimes the picture is similar. Machine identities are the agent auth primitive. They are project-scoped, not session-scoped. Audit logs cover what was retrieved but not which child process received the value or when it exited. The self-hosted option does allow offline operation after the initial bootstrap, but "offline" here means the Infisical server you are running internally, not local-only.

Infisical added a "dynamic secrets" feature in late 2025 that generates short-lived credentials for databases. That is meaningfully better for blast radius than long-lived keys. At time of writing the feature set is narrower than Vault's dynamic secrets but the operational overhead is lower.

HashiCorp Vault (now under IBM)

Vault is the reference implementation for enterprise secrets management. Lease-bounded dynamic secrets, fine-grained path policies, a full audit log (every read, every write, to syslog or to a file), AppRole and Kubernetes auth, the ability to operate in HA mode without external dependencies. If your threat model requires this level of control, Vault is the answer.

The cost is real. A hardened Vault cluster with proper HA, TLS termination, unsealing strategy (auto-unseal requires a KMS, which reintroduces a cloud dependency), audit-log shipping, and rotation policies takes weeks to stand up correctly. The HashiCorp BSL license change in 2023 pushed some teams to OpenBao, the Linux Foundation fork. Both are operationally similar.

For AI-agent runtimes, Vault's token/role system can approximate per-agent scoping. You can issue a short-lived token for each agent session via AppRole, restrict it to specific secret paths, and let it expire. This requires a wrapper script or a custom MCP server call that mints the token at session start. Nobody ships this out of the box. You build it yourself.

Vault's audit log is the strongest in this list. It records the caller, the path, the operation, and the timestamp for every secret access. Post-incident forensics are genuinely tractable.

Recommended for: teams with dedicated platform engineering capacity, compliance mandates (SOC 2, FedRAMP, PCI-DSS), and the ability to maintain a Vault cluster as a first-class service. Not recommended for: teams of one to five people without dedicated infra, or for offline/local development environments.

Mozilla SOPS

SOPS (Secrets OPerationS) encrypts secret files in place, using KMS, age, or GPG. The encrypted file lives in your repo. Decryption happens at use time. The workflow looks elegant on paper: secrets travel with the code, no separate service, git handles the history.

The problem is what happens when you decrypt. SOPS outputs plaintext. The typical workflow is sops -d secrets.yaml > .env and then some process reads .env. That plaintext .env is now on disk, in the repo directory, possibly for the duration of your working session. An AI agent that inherits your shell or traverses the repo tree can read it.

This is not a theoretical risk. The Knostic disclosures showed that coding agents encounter files in the project directory and record their contents. A decrypted .env with production credentials is a high-value find.

SOPS is well-designed for what it does: encrypted secrets in version control, decrypted by a KMS-authenticated human at a specific moment. It is not designed for runtime injection into subprocesses. The decryption step is the gap.

If you use SOPS, the mitigations are: decrypt outside the repo directory, use sops exec-env (which injects directly into a subprocess environment without writing a file), and add decrypted files to .gitignore and .dockerignore aggressively. The sops exec-env secrets.yaml program arg1 pattern is meaningfully safer than sops -d secrets.yaml > .env.

1Password CLI

1Password CLI (op) is excellent for developers who already use 1Password personally. The op run command injects secrets as environment variables into a subprocess, pulling values from a 1Password vault at run time. The UX is well-polished and the learning curve for existing 1Password users is minimal.

The limitations for agent runtimes are two. First, op run requires a network connection to 1Password's servers on every invocation. In a session where an agent fires dozens of subprocesses, each one that needs a credential triggers a network round-trip. The latency is low on a fast connection but it adds up and it fails under degraded connectivity.

Second, the audit story requires 1Password Business or Teams. Individual and Family accounts have no secret access event log. For teams that need to answer forensic questions about what an agent pulled and when, the account tier matters.

1Password CLI is a solid choice for individual developers and for small teams that already standardize on 1Password. It is a poor choice for offline environments, for high-frequency subprocess spawning, or for teams that need per-agent scoping beyond vault-level access control.

Agent Vault

Agent Vault takes the forward-proxy approach. Instead of injecting secrets before the process starts, it intercepts outgoing HTTP requests from the agent, injects the credential, and forwards the call. From the agent's perspective, it calls an API endpoint with a placeholder. Agent Vault swaps the placeholder for the real token in transit.

This solves a specific problem: you do not need to know at session-start which secrets the agent will need. The agent discovers them at call time.

The architecture introduces a man-in-the-middle in your agent's HTTP stack, which creates two concerns. First, you need to trust that Agent Vault does not log the injected values in a recoverable form. Second, any tool the agent uses that does TLS pinning or mutual auth will break. For agents calling standard REST APIs this is usually fine. For agents calling internal services with stricter TLS requirements it is not.

Agent Vault's audit is proxy-log based: you see which endpoints got called with which placeholder tokens. You do not see which child process made the call or what it did with the response. The blast radius question is "could the agent make more HTTP calls than intended?" and the answer is yes, bounded only by the proxy rules you configure.

For teams where the primary risk is credential injection into API calls (rather than file-system or environment exposure), Agent Vault is worth evaluating. It does not address SOPS-style decryption-to-disk or environment variable inheritance.

secretless-ai

secretless-ai is a purpose-built credential broker for AI coding agents. It supports multiple connector types (database, S3, REST API), has a config file where you define which agent gets which connector, and injects credentials via process environment at exec time.

The appeal is that the abstraction is shaped for agents rather than for humans. You define "claude-code can connect to the staging database" rather than "here is the connection string." The agent requests the connector by name, secretless-ai resolves the credential, and the credential appears in the subprocess environment for that call only.

The weaknesses are audit depth (connection-level logging but no per-grant HMAC chain) and an early-stage connector library. Support for custom REST APIs beyond the built-ins requires writing a connector plugin, which is a Go compile cycle. The project is source-available but not OSI-approved at time of writing.

For teams whose agent workload is primarily database and object-storage access, secretless-ai is worth a trial. For teams with diverse secret types or compliance-grade audit requirements, it is not yet there.

hasp

hasp is local-first, process-tree-scoped, and offline by default. It stores an encrypted vault locally (Argon2id, AEAD at rest), maintains an HMAC-chained audit log at ~/.hasp/audit.jsonl, and injects secrets into subprocesses via environment variable, temp file (mode 0600), or temp dotenv outside the repo. Six agent profiles ship by default (claude-code, codex-cli, cursor, aider, hermes, openclaw) with a generic fallback.

The blast radius story is specific: a secret that hasp injects appears inside a bounded process tree and disappears when the process exits. The agent's context window does not see the value directly. State files the agent writes hold references, not resolved values. If an agent that received a STRIPE_SECRET_KEY via hasp run then writes a state file, the state file cannot contain the key because the key was never in the agent's environment before the subprocess launched.

The audit log answers "what was granted, to which profile, in which session window, and did the chain verify?" via hasp audit --verify. The 24-hour grant ceiling is a hard default. Grants do not persist indefinitely.

The limitations are also specific. hasp is macOS and Linux only. It has no server mode and no web UI. It does not generate dynamic database credentials. It does not integrate with cloud secret backends. If your team needs a shared secret store with RBAC, centralized rotation, and a compliance dashboard, hasp is not that.

hasp's license is FCL-1.0, which converts to Apache 2.0 in 2027. Source-available today, permissive OSS at the two-year mark.

What gets missed in most comparisons

Most secret manager comparison posts benchmark enterprise features against enterprise threats. The examples are SOC 2 compliance, cross-region replication, and HSM integration. These are real concerns for large organizations with dedicated security teams. They are not the first concerns for a team of three engineers whose biggest practical risk is an AI coding agent writing a credential to a file in the repo tree.

The actual threat profile for small teams in 2026, per GitGuardian's 2026 State of Secrets Sprawl, is: AI-assisted commits leak around twice as often as baseline. The vectors are ambient environment variable inheritance, state files persisted by agent tools, and .env files that outlive the moment they were created. None of those vectors requires a sophisticated attacker. They require only that the developer did not think about what the agent could see and write.

Against that threat model, Vault's dynamic leases are overkill and its ops burden is prohibitive. SOPS's encrypted-in-repo approach sounds good and decrypts to a plaintext file anyway. Doppler's API-pull approach solves the "stop committing secrets" problem but does not stop an agent that inherits the Doppler token from doing whatever it wants with it.

The missing question in most evaluations is not "does this tool have a secrets API?" but "after the agent runs, what persists?" A tool that injects at exec time and cleans up on exit answers that question better than a tool that keeps the secret available in the shell environment for the duration of the session.

The second thing that gets missed: offline and low-latency operation matter more for developer machines than for CI. CI runners are ephemeral and usually have reliable network. Developer machines are sometimes on trains, sometimes behind VPNs that time out, and sometimes in flow states where adding a 300ms network round-trip to every subprocess spawn is genuinely disruptive. Cloud-managed tools are optimized for CI. Local-first tools are optimized for the developer.

A checklist you can paste into a decision doc

## Secret manager selection checklist (2026, AI-agent runtime)

Secret-zero handling
- [ ] How does the agent get its first credential? (env var, file, keyring, none)
- [ ] If env var: is the var visible in process listings or state files?
- [ ] If file: is the file outside the repo tree and mode-protected?

Blast radius
- [ ] What is the maximum scope of a grant? (session, project, account, org)
- [ ] Can you issue a grant scoped to one agent profile for one time window?
- [ ] Does the secret persist past the subprocess that needed it?

Audit
- [ ] Can you list every grant in the last 24 hours in under 10 seconds?
- [ ] Is the audit log tamper-evident? (HMAC chain, append-only, offsite copy)
- [ ] Does the log record which agent profile / which process made the request?

Runtime injection
- [ ] Is the secret injected at exec time (preferred) or available ambient in env?
- [ ] Does the value appear in the agent's context window or only in its subprocess?
- [ ] Does the secret persist on disk after the subprocess exits?

License and dependencies
- [ ] Is the license OSI-approved or with a defined OSS conversion date?
- [ ] Does the tool require a cloud connection for secret retrieval?
- [ ] What is the failure mode when the cloud service is unavailable?

Ops burden
- [ ] Who owns the secret rotation cycle?
- [ ] Who maintains the server (if self-hosted)?
- [ ] What is the audit log retention policy and who pays for storage?

What this means for your stack

The default for most teams in 2026 is still ambient environment variables: secrets in ~/.zshrc, .env files in project roots, a cloud manager that pulls everything into the process at startup. That default was unsafe before AI coding agents. With agents that run for hours, write files, and generate commits, it is actively dangerous. GitGuardian's 81% YoY increase in AI-service token leaks is the current measurement of what that default costs.

The alternative is exec-time injection: a broker that holds values in an encrypted local vault, mints a grant for a specific agent profile at session start, injects the value into the child process environment when the subprocess runs, and writes nothing persistent when the process exits. Per-agent scoping and an append-only audit log are the two features that make that model tractable at small-team scale.

hasp is one working implementation of that model. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the next session gets a reference instead of a key. Source-available (FCL-1.0), local-first, macOS and Linux, no account required.

The tool choice is secondary. The decision to move from ambient environment variables to exec-time injection is the one that changes the risk profile. Any of the tools above that support process-level injection (SOPS exec-env, op run, secretless-ai connectors, hasp profiles) get you most of the way there. The matrix above tells you what each one costs in operational complexity, audit depth, and offline capability.