2026 secrets stack, a decision matrixTen tools. Five dimensions. One honest recommendation.

In May 2026 you can pick from a dozen credible tools for managing secrets. Knowing which one fits your threat model is the hard part, and that threat model has changed fast.

Until around 2023, most secrets stacks were designed around one consumer: a human developer typing at a terminal, or a CI runner with a cloud IAM role. The attacker model was "credential committed to git" or "long-lived key stolen from a breach." The mitigations were consistent: encrypt at rest, restrict access, rotate regularly, scan repos.

AI coding agents broke three of those assumptions simultaneously. The agent runs as a long-lived process in the developer's environment, with the same environment variable access as the developer. It spawns subprocesses and writes files. It generates commits. Knostic disclosed in February 2026 that Claude Code's settings.local.json was recording the full environment variable set from agent sessions and shipping it in npm packages, found in roughly 1-in-13 scanned packages. GitGuardian's State of Secrets Sprawl 2026 puts AI-service token leaks at 81% year-over-year growth, with AI-assisted commits leaking roughly twice as often as the baseline. OX Security documented approximately 7,000 MCP servers in the wild in early 2026, none with a signature requirement. Check Point published CVE-2025-59536, a command-injection bug in Claude Code project files, in early February. The category is: the developer environment is now a shared runtime, and the old tools were not designed for that.

This article covers every credible option, organized by what they do, not what their marketing says.

What to know in 60 seconds

• There are five meaningful categories: OS keychain / local storage, file-based encryption (SOPS, age, dotenvx), local vaults (GNU pass, GnuPG-backed), centralized vaults (HashiCorp Vault, Infisical, Doppler), cloud-native managers (AWS, GCP, Azure), and brokers (hasp, CyberArk Secretless).
• Federation (OIDC, SPIFFE/SPIRE) eliminates the long-lived key at the workload layer, shrinking what secrets management needs to cover. It does not replace secrets management for the cases that remain.
• The difference between 2023 and 2026 is not new tools. It is a new consumer that has write access to your repo, runs unsupervised, and generates state files you forget to check.
• GitGuardian's 2026 data shows the leak vector has shifted from "committed .env file" to "agent state file, log output, and ambient environment inheritance."
• The decision matrix below covers 10+ tools across five dimensions: storage, identity, delivery, audit, and blast radius. Use the decision tree section to get to your starting point in under five minutes.

Five dimensions that determine your exposure

Most comparison posts run down feature lists. The five questions below determine your incident exposure. Feature lists do not.

Storage. Where does the cleartext value exist at rest? In a hardware-backed keychain, in an encrypted vault on disk, in a SaaS database, or in an HSM? The answer determines what an attacker needs to extract a credential without running code.

Identity. How does the consumer authenticate to the storage layer? A long-lived token, a machine identity, a cloud IAM binding, a passphrase, or an ephemeral attestation? The answer determines what the secret-zero is and where it lives.

Delivery. How does the cleartext value get from storage to the consumer's address space? Environment variable in the parent shell (persistent until the shell dies), injected into a child process (gone when the process exits), written to a temp file (survives until cleanup), or pulled via API (network call on every use)? The delivery mode determines how long an AI agent can access a credential after it was originally intended.

Audit. Can you answer "did the agent read this credential between 2pm and 4pm Tuesday?" in under 10 seconds, with a tamper-evident log? Vault has this. Most other tools do not.

Blast radius. If an agent goes rogue, or if a credential is exfiltrated, what is the maximum damage? One project, one session, one organization, one cloud account?

Most comparison failures happen because teams pick by delivery (what UX is easiest?) without thinking about storage, identity, or blast radius.

The full decision matrix

Tool	Storage	Identity	Delivery	Audit	Blast radius	Offline	Agent-safe
macOS Keychain	Hardware-backed SE on M-series	User + biometric	Env var or API call	None	Per-machine	Yes	No
GNU pass / libsecret	GPG-encrypted files	GPG key	Plaintext to stdout	None	Per-machine	Yes	No
Mozilla SOPS	Encrypted file in repo	KMS / GPG / age key	Decrypt to plaintext file or stdout	None	Yes (key must be local)	Partial
age + dotenvx	Encrypted env file	age keypair	Decrypt to plaintext or exec-env	None	Yes	Partial
GNU pass (with git)	GPG files + git history	GPG key	Plaintext to stdout	git log (partial)	Per-machine	Yes	No
HashiCorp Vault	Encrypted backend (Consul, S3, etc.)	AppRole, platform auth, OIDC	Dynamic lease, env var, API	Full structured log (every read/write)	Policy-bounded lease	Yes (HA cluster)	Partial (with custom wrapper)
Infisical	Cloud or self-hosted DB	Machine identity, OIDC	Env pull at startup	Cloud activity log	Project-scoped	Partial (self-host)	No
Doppler	Cloud DB	Service token	Env pull at startup	Dashboard + webhook	Project-scoped	No	No
AWS Secrets Manager	KMS-backed cloud	IAM role / access key	API call, SDK	CloudTrail	IAM-bounded	No	No
GCP Secret Manager	Cloud, CMEK optional	Workload identity / SA key	API call, SDK	Cloud Audit Logs	Project-bounded	No	No
Azure Key Vault	Cloud, HSM optional	Managed Identity / SP	API call, SDK	Azure Monitor	Resource group	No	No
CyberArk Secretless	Config file	Connector credential	Process env injection	Connector log	Connector scope	Partial	Partial
hasp	Argon2id AEAD local vault	Local passphrase	Process-tree env, temp file, temp dotenv	HMAC-chained local log	Process-tree only	Yes	Yes
OIDC / SPIFFE-SPIRE	No storage (identity only)	Workload attestation	Short-lived JWT/SVID	Issuer log	Per-workload	Partial	Partial

"Agent-safe" means: values are not available in the agent's ambient environment before the subprocess that needs them starts, and do not persist in state files after the process exits.

A few cells in that table need unpacking.

What "partial" means in the agent-safe column

SOPS and age are "partial" because they have exec-env modes (sops exec-env secrets.yaml program or dotenvx run -- program) that inject values into a specific subprocess rather than writing a file. If you use those modes, they do what a broker does. If you use sops -d secrets.yaml > .env, you have a plaintext file in your repo directory that every agent subprocess can read. Most SOPS documentation leads with the file-output path.

HashiCorp Vault is "partial" because you can wrap a Vault read inside an exec that injects the credential into a specific process. But nothing in the default Vault UX does this for you. You write the wrapper. Most teams do not.

CyberArk Secretless Broker is built for this exact delivery pattern in containerized environments. Its native context is Kubernetes pods. It can run on a developer machine but the setup overhead is high and documentation for that path is thin.

Cloud-native managers and the laptop problem

AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault solve the cloud-workload problem cleanly. EC2 instance roles, GCP workload identity, and Azure Managed Identity give cloud processes ambient IAM-based authentication. No long-lived credential on disk.

On a developer's laptop, that identity model breaks. You fall back to a long-lived access key, a service account JSON, or a federated login that expires and prompts for re-authentication. GitGuardian's 2026 research shows this is where the leaks happen: on developer machines, not in production infrastructure. Knostic found settings.local.json containing credentials not in cloud runners (which are ephemeral) but in developer workstations that npm-published packages.

If your developers need cloud secrets locally, the federated path (AWS SSO + aws sso login, GCP Application Default Credentials via gcloud auth application-default login) is the right one. Still requires session management and does not scope delivery to a specific subprocess.

HashiCorp Vault: still the reference, now under IBM

Vault remains the reference implementation for enterprise secrets management. Lease-bounded dynamic secrets, fine-grained path policies, full audit log (every read and write, with caller identity, timestamp, and path), AppRole and Kubernetes auth, HA clustering. If your threat model is "regulated environment with dedicated platform engineering capacity," Vault is the answer.

The IBM acquisition of HashiCorp in 2024 has not materially changed the product. OpenBao (the Linux Foundation fork, created after the BSL license change in 2023) is operationally equivalent if the license is a concern.

The cost is real. A production Vault cluster with proper HA, TLS, auto-unseal, audit log shipping, and rotation policies is weeks of work to stand up and a steady maintenance load. The Vault learning curve is steep. Teams with fewer than five engineers who do not have a dedicated infra person often find the ops burden prohibitive.

Doppler and Infisical: good defaults, wrong consumer model

Both are well-designed for the problem they solve: eliminate .env files scattered across developer machines and CI configs. The developer experience is better than most alternatives. Infisical's self-hosted option removes the cloud dependency for secret retrieval (you run the Infisical server, not their SaaS). Dynamic secrets in Infisical (added late 2025) generate short-lived database credentials, which narrows blast radius compared to static long-lived keys.

Neither one is designed for AI-agent runtime. Their delivery model is: at session start, pull all credentials into the process environment. The agent then inherits that environment and holds every credential for the entire session. Doppler's service tokens are project-scoped, not session-scoped. There is no mechanism to say "this Claude Code session gets read access to DATABASE_URL for four hours, then loses it."

Decision tree: pick your starting point

Work through this in order. Stop when you find your profile.

Are you a solo developer on one machine, with no team and no AI agents? Start with macOS Keychain (macOS) or libsecret + GNU pass (Linux). Store your API keys there. Add a careful .gitignore and .npmignore. That is a defensible position. Skip the rest of this tree.

Are you a solo developer who runs AI coding agents (Claude Code, Cursor, Codex, Aider)? The keychain alone is not enough. Your agent inherits every secret in your shell. Move to a broker that injects credentials into specific agent sessions. See "After the decision tree" below.

Are you a team of 2-10 engineers without compliance mandates? Start with Doppler or Infisical. They solve the "stop committing .env files" problem with minimal ops overhead. Add a scanning step (GitGuardian, truffleHog, or hasp check-repo) to catch what slips through. When you add AI agents, layer a broker at the execution boundary. Do not try to replace the cloud manager.

Are you a team of 10-50 engineers with some compliance requirements (SOC 2, ISO 27001)? Doppler or Infisical for most teams, with the caveat that the audit trail requires paid tiers and cross-correlating manager logs with agent session logs is manual. HashiCorp Vault (or OpenBao) if you have the infra capacity and need fine-grained path policies and a structured audit log that SOC 2 auditors will accept without argument.

Are you a large organization (50+ engineers) with regulated data (SOC 2 Type II, PCI-DSS, FedRAMP, HIPAA)? HashiCorp Vault or an enterprise offering (CyberArk, Delinea, BeyondTrust) is required. Dynamic secrets for database credentials, HSM-backed key storage for the highest-sensitivity keys, structured audit log shipped to your SIEM, dedicated Vault team. AI agents at this tier need a custom wrapper that mints short-lived Vault tokens at session start and restricts them to development-environment paths. No agent should ever have a token that reads production.

Are you running workloads in a single cloud (AWS, GCP, or Azure) with no on-prem or developer-machine component? Use the native secrets manager for that cloud. AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault. The IAM-based identity model works cleanly for cloud workloads. For developer laptops, layer a local tool over the cloud manager's SDK.

Are you running multi-cloud or hybrid (cloud + on-prem + developer machines)? This is where the matrix gets complicated. HashiCorp Vault (or HCP Vault) is the most common multi-cloud answer. SPIFFE/SPIRE is the right long-term answer for workload identity federation across boundaries. Both take time to stand up.

After the decision tree: if AI agents run in your environment Regardless of which vault or manager you use, the AI-agent delivery problem requires an execution-layer answer. The broker sits between your vault and the agent process, injects credentials into specific subprocesses at exec time, and records grants in an audit log you can check independently. This is true whether your vault is Vault, Doppler, or the macOS Keychain.

Where the wave is moving

Three shifts are underway that will make the 2026 matrix look dated by 2027.

Ephemeral workload identity. SPIFFE/SPIRE gives workloads short-lived X.509 SVIDs tied to their runtime context (container ID, pod identity, service account). The credential proves "I am the billing service running on this cluster," not "I hold this static API key." AWS IAM Roles Anywhere and GCP Workload Identity Federation extend this model outside the cloud boundary. The logical end state is that application workloads stop holding long-lived static credentials entirely. They hold identities and exchange them for short-lived credentials at call time.

MCP server signing. OX Security's early 2026 report documented 7,000 MCP servers in production with no signature requirement. A prompt-injection attack documented by Snyk researchers in early 2026 used an MCP server to exfiltrate repository data. The MCP spec is moving toward signed server metadata and issuer verification. Once that lands, "is this MCP server authorized?" becomes a checkable property. That creates a natural place for an allow-list of verified MCP servers per project, which is a secrets-management primitive for tool access.

Signed agent sessions. Several teams are experimenting with signing the agent's session start with a workload SVID or a short-lived Vault token. The signature produces a cryptographic record of what identity the agent held when it started. Paired with a per-session grant log, that record makes post-incident forensics tractable: "the agent held this identity, which had access to these paths, during this window." Knostic's disclosures in early 2026 drove interest in this pattern. No shipping product handles it end-to-end yet, but the pieces are available in Vault + SPIRE.

Workloads are moving from holding static keys to holding identities they exchange for short-lived credentials at call time. The 2026 matrix lands in the middle of that shift.

Migration paths

Moving from one tier to another without breaking everything requires sequencing.

From .env files to a cloud manager (Doppler or Infisical):

1. Inventory all .env files in the codebase. A find . -name '.env*' -not -path '*node_modules*' in each repo is a start.
2. Import the values into Doppler or Infisical. Do not delete the .env files yet.
3. Update CI to pull from the manager instead of from secrets injected via the platform's native env vars. Verify CI passes.
4. Update developer onboarding to authenticate to the manager on first setup. Run both paths for one sprint.
5. Delete the .env files and add them to .gitignore. Run git log --all --oneline -- '.env' to confirm they are not in history.
6. Rotate every credential that was in the .env files, because you do not know who copied them before the migration.

Step 6 is where most migrations stall. Teams skip the rotation and accept the residual risk. Do not. The value of the migration is zero if the old credentials remain live.

From a cloud manager to HashiCorp Vault: This migration is an ops migration, not a credential migration. The credentials move from the SaaS database to Vault's storage backend.

1. Stand up the Vault cluster. Test HA failover before you store anything important.
2. Define auth methods that match your workloads: AWS IAM for cloud runners, AppRole or OIDC for CI, developer machine tokens via vault login with your chosen auth backend.
3. Write path policies that mirror your existing access model. Start restrictive.
4. Migrate credentials in batches by team/environment, not all at once. Verify each batch before moving the next.
5. Decommission the cloud manager service tokens only after each consumer is verified against Vault.

The most common failure mode is the audit log. Vault's audit device must be configured from day one. Teams that add it later find gaps in their log that auditors will ask about.

From a cloud manager to a broker-first architecture: This does not require replacing the cloud manager. The broker sits at the execution layer and pulls from the manager at exec time, injecting into the specific subprocess. The migration is:

1. Install and configure the broker on developer machines. Map each agent profile to its allowed credential set.
2. Update developer runbooks: instead of source .env && claude code, run broker exec -- claude code (or the equivalent for your broker).
3. Confirm that agent state files no longer contain credential values. hasp check-repo does this for hasp; write the equivalent grep for your broker.
4. Add the broker exec pattern to CI where agents run in CI. The runner environment still uses the cloud manager; the broker scopes delivery from there.

The migration that fails most often is the cultural step: getting developers to change how they launch agent sessions. The tooling change is small. The habit change takes effort.

What the matrix will not decide for you

The matrix tells you which tool fits which threat model. Four things it cannot resolve:

On-call ergonomics. When your production database credential rotates during an incident at 2am, which system the on-call engineer needs to reach is not a security decision, it is an operational one. Vault's complexity is a real cost at 2am. Doppler's dashboard is faster for a panicked engineer. The tool with the better technical properties is not always the tool that helps in a crisis. Weight this deliberately.

Vendor relationships. HashiCorp is now IBM. Doppler has raised $20M. Infisical is venture-backed and open-source. HCP Vault pricing has changed twice since the acquisition. Most organizations do not switch secrets managers once they have migrated credentials and updated every service that consumes them. The switching cost is high. The vendor you pick in 2026 is likely the one you will have in 2029. A hard conversation about vendor trajectory now is cheaper than a forced migration later.

The CISO's preferred tool. Most security teams above a certain size have a tooling standard that predates this analysis. Moving away from CyberArk or Thycotic or a centrally-managed Vault cluster requires a security review and change management process that the matrix cannot shortcut. If your CISO has a preference, the right move is usually to layer your desired approach on top of it (broker at the execution layer, built on top of the mandated vault) rather than to replace it. Picking a fight over the policy layer rarely ends well.

Compliance paperwork. SOC 2, PCI-DSS, FedRAMP, and ISO 27001 auditors do not care which tool you use. They care that you can produce evidence: who had access to what, when, for how long, and whether that access was reviewed. Vault's structured audit log is the easiest format to produce for most auditors. Doppler's dashboard requires exporting. A home-built HMAC-chained local log requires explaining the format. The matrix does not tell you what your next audit will accept. Talk to your compliance contact before picking.

The "we'll figure it out later" trap. Engineering leaders routinely treat secrets management as a problem to solve at scale. The Knostic disclosures in early 2026, the CVE-2025-59536 publication, and the OX Security MCP report all documented real exposures on teams that had planned to revisit their secrets stack after they scaled. The cost of a credential-harvest incident does not scale with team size. A three-person startup with a leaked production database key has the same recovery work as an enterprise.

Decision worksheet

Paste this into your next architecture review.

## Secrets stack decision worksheet

Context
- [ ] Team size: __
- [ ] AI coding agents in use (list): __
- [ ] Compliance requirements: __
- [ ] Primary cloud (if any): __
- [ ] On-prem or air-gapped components: yes / no

Storage layer
- [ ] Current long-lived credentials stored in: __
- [ ] Encrypted at rest: yes / no
- [ ] Hardware-backed (Secure Enclave, HSM): yes / no
- [ ] Accessible without a network call: yes / no

Identity layer
- [ ] Agent authenticates to vault with: __
- [ ] That auth credential lives in: __
- [ ] Its lifetime: __
- [ ] How it gets rotated: __

Delivery layer
- [ ] Secrets arrive in agent process via: env var / file / API call
- [ ] Ambient in parent shell before subprocess launches: yes / no
- [ ] Persist in state files after subprocess exits: yes / no
- [ ] Scoped to process tree: yes / no

Audit
- [ ] Can answer "did agent X read secret Y at time Z": yes / no
- [ ] Log is tamper-evident: yes / no
- [ ] Log retention: __ days
- [ ] Auditors will accept the log format: yes / no / unknown

Blast radius
- [ ] Maximum scope of a single compromised credential: __
- [ ] Time to detect a credential in unauthorized use: __
- [ ] Time to revoke and rotate: __

AI-agent-specific
- [ ] Agent state files (.claude/, .cursor/, .aider/, .codex/) in .gitignore: yes / no
- [ ] Agent sessions do not inherit ambient shell credentials: yes / no
- [ ] Last checked for leaked credentials in repo: __
- [ ] Log output checked for accidental credential printing: yes / no

Gaps identified
- Storage: __
- Identity: __
- Delivery: __
- Audit: __
- Blast radius: __

What this means for your stack

The default stack in May 2026 is still ambient environment variables pulled into the developer's shell at session start. Every process inherits them, including the AI coding agent that runs for eight hours, writes state files, and generates commits. GitGuardian's 81% year-over-year increase in AI-service token leaks is the running cost of that default.

The alternative is a three-layer answer: a policy-layer vault for storage and rotation, an execution-layer broker for delivery and scoping, and a tamper-evident audit log that covers both. The vault can be Doppler, Infisical, Vault, or a cloud-native manager. The broker sits at the exec boundary and handles the agent-specific problem of keeping credentials out of ambient environment state and out of state files.

hasp is one working implementation of the execution layer. curl -fsSL https://gethasp.com/install.sh | sh, then hasp setup, hasp project bind, and hasp run to wrap an agent session. The local vault uses Argon2id (64MB, 3 iterations, 4 lanes), AEAD at rest. The audit log at ~/.hasp/audit.jsonl is HMAC-chained and verifiable with hasp audit --verify. Six agent profiles ship by default. No cloud, no account, no telemetry by default. FCL-1.0 license, converts to Apache 2.0 in 2027. macOS and Linux.

The tool you pick is secondary. The model shift from "ambient at session start" to "injected at exec time, gone when the process exits" is what changes the exposure profile. That shift is available today with multiple tools across this matrix. The decision worksheet above will tell you which one fits your context. Use it before the next agent session, not after the next incident.