Open-Source Credential Vaults for AI Agents: the Radar Shortlist (2026)

A note on methodology. We The Flywheel is vendor-agnostic. No project on this list paid for placement or influenced its score, and several of the strongest entrants are too new to have a commercial relationship with anyone. This evaluation grew out of a community survey of open-source credential vaults for AI agents; we re-scored the field against our own framework and verified every licence, repository, and release date against primary sources. Our full scoring framework is documented and public.

The problem these tools exist to solve

Conventional secrets management hands the secret to the consumer. With an LLM agent, that is the vulnerability. A credential the agent can read is a credential a prompt-injection attack can exfiltrate, and the leak path is rarely exotic: the agent prints a value to a log or to stdout, that output returns to the context window, and an injected instruction reads it back out. A 2026 arXiv analysis of credential vulnerabilities in agent skills attributed roughly 73% of them to console and print output alone.

The architectural answer the category has converged on is blunt: the agent should never hold the credential at all. A broker outside the agent's trust boundary injects the secret into outbound requests, so a compromised or injected agent has nothing to leak, only scoped, brokered access it cannot enumerate. The same idea now sits inside Anthropic's Managed Agents and Cloudflare's outbound Workers for sandboxes, both of which run an out-of-sandbox proxy that holds secrets the agent never sees. Those are proprietary platforms. The open-source field is younger, and that is what this shortlist covers.

A proxy bounds the problem rather than eliminating it, and it is worth being precise about what it does and does not stop. It stops an injected agent from leaking the raw credential, because the agent never holds one. It does not stop that agent from being talked into misusing the access it has been granted, so scoping and rate-limiting at the proxy still matter. The proxy also becomes a trust anchor of its own: its security rests on how the agent authenticates to it, which is why workload identity belongs in the same conversation. None of that weakens the case for moving the secret out of the agent. It just means the proxy is the floor, not the ceiling.

How we scored these tools

The Flywheel Radar evaluates tools across 18 standardised metrics grouped into six dimensions: brand authority, social presence, developer community, review-platform performance, community sentiment, and news coverage. Developer community, which counts GitHub stars, contribution velocity, and release cadence, carries a 25% weight. For most categories that weight needs a caveat; here it does not. These are open-source infrastructure projects whose health genuinely lives on GitHub, so the signal is doing exactly the work it was designed to do.

One category-specific axis sits above the composite score: the trust-boundary test. Does the agent ever hold the real secret? A tool can be a mature, well-governed, widely starred secrets platform and still fail the test, because storing a credential well is a different problem from keeping it out of an agent's reach. We score the field on both, and we say which question each tool actually answers. Star counts and release dates below are snapshots as of late May 2026 and will drift; the licences will not.

The four worth running

Two of these are purpose-built credential proxies for agents. Two are the open-source vaults worth putting behind them. Together they are a complete, genuinely-open stack; individually, each answers one half of the question.

1. Infisical Agent Vault

Agent Vault is the purest expression of the proxy model on this list. It is a TLS-intercepting, credential-injecting forward proxy: the agent routes its outbound requests through it, the credential is attached at the proxy layer, and the agent never sees, stores, or logs the underlying secret. Infisical launched it on 22 April 2026 under an MIT licence; it is written in Go and targets Claude Code, custom harnesses, and other agent runtimes directly.

The design is the strongest available answer to the exfiltration problem, because a secret the agent cannot read is a secret an injected prompt cannot leak. The honest caveat is maturity: the repository labels it a research preview and warns it is not yet production-ready. Treat it as the canonical pattern to build toward and to evaluate, not as the thing you wire into a revenue-critical system this quarter. Roughly 1.5k GitHub stars and an active release cadence as of late May 2026.

2. OneCLI

OneCLI is the more deployable of the two agent-native tools today. It bundles a Rust gateway, a Next.js dashboard, and an AES-256-GCM encrypted store into a single Docker deployment. Agents receive placeholder keys; the gateway matches each outbound request by host and path, swaps the placeholder for the real credential, and injects it as a header or query parameter. It is Apache-2.0 licensed, carries roughly 2.3k stars, and was shipping releases as recently as the week of writing.

The packaging is its advantage: one command gives you a vault, a gateway, and per-agent scoped access tokens, which is a faster path to a working setup than assembling the parts yourself. The architectural trade-off relative to Agent Vault is that the agent still holds a working placeholder token. It is scoped and swappable rather than the real upstream secret, so the blast radius is bounded, but it is one more moving part to reason about than a model where the agent holds nothing at all. For teams that want a self-hosted agent credential gateway running this month, it is the most practical open option.

3. OpenBao

OpenBao is the secrets store to put behind your proxy if an OSI-approved licence is a requirement. It is the MPL-2.0 fork of HashiCorp Vault, created in direct response to the 2023 relicensing, now governed under the Linux Foundation with contributors including IBM engineers. It is API-compatible with Vault, which makes migration tractable, and it carries roughly 6.2k stars with active releases.

It does not solve the agent problem on its own. It is a vault, so the consumer still receives the secret, which is precisely why it belongs behind Agent Vault or OneCLI rather than in front of an agent directly. What it gives you is the full Vault feature set under a licence you can actually build on, with neutral governance rather than a single vendor's commercial roadmap. The limitation is operational: there is no Linux Foundation-managed SaaS, so you run it yourself.

4. Infisical

Infisical is the most established open-source secrets platform in this group, at roughly 27k stars with a very active release cadence. Its core is MIT-licensed, with enterprise features in a dedicated source-available directory: an open-core model rather than a fully permissive one. It handles secret syncing across teams and infrastructure, leak prevention, and the surrounding lifecycle work that a real organisation needs.

For agents specifically, Infisical is the backing store and the parent ecosystem behind Agent Vault, not the runtime broker itself. If you are already standardising secrets management for your engineering org and want your agent credentials to live in the same system, this is the platform that makes that coherent. Pair it as the store with Agent Vault as the runtime boundary, and read the licence directory split before you assume a given feature is free to self-host.

What didn't make the cut

Several of these are good software. They did not earn a recommendation for this specific use case, open-source credential handling for AI agents, for reasons worth stating plainly.

• HashiCorp Vault is the most mature secrets platform in existence and the widest backend and auth ecosystem you can buy. It fails the open-source filter for this list: it is BUSL-1.1, source-available rather than OSI open-source, and now owned by IBM. If the open licence is not a hard requirement for you, Vault is a defensible choice. But the genuinely-open continuation of its feature set is OpenBao, which is why OpenBao is on the shortlist and Vault is here.
• Bitwarden and Vaultwarden are excellent self-hosted password managers. Vaultwarden, the Rust reimplementation of the Bitwarden API, is one of the most-starred self-hosting projects on GitHub. Neither is an agent solution. They are credential stores with no runtime brokering layer: the consumer still receives the secret, so on their own they do nothing for the keep-it-out-of-the-agent problem.
• CyberArk Conjur has genuine enterprise PAM lineage and a machine-identity model, under an LGPL-3.0 server licence. But the open-source edition is the smallest community here at under a thousand stars, on a slower release cadence, and its own README now steers users toward CyberArk's commercial Secrets Manager. That is a soft deprecation signal, and not a foundation to build new agent infrastructure on.
• Keywhiz (Square) is archived. The repository was archived in late 2023 with a deprecation notice that recommends HashiCorp Vault instead, and its last release predates the agent era entirely. Include it only as history. Knox (Pinterest) is alive but quiet: maintained, but light on cadence and designed long before agents were a consideration.
• SOPS (now a CNCF project, no longer "Mozilla SOPS") is widely used and well maintained, but it answers a different question. It encrypts values inside config files at rest using KMS, age, or PGP keys. There is no daemon, no proxy, and no request-time injection, so an agent still decrypts and holds the plaintext. It is useful alongside a broker, for encrypting the broker's own config, but not as a substitute for one.

Choosing the right setup

The decision is less about picking a single tool than about deciding which half of the problem you are solving, and how much maturity you can trade for the correct architecture.

If you want the strongest security posture and can run a preview

Build toward Infisical Agent Vault backed by OpenBao. The proxy keeps the secret out of the agent entirely, and the backing store is genuinely open and Vault-compatible. Run it in a non-critical environment first, given Agent Vault's research-preview status, and treat the pairing as the reference design the rest of the category is chasing.

If you want a working self-hosted gateway this month

Start with OneCLI. The single-command Docker deployment gives you a vault, a gateway, and per-agent scoped tokens without assembling the pieces. Accept that the agent holds a scoped placeholder rather than nothing at all, and keep those tokens narrow.

If you are standardising secrets for the whole engineering org

Use Infisical as the platform and add Agent Vault as the agent boundary in front of it, so agent credentials live in the same system as everything else. Read the open-core licence split before you depend on an enterprise-directory feature.

If an OSI-approved licence is non-negotiable

Rule out HashiCorp Vault and pair an MPL-2.0 store, OpenBao, with an MIT-or-Apache proxy: Agent Vault or OneCLI. That combination is open source end to end, with no source-available carve-outs in the runtime path.

Bottom line

The open-source credential vault for AI agents is a category roughly two months old, and it has already produced the right answer: keep the secret outside the agent and broker access through a proxy the agent cannot read from. Infisical Agent Vault states that pattern most cleanly; OneCLI makes it deployable today; OpenBao and Infisical give you open backends to put behind either. The rest of the field is competent secrets storage that was built for a world before agents, and storage was never the part that was broken.

The honest constraint is time. The two tools that solve the actual problem are weeks old, and one of them says so on its own repository. Build toward the architecture now, prove it in a non-critical environment, and watch the release cadence. This is exactly the kind of fast-moving category the Technology Radar exists to track. For how we arrive at these recommendations, read the full methodology.

What is a credential proxy for AI agents, and how is it different from a secrets vault?

A secrets vault stores credentials and hands them to whatever asks, so your agent reads a key from the vault and then holds it. A credential proxy sits in the agent's outbound network path instead: the agent makes a normal HTTP request with a placeholder, and the proxy attaches the real credential server-side before forwarding it upstream. The distinction matters because the agent never possesses the secret in the proxy model. Infisical Agent Vault and OneCLI are proxies; Infisical, OpenBao, and HashiCorp Vault are vaults. For agent workloads you typically want both: a vault as the store, a proxy as the runtime boundary.

Why can't I just give my agent an API key from a secrets manager?

Because an LLM agent that can read a credential is a credential a prompt-injection attack can exfiltrate. The dominant leak path is mundane: the agent prints a value to a log or stdout, and that output is fed back into the context window where an attacker's injected instructions can read it. A 2026 arXiv analysis of agent-skill credential vulnerabilities attributed roughly 73% of them to print and console output. Pulling the key from a vault rather than hardcoding it does not change the exposure, because the agent still ends up holding the plaintext. Keeping the secret outside the agent entirely is the only structural fix.

Is HashiCorp Vault still open source?

No. HashiCorp relicensed Vault under the Business Source Licence (BUSL-1.1) in August 2023, which makes the source available to read but is not an OSI-approved open-source licence. HashiCorp was acquired by IBM, with the deal completing in early 2025. Vault remains a capable, mature secrets platform, but if a genuinely open licence is a requirement, OpenBao is the MPL-2.0 fork created in direct response to the relicensing, now governed under the Linux Foundation and API-compatible with Vault.

Are these tools production-ready?

It depends which one. Infisical (the platform), OpenBao, and HashiCorp Vault are mature, widely deployed systems. OneCLI is young but actively maintained and shipping releases frequently. Infisical's Agent Vault is explicitly a research preview as of May 2026, and its own repository warns it is not yet production-ready, so treat it as the reference architecture for the proxy pattern rather than something to put in front of a revenue-critical fleet today. The category itself is roughly two months old at the time of writing; expect rapid change.

Do I still need an agent proxy if I already run Infisical, Vault, or OpenBao?

Yes, if your agents are the consumers. A vault solves storage, rotation, and access control for the credential, but it still delivers the secret to whatever authenticates, and once your agent holds it, you are back to the exfiltration problem. The proxy is the missing layer: it lets the agent operate with a placeholder while the real credential is injected outside the agent's reach. The common pattern is a vault you already trust as the backing store, with Agent Vault or OneCLI as the runtime broker in front of it.

Which of these is the most genuinely open-source option?

By licence: OneCLI (Apache-2.0), Infisical Agent Vault and the Infisical core (MIT), OpenBao and SOPS (MPL-2.0), Vaultwarden and the Bitwarden server core (AGPL-3.0), and CyberArk Conjur's server (LGPL-3.0) are all OSI-approved open source. Two common assumptions are wrong in 2026: HashiCorp Vault is BUSL-1.1 (source-available, not open source), and parts of both Bitwarden and Infisical sit under source-available enterprise licences in dedicated directories. Read the licence file, not the marketing page: the distinction decides whether you can self-host and modify without a commercial agreement.