Agent Vault: an HTTP credential broker that keeps secrets out of your agents

The problem Agent Vault was built around: prompt injection that reads your API keys

The README frames the problem in one sentence: traditional secrets management returns credentials to the application, and that model breaks when the application is an AI agent that can be manipulated through prompt injection. If ANTHROPIC_API_KEY or GITHUB_PAT sits in the agent's environment, a successful injection turns into credential exfiltration, because the agent holds the real value and can be talked into sending it somewhere. Agent Vault's stated goal is to remove that possibility rather than detect it: agents should not possess credentials at all. The audience is narrow and specific. The README lists secure remote coding agents (a Claude Code session that needs Anthropic and GitHub access), all-purpose agents such as OpenClaw and Hermes, custom agents and harnesses, and ephemeral sandboxes where an orchestrator mints a temporary token for the agent to use. If your agent runs in a container you control, on a host you control, and never processes untrusted input, the threat model this project addresses is largely absent, and the operational cost described below buys you little.

How the brokering actually works: a MITM proxy that rewrites auth on the way out

Agent Vault ships as a single binary that acts as both a server and a CLI client. It stores credentials and brokers them to agents using a MITM proxy architecture. The agent is bootstrapped to send its outbound traffic through the proxy via HTTPS_PROXY, so MCP servers, CLIs, SDKs and raw API clients keep working without code changes. When a request arrives, Agent Vault matches it against a configured service, then either substitutes a dummy placeholder value in a header (the README gives __anthropic_api_key__ as the example) with the real credential, or replaces the auth header on the outbound request entirely. The request then leaves for the target API carrying the real credential, while the agent never saw it. Two consequences follow from that design. First, the vault has to terminate TLS to read and rewrite headers, which is why the bootstrap step exists and why the CA certificate has to be trusted inside the agent environment. Second, every authenticated call is visible to the vault, which is what makes egress filtering and request logging possible: you can restrict which agents reach which services and which endpoints on those services, and inspect the authenticated traffic afterwards. The README also documents the default for traffic that matches no service: it forwards as plain proxy traffic. Setting unmatched_host_policy=deny flips the vault into strict mode and returns 403 for those requests instead. That default is worth pausing on. A vault left in the default state still forwards unknown destinations, so the filtering guarantee only covers hosts you have explicitly configured, not the full egress surface.

Deployment shape: the vault belongs on a different machine from the agent

The README is explicit that Agent Vault is meant to run on a separate machine from the agents it serves, and it states the reason: that separation is what prevents an agent from reaching the stored credentials directly. This is not a stylistic preference, it is the security boundary the whole design rests on. A vault co-located with the agent, on the same host or in the same container, collapses back toward the problem the project set out to solve, since a compromised agent has a path to the credential store. The README's own diagram shows the split: agents on a private network, the vault injecting credentials as traffic leaves for api.anthropic.com, api.github.com, api.stripe.com and similar hosts. In practice this means the operator carries a second host to provision, patch and monitor, plus network rules that let the agent reach the vault's proxy port and nothing else on that machine. The README does not spell out those network rules, so treat the topology as a design constraint you have to implement rather than a default the software enforces for you.

Credential stores: local encrypted store by default, Infisical as a backend

By default Agent Vault stores credentials itself in a local encrypted store, which is the reason the README can describe it as a self-contained binary with no dependency on any other system. The alternative is a pluggable credential store, documented at docs/learn/credential-stores.mdx, which lets you back the vault with an external secrets store such as Infisical. The README states that this path extends Agent Vault to include features like dynamic secrets from Infisical. That is the honest way to read the feature matrix: the interesting secret-management capabilities arrive when you attach Infisical, not when you run the binary standalone. If you choose the local store, you own the lifecycle questions the README does not answer here. It does not describe rotation scheduling, version history, or what happens to in-flight requests when a credential changes. Those gaps are not hidden, they are simply outside what the supplied material covers, and you should confirm them against the documentation before committing to the standalone mode for anything long-lived.

Getting it running: HTTPS_PROXY bootstrap and the strict-mode switch

The README points to docs.agent-vault.dev/installation and docs.agent-vault.dev/tutorial for the concrete steps, and it does not reproduce the full command sequence in the repository text. What it does establish is the shape of the setup. You install the single binary, which serves as both the vault server and the CLI client used to manage it. You register credentials for the services your agent needs, the README's examples being ANTHROPIC_API_KEY and GITHUB_PAT. You then bootstrap the agent environment so its outbound HTTP traffic goes through the vault, which the README describes as making the agent compatible with the MITM architecture via HTTPS_PROXY. Because the vault terminates TLS, the agent environment has to trust the vault's certificate; the README treats this bootstrap as part of the integration rather than an optional hardening step. The one configuration key the README names directly is unmatched_host_policy, which takes the value deny to reject unmatched requests with 403 instead of forwarding them. That key is the difference between a proxy that brokers known services and a proxy that also acts as an egress control point, so decide its value deliberately rather than accepting the permissive default. For exact commands and any flags around the bootstrap step, read the installation page, since guessing them from the README would be speculation.

Where Agent Vault is the wrong tool, and what to use instead

The most useful limitation is written by the maintainers themselves. The README compares Agent Vault with Infisical Agent Proxy and recommends Agent Proxy for production and enterprise use cases. The difference in approach is concrete. Agent Vault is a self-contained binary that stores credentials itself and runs entirely on infrastructure you control, with no dependency on any other system. Agent Proxy is built directly into Infisical, so the secrets, the services they are brokered to, and the access control all live in one place, and it inherits the surrounding Infisical features: dynamic secrets, secret rotation, versioning and more. Agent Proxy is part of Infisical Secrets Management and the README says it is available on every plan including the free one, so the choice is not purely a pricing decision. The practical split is this. If you want a single binary with no external dependency and you accept that rotation and versioning are not part of the standalone story, Agent Vault fits. If you need those capabilities, or you already run Infisical, the integrated option covers the same brokering ground with less to operate. There is a second case worth naming: if your agents cannot be reconfigured to use HTTPS_PROXY, or run in a runtime that ignores proxy environment variables, the transparent integration this project depends on does not apply, and you would be looking at per-client configuration work the README does not promise to solve. A third: if your agents and your secrets already live behind a boundary where the agent process genuinely cannot read the credential store, the separate-host requirement adds infrastructure without changing the risk profile.

Maintenance, releases and the licence question you have to check yourself

The repository is active rather than archived, with a last push in September 2026 and releases at v0.39.1, v0.39.2 and v0.39.3 across August and September 2026. The version number is the more informative signal: a 0.x line at thirty-nine minor releases suggests steady iteration rather than a settled interface, so pin a version and read the release notes before upgrading, particularly if you have written automation against the CLI. Upstream, the project is backed by Infisical, which matters for the maintenance question in a way that a solo repository would not, though the README's own recommendation of Agent Proxy for production is a signal about where the company expects the heavier workloads to land. On licensing, the repository metadata reports NOASSERTION, which means no standard licence identifier was detected. That is not the same as an open licence, and it is not the same as a proprietary one; it means the terms were not machine-readable from the metadata. The README calls the project open-source, and the licence file in the repository is the authoritative source. Read it before you ship this inside a commercial product, and if the terms are unclear or the file is absent, ask the maintainers directly rather than assuming. Nothing here is legal advice, and the licence text is the only thing that answers the question.

Editorial conclusion

Adopt Agent Vault if you run agents in sandboxes or remote sessions that you cannot fully trust with real API keys, and you are willing to operate a separate proxy host and install a CA certificate in each agent environment. Do not adopt it if you need secret rotation, versioning or dynamic secrets today, or if your agents can reach the vault host directly; the README points production and enterprise users at Infisical Agent Proxy instead. Before rolling it out, verify that your agent runtime honours HTTPS_PROXY, check whether a request to an unmatched host would be forwarded or rejected under your unmatched_host_policy setting, and confirm the licence terms, since the repository metadata reports NOASSERTION rather than a named licence.

Official sources

1. Infisical/agent-vault on GitHub
2. Issues
3. Project website
4. README
5. Releases