Evaluating the Best Vault Systems for AI Agent Workplaces

Why a coding agent changes what a vault needs to do

A human developer usually gets a secret through a .env file or a CLI command run once at the start of a session. An AI coding agent breaks that model because it reads files to understand a codebase, not because anyone told it to. If a .env file sits in the project, the agent will eventually open it the same way it opens any other file, and once a value has been read into its context, it can be sent on to a model provider or show up in a saved transcript.

The fix teams converge on is to stop putting the secret in a file at all. A vault that supports process injection hands the credential straight into the environment of the one command that needs it, at the moment it starts, so the agent never has a file containing the value to open in the first place.

This is also why a personal password manager, built for a human typing a password into a browser, is the wrong tool here. What an agent workplace needs is something built for machine identities: short-lived credentials that a script or a CI job can authenticate as, not a vault built around a human opening it once a day.

• An agent reads files as part of normal operation, so a secret left in a file will eventually be read.
• Process injection puts the credential in the command's environment, not in a file the agent can open.
• Machine-identity secrets managers, not consumer password managers, are the right category here.

The three tools people actually reach for

There is no single product called a cowork agent ai vault. Searchers expecting one usually end up at one of three general-purpose secrets managers, each run the same way: wrap the agent's start command so the secrets are injected only into that process.

Doppler is the fully managed option: doppler run --config dev --project myapp -- npm start fetches your project's secrets and injects them as environment variables for that one process. It is the fastest to set up, but it is SaaS, so it needs a live connection to Doppler's API. A --fallback file lets a previously synced secret still be read if the connection drops, but that only covers secrets you already pulled once while online, not a true offline start.

Infisical is the open-source alternative, with the same shape of command: infisical run --env=dev --path=/apps/api -- npm run dev. Because it has a self-hosted edition, teams building a private agent workplace can run the whole secrets service on their own infrastructure instead of depending on a vendor's cloud.

HashiCorp Vault is the oldest and most capable of the three, built for dynamic secrets: instead of a static database password, it can hand out a credential that expires on its own after an hour, so a leaked value stops being useful on a timer rather than needing someone to notice and rotate it. The tradeoff is a steeper setup, with policies, auth methods and secret engines to configure before the first secret comes out of it.

• Doppler: doppler run -- [command], SaaS, needs connectivity (a --fallback file covers brief drops, not a cold offline start).
• Infisical: infisical run -- [command], open source with a self-hosted edition.
• HashiCorp Vault: the most capable, with dynamic, self-expiring secrets, at the cost of a harder setup.

Running one of these fully offline

A fully air-gapped agent workplace, common in regulated industries or anywhere proprietary code cannot touch the public internet, rules out Doppler outright, since it depends on reaching Doppler's servers. That leaves HashiCorp Vault or a self-hosted Infisical instance, both of which can run entirely inside your own network with no outbound dependency.

There is a licensing wrinkle worth knowing before you commit to HashiCorp Vault for this. In August 2023, HashiCorp moved Vault from the Mozilla Public License to the Business Source License, which still permits you to run and modify it internally but restricts offering it as a competing hosted product. That change is also why OpenBao exists: a group of engineers, several from IBM, forked Vault's last MPL-licensed release (1.14.0) and placed the project under the Linux Foundation, where it is still licensed MPL 2.0 today. If license terms matter to your organization more than Vault's larger ecosystem, OpenBao is a drop-in-shaped alternative built for exactly that concern.

Whichever you pick, the rule for an offline setup is the same: the vault, the agent's execution environment and the model you are running all need to sit inside the same secured network. A secret that never has to leave that perimeter cannot be the thing that lets data leave it.

• Doppler cannot run air-gapped. HashiCorp Vault and self-hosted Infisical can.
• HashiCorp Vault moved to the Business Source License in August 2023.
• OpenBao is the Linux Foundation fork of Vault's last MPL-licensed release, still under MPL 2.0.
• Keep the vault, the agent and the model inside the same network perimeter for a true air-gapped setup.

Configuration choices that matter more than which product you pick

The product matters less than three decisions you make inside it. First, grant the agent's identity only the secrets its current task needs, not every credential your team has ever stored. A scoped identity limits what a compromised or confused agent session can reach.

Second, prefer a dynamic or short-lived secret over a static one wherever the vault supports it. A database password that expires in an hour means a value that leaks during a bad session stops being useful before anyone has to notice and rotate it by hand.

Third, never give the agent direct access to the vault's own API. The wrapper script or your CI job should be the thing that talks to the vault and hands the resulting value to the child process. An agent that can call the vault directly can also enumerate what else is stored there, which defeats the point of scoping its access in the first place.

• Scope each agent identity to only the secrets its current task needs.
• Use dynamic, short-lived secrets wherever the vault supports them.
• Keep the agent one step removed from the vault's API; let a wrapper script fetch and hand off the value.

Where a desktop vault like Forkbench's fits next to these

Everything above is a service: something with its own policies, leases and often its own server, built for a team with a backend to protect. Forkbench's Vault solves a narrower problem. It stores your API keys in your Mac's own Keychain and lets a coding agent you are running locally reference one by name, so the key's value never has to sit in a .env file or get typed into a prompt.

That is not a replacement for HashiCorp Vault or Infisical, and it is not trying to be. Forkbench has no concept of a dynamic, self-expiring secret, no policy engine, and nothing resembling a lease a secret can outlive. What it removes is the much more common failure on a single developer's machine: a plaintext .env file that an agent reading the project happens to open.

The caveat is the same shape as the one above for a vault's own API: Forkbench keeps the value out of the agent's context, but once a command is running with that key, whatever that command does with it is between the command and the key, pinned or not. If you are protecting a production database credential a CI pipeline uses, you still want Vault or Infisical sitting in front of that pipeline. If you are protecting a developer's personal API key from their own coding agent, a desktop-scoped vault is closer to the actual job.

• Forkbench's Vault is Keychain-backed and scoped to one Mac, not a networked service.
• It has no dynamic secrets, no policy engine and no leases, unlike Vault or Infisical.
• It stops a key from sitting in a plaintext file; it does not stop a program the agent ran from using the key it was handed.

A short checklist before you pick one

Start with where the agent runs. Fully air-gapped rules out Doppler. A single developer's own Mac rules out needing a networked service at all for most of their personal keys.

Then check what the credential protects. A production system a pipeline touches on a schedule wants dynamic, short-lived secrets from Vault or Infisical. A personal key used only inside one developer's own agent session is adequately served by keeping it out of the project folder in the first place.

Finally, write down who is allowed to read the vault's own configuration, separately from who is allowed to use the secrets it issues. Those are different permissions, and conflating them is the most common way a least-privilege setup quietly stops being least-privilege.

• Air-gapped environment: HashiCorp Vault or self-hosted Infisical, not Doppler.
• Production credential used on a schedule: a service with dynamic secrets, not a desktop vault.
• Personal developer key: keeping it out of the project folder matters more than which vendor you pick.