Secret and credential sprawl is a real problem in agent pipelines specifically -- each agent needs its own scoped access and the blast radius of a leaked credential is much larger when an agent can act autonomously. We ended up with a tiered secret model: agents get short-lived derived tokens scoped to exactly the tools they need for a given task, not broad API keys. Revocation on task completion, not on schedule. More ops overhead upfront but caught two misuse cases that would have been invisible otherwise.
Show HN: OneCLI – Vault for AI Agents in Rust
21–30 of 62 posts
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#22You don't want to give the agent a raw key, so you give it a dummy one which will automatically be converted into the real key in the proxy. So how does that help exactly? The agent can still do exactly what it could have done if it had the real key.
For one thing, it cannot leak secrets between services.
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#23[flagged]
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#24You don't want to give the agent a raw key, so you give it a dummy one which will automatically be converted into the real key in the proxy. So how does that help exactly? The agent can still do exactly what it could have done if it had the real key.
For one thing, it cannot leak secrets between services.
Is that really a problem? All the examples on the repo page themselves show LLMs running unintended operations on the "correct" service and messing up your data. And that is very much still going to happen with this wrapper. If anything it is going to provide a false sense of security.
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#25This is the right approach. I built a similar system to https://github.com/airutorg/airut - couple of learnings to share: 1) Not all systems respect HTTP_PROXY. Node in particular is very uncooperative in this regard. 2) AWS access keys can’t be handled by simple credential swap; the requests need to be resigned with the real keys. Replicating the SigV4 and SigV4A exactly was bit of a pain. 3) To be secure, this syst…
Node 24+ does respect HTTP_PROXY when NODE_USE_ENV_PROXY=1 is set.
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#26This can also be done using existing Vaults or Secrets manager. Hashicorp Vault can do this and agents can be instructed to get secrets, which are set without the agent's knowledge. I use these 2 simple scripts with OpenClaw to achieve this, along with time-scoped expiration. The call to vault_get.sh is inside the agent's skill script so that the secrets are not leaked to LLMs or in any trace logs: vault_get.sh: http…
It seems that the architecture you describe still gives the key to the agent (who could email it to red team or perform nefarious actions with it). The advantage of OP's architecture is that the agent never sees the key and you could inspect the request before proxying it. Is that right or do I misunderstand something?
Sort of. The point of Vault is you're supposed to actually use RBAC and least privilege and store NPE credentials that are properly scoped to the actions you're comfortable automating, which your NPE then gets a certificate to fetch on demand, rather than just giving it your own personal root credentials that can do anything.
We're going to see this reinvented thousands of times in the next few months by people whose understanding of security is far poorer than HashiCorp's, via implementations that are nowhere near as well-tested, if tested at all.
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#27This can also be done using existing Vaults or Secrets manager. Hashicorp Vault can do this and agents can be instructed to get secrets, which are set without the agent's knowledge. I use these 2 simple scripts with OpenClaw to achieve this, along with time-scoped expiration. The call to vault_get.sh is inside the agent's skill script so that the secrets are not leaked to LLMs or in any trace logs: vault_get.sh: http…
It seems that the architecture you describe still gives the key to the agent (who could email it to red team or perform nefarious actions with it). The advantage of OP's architecture is that the agent never sees the key and you could inspect the request before proxying it. Is that right or do I misunderstand something?
The call flow is:
agent -> select skill (ex: reddit) -> execute action in skill -> script or code associated with skill -> get api key -> call reddit -> reddit posts -> agent.
The agent sees the output of the service, it does not directly see the keys. In OpenClaw, it’s possible to create the skill in a way that the agent does not directly know about or use vault_get command.
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#28[flagged]
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#29IronClaw seems to do this natively, I like the idea in general, so it's good too see this pulled out. I have few questions: - How can a proxy inject stuff if it's TLS encrypted? (same for IronClaw and others) - Any adapters for existing secret stores? like maybe my fake credential can be a 1Password entry path (like 1Password:vault-name/entry/field and it would pull from 1P instead of having to have yet another place…
You use a forward proxy that can MITM.
So would I have to add that Proxy's certificate to my trust store?
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#30[flagged]
Rust might be a solid choice but most of it is written in Typescript... which is not as solid of a choice.