alt Hacker NewsShow HN: Agent Vault – Open-source credential proxy and vault for agents
Hey HN! Today we're launching Agent Vault - an open source HTTP credential proxy and vault for AI agents. Repo is at https://github.com/Infisical/agent-vault, and there's an in-depth description at https://infisical.com/blog/agent-vault-the-open-source-crede....
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 work seamlessly across all agentic use cases since each has its own nuances.
All in all, we believe credential brokering is the right next step for how secrets management should be done for agents and would love to hear your views, questions, feedback!
Comments
Could this work (or planned) on gVisor-based sandboxes?
T from Infisical here - Also forgot to mention that this is a research preview launch for Agent Vault and should be treated as such - experimental <<
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 :)
This is a good start, it does covers gaps in certain areas. There are few more areas I can think of
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
I have a related question, is anyone developing standards on how agents can proxy the requestor identity to backend database or application layers? (short lived oauth tokens perhaps, not long lived credentials like the ShowHN seems to focus on?)
been thinking about this exact problem for a while. my own setup uses OS keyring with a <secret:name> token substitution pattern — the agent requests a credential by name, the substitution happens at execution time, the LLM never sees the raw value in context or logs. works reasonably well.
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.
Been tinkering with something of my own at https://github.com/manojbajaj95/authsome. Core goal was to do credential management, from an ease point of view and not security.
I like this direction.
Agents having direct access to credentials always felt a bit scary.
This seems cleaner, even if it just moves the trust somewhere else.
I really like the approach you've taken of providing an egress proxy. That let's you do a lot of things that layer around providing gaurdrails and auditing. I've been taking a similar approach on an open source embedded iPaaS project I've been working on where it primarily offers an authenticating egress proxy to whatever business logic needs it (agent, sync engine, etc).
It looks promising if I have a request to llm with secrets is it handle it as well?
This doesn't change the fact that you'd still be able to exfiltrate data like sure they don't get credentials but if they get the proxy auth key then they would also be able to make requests through it no?
How is it different from Onecli ? And does it do credential stripping ? Will it support access SDK from Bitwarden and integrate with infiscal ?
Can I use Infisical cloud vaults with Agent Vault? I like the UI of secret management there. I like that I can manage secrets from many environments in a single place.
Completely unaffiliated but I just installed executor.sh today and it looks almost exactly the same
how do you deal with "access to the proxy"? because one can access maliciously without accessing to the token/secret.
How do you solve for the agent signing up for a service and needing to save it and guaranteeing the credit wont go to the chat?
yea
[dead]
[dead]
[dead]
[dead]
Curious how you think about this meeting the agent-identity side. The proxy knows who's calling, but the callee (what agent lives at api.example.com, what auth it expects, what its card looks like) doesn't really have a home. Been poking at that half at agents.ml and it feels like the two pieces want to fit together
It’s an idea that obfuscates keys a bit, but how are you going to prevent the agent from gaining access to the vault and keys itself? I’ve seen it reverse engineer many things to expose the underlying credentials. I can only think running this on a firewall that the agent can’t access to prevent escalation.