Show HN: Agent Vault – Open-source credential proxy and vault for agents

To be honest, I haven't used OneCLI personally before so I can't speak to it in detail but Agent Vault does take a similar approach with the MITM architecture and setting HTTPS_PROXY in the agent's environment to route traffic through the proxy; we feel like this is the right approach in terms of interface-agnostic ergonomics given that agents may interact with upstream services thru a number of means: API, CLI, SDK, MCP, etc.

Since we are in the beginnings of Agent Vault (AV), I wouldn't be surprised if there were many similarities. That said, AV likely takes a different approach with how its core primitives behave (e.g. define specific services along with how their auth schemes work) and is specifically designed in an infra-forward way that also considers agents as first class citizens.

When designing AV, we think a lot about the workflows that you might encounter, for instance, if you're designing a custom sandboxed agent; maybe you have a trusted orchestrator that needs to update credentials in AV and authenticate with it using workload identity in order to mint a short-lived token to be passed into a sandbox for an agent - this is possible. I suspect that how we think about the logical design starting from an infra standpoint will over time create two different experiences for a proxy.

If I understand correctly regarding credential stripping then yes. The idea is that you set the credentials in Agent Vault and define which services should be allowed through it, including the authentication method (e.g. Bearer token) to be used together with which credential.

We don't have plans yet to integrate with Bitwarden at this time but this could be something worth looking into at some point. We definitely would like to give Agent Vault first-class support for Infisical as a storage for credentials (this way you'd get all the benefits of secrets rotation, dynamic secrets, point in time recovery, secret versioning, etc. that already come with it).

I haven't used executor.sh but this seems to operate at a different layer from Agent Vault.

From what I'm seeing, executor.sh is an integration and execution layer for agents. Where Agent Vault shines is that it fits right into the tools and workflows that your agents are already using in an interface-agnostic way: API, CLI, SDK, MCP.

Put differently, the MITM architecture of Agent Vault (operates more at the network‑layer) allows the sandboxed agent can do whatever it would've done normally, just all routed through AV - the agent is basically proxy unaware.

Can you please elaborate on the agent signing up for a service piece? I'm curious to understand the use case more (type of agent, what credit, etc.).

The current modal assumes that you have a trusted entity whose able to save credentials to Agent Vault; that entity is likely not the agent itself because that would mean that the agent would have access to credentials. The agent is then simply configured to proxy requests through AV which attaches credentials at this proxy layer. Here are two examples:

Example 1:

- You have a backend that saves an API Key to AV for a specific vault and defines the service rules for how that credential can be used.

- That same backend mints a session-scoped token to AV and invokes the creation of a pre-configured sandbox, passing that token into it.

- The agent in the sandbox does what it needs to do, requests fully proxied through AV.

Example 2:

- A human operator manually goes into AV and adds an API Key.

- The human operator spins up an agent (could be an OpenClaw, Claude Code, etc.) in a pre-configured environment to route requests through AV. This can be done using non-cooperative sandbox mode with the AV CLI or through more manual configuration.

- The agent does what it needs to do, requests fully proxied through AV.

We're still working on smoothening it out but perhaps this gives you a better idea of how this might work.

AV does have a permission system that supports agents being able to save credentials to it and then subsequently using the proxy (maybe this is what you're targeting) but this isn't the use case that I've personally explored at much; definitely worth looking into tho.

Yeah idk if this is solveable but let's say I have a master agent that I say go sign me up for these services so you can build secure agents to use the keys securely.

It seems like it simply has to stop and tell me to handle the secrets to put them in vault. Because of the data/instructions in same channel problem.

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).

https://github.com/rmorlok/authproxy