Show HN: Agent Vault – Open-source credential proxy and vault for agents (github.com)
We built Agent Vault in response to a question that been plaguing the industry: How do we give agents secure access to services without them reading any secrets?
Most teams building agents have run into this exact problem: They build an agent or agentic system and come to realize at some point that it needs credentials in order to access any services. The issue is that agents, unlike traditional workloads, are non-deterministic, highly-prone to prompt injection, and thus can easily be manipulated to leaking the credentials that they need to operate. This is the problem of credential exfiltration (not to be confused with data exfiltration).
In response to this, some teams we've seen have implemented basic guardrails and security controls to mitigate this risk in their agentic environments including using short-lived access tokens. The more advanced teams have started to converge toward a pattern: credential brokering, the idea being to separate agents from their credentials through some form of egress proxy. In this model, the agent makes a request to a proxy that attaches a credential onto it and brokers it through to the target service. This proxy approach is actually used in Anthropic's Managed Agents architecture blog with it being that "the harness is never made aware of the credentials." We've seen similar credential brokering schemes come out from Vercel and in Cloudflare's latest Outbound Workers.
Seeing all this made us think: What if we could create a portable credential brokering service plugged seamlessly into agents' existing workflows in an interface agnostic way, meaning that agents could continue to work with APIs, CLIs, SDKs, MCPs without interference and get the security of credential brokering.
This led to Agent Vault - an open source HTTP credential proxy and vault that we're building for AI agents. You can deploy this as a dedicated service and set up your agent's environment to proxy requests through it. Note that in a full deployment, you do need to lock down the network so that all outbound traffic is forced through Agent Vault
The Agent Vault (AV) implementation has a few interesting design decisions:
- Local Forward Proxy: AV chooses an interface agnostic approach to credential brokering by following a MITM architecture using HTTPS_PROXY as an environment variable set in the agent's environment to redirect traffic through it; this also means that it runs its own CA whose certificate must be configured on the client's trust store.
- MITM architecture: Since AV terminates TLS in order to do credential brokering its able to inspect traffic and apply rules to it before establishing a new TLS connection upstream. This makes it a great to be able to extend AV to incorporate firewall-like features to be applied at this proxy layer.
- Portable: AV itself is a single Go binary that bundles a server and the CLI; it can be deployed as a Docker container as well. In practice, this means that you can self-host AV on your own infrastructure and it should work more universally than provider specific approaches like that of Vercel and Cloudflare.
While the preliminary design of Agent Vault is a bit clunky to work with and we’d wished to have more time to smoothen the developer experience around it, particularly around the configuration setup for agents to start proxying requests through it, we figured it would be best to open source the technology and work with the community to make gradual improvements for it to ...
47 comments
[ 5.8 ms ] story [ 72.1 ms ] threadI use containers to isolate agents to just the data I intend for them to read and modify. If I have a data exfiltration event, it'll be limited to what I put into the container plus whatever code run inside the container can reach.
I have limited data in reach of the agent, limited network access for it, and was missing exactly this Vault. I'm relieved not to need to invent (vibe code) it.
Since the project is in active development, the form factor including API is unstable but I think it gives a good first glance into how we're thinking about secrets management for AI agents; we made some interesting architectural decisions along the way to get here, and I think this is generally on the right track with how the industry is thinking about solving credential exfiltration: thru credential brokering.
We'd appreciate any feedback; feel free also to raise issues, and contribute - this is very much welcome :)
https://github.com/rmorlok/authproxy
1. The end point matters, example if the credential is OAuth2 token and service has a token refresh endpoint then the response would have a new token in the payload reaching directly to the agent
2. Not all the end points are made the same even on the service side, some may not even require credential, the proxy may end up leaking the credential to such endpoints
3. The proxy is essentially doing a MITM at this point, it just increased its scope to do the certificate validation as well, to do it correctly is a hard problem
4. All credentials are stored on a machine, it requires a lot more access & authorization framework in terms of who can access the machine now. One might think that they closed a security gap and soon they realize that they opened up couple more in that attempt
We're pretty swarmed on requests at the moment but I've noted these down as improvements to AV; it's a work in progress, we'll be molding it into the right shape over the next few months.
A few thoughts for each of the above:
1. AV doesn't consider OAuth2 tokens atm but this is definitely a next step.
2. Agree which is why there is a "passthrough" mode; for each endpoint, you need to explicitly specify what credential is used for it.
3. That's correct. This is a MITM architecture with credential brokering capabilities added on top.
4. Agree. The idea here is that AV can function both as a proxy and vault but in a true production setting, it should pull credentials from a secure secrets store like Infisical. This way credentials cached in memory in AV can even be made ephemeral.
Great observations all around and we have plans for them :)
but the problem with that model is it's static protection. if the agent process itself becomes hostile or gets prompt-injected, keyring doesn't really help — it can still request the secret and get it, it just doesn't see it in the context window.
the shift i've been landing on and building into Orbital(my own project) is that it's less about blocking credential access and more about supervising it. you want to know exactly when and why the agent is requesting something, and have the ability to approve or deny in the moment. pre-set policies are hard because you genuinely can't anticipate what tools an agent will call before it runs — claude code might use curl, bash, or a completely random command depending on the problem. the approval needs to happen at runtime, not preset.
the proxy model here is interesting because it creates a natural supervision boundary. curious whether you're planning runtime approval flows or if the design stays policy-based.
Agents having direct access to credentials always felt a bit scary.
This seems cleaner, even if it just moves the trust somewhere else.
You'd add HTTPS_PROXY to your sandbox environment and pre-configure it to trust the AV CA.
For this reason, you'd want to keep the two separate; we have some ideas in the works for that atm but largely still experimental.