How is it different from Onecli ? And does it do credential stripping ? Will it support access SDK from Bitwarden and integrate with infiscal ?
NVIDIA's OpenShell also has its own version of this, though its also in very early stages.
Show HN: Agent Vault – Open-source credential proxy and vault for agents
31–40 of 71 posts
Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents
#32how do you deal with "access to the proxy"? because one can access maliciously without accessing to the token/secret.
Agent Vault should remain in close proximity to the sandboxed agent and not be exposed to the public internet; your standard network security controls apply.
The proxy itself currently implements a token-based auth scheme. Depending on your setup, you can have an orchestrator mint an ephemeral token to be passed to a sandboxed agent to authenticate with the proxy.
Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents
#33[dead]
Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents
#34how do you deal with "access to the proxy"? because one can access maliciously without accessing to the token/secret.
Agent Vault should remain in close proximity to the sandboxed agent and not be exposed to the public internet; your standard network security controls apply. The proxy itself currently implements a token-based auth scheme. Depending on your setup, you can have an orchestrator mint an ephemeral token to be passed to a sandboxed agent to authenticate with the proxy.
this feels like vpn all over again. the location shouldn't grant any inherent trust.
Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents
#35yea
Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents
#36Earlier quoted context omitted.
Agent Vault should remain in close proximity to the sandboxed agent and not be exposed to the public internet; your standard network security controls apply. The proxy itself currently implements a token-based auth scheme. Depending on your setup, you can have an orchestrator mint an ephemeral token to be passed to a sandboxed agent to authenticate with the proxy.
this feels like vpn all over again. the location shouldn't grant any inherent trust.
[dead]
Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents
#37[flagged]
Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents
#38This 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
Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents
#39been thinking about this exact problem for a while. my own setup uses OS keyring with a 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.
Re: Show HN: Agent Vault – Open-source credential proxy and vault for agents
#40Been 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.