[dead]
Show HN: OneCLI – Vault for AI Agents in Rust
41–50 of 62 posts
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#42[dead]
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#43I don't get the benefit. Yes, agents should not have access to API keys because they can easily be fooled into giving up those API keys. But what's to prevent a malicious agent from re-using the honest agent's fake API key that it exfiltrates via prompt injection? The gateway can't tell that the request is coming from the malicious agent. If the honest agent can read its own proxy authorization token, it can give tha…
[flagged]
People are addressing that gap. I have a secure agent framework that uses a tool gateway hooked up to OPA (https://github.com/sibyllinesoft/smith-core), this solves the credential issue as the credentials live in the tools, and the authz issue, as OPA policy controls who does what.
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#44Use Vault and use a proxy. They address different problems.
Vault protects keys at rest, but the agent still gets them at runtime. The proxy keeps the key away from the agent entirely, which closes key leakage. But a prompt-injected agent can still exfiltrate data it reads through the proxy. The trust boundary shifts, it doesn't disappear.
Looks like OneCLI combines both into one tool, which is the right call.
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#45I mean it's just not solving the problem right? If the model got injected then whatever the wrapper do can not prevent the consequences?
Sorry but am I missing something here?
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#46This 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…
Im literally working on the exact same solution. Difference is I'm running the system in a Kubernetes cluster. I essentially run a sidecar container that sets up ip tables that redirect all requests through my mitm proxy. This was specifically required because of Node not respecting HTTP_PROXY. Also had to inject a self signed cert to ensure SSL could be proxied and terminated by the mitm proxy, which then injects th…
I'm working on something similar with https://github.com/dtkav/agent-creds though I keep growing the scope.
The model is solid. It feels like the right way to use YOLO mode.
I've been working on making the auth setup more granular with macaroons and third party caveats.
My dream is to have plugins for upstreams using OpenAPI specs and then make it really easy to stitch together grants across subsets of APIs.
I think there's a product in here somewhere...
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#47Earlier quoted context omitted.
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.
It would seem in this design that all the tools should be called through a wrapper that understands the vault and provides the credentials to the tool in the right way. How otherwise can curl use the credentials? Curl has no idea that there's a vault somewhere
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#48This 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.
Node v22.21+ as well
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#49This problem+solution, like many others in the agentic-space, have nothing agent-specific. Giving a "box" API keys was always considered a risk, and auth-proxying has existed as a solution forever. See tokenizer[0] by the fly.io team, which makes it a stateless service for eg - no database or dashboard. Or the buzzfeed SSO proxy, which lets you do the same via an OAuth2-dance at the frontend, and a upstream config at…
Just because it's been done before for a different use-case doesn't mean that building exclusively for this use-case doesn't remove friction.
But it hasn't been built exclusively for that use case. It's literally the same.
Re: Show HN: OneCLI – Vault for AI Agents in Rust
#50This 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…
Also doesn't this mean I have to reconfigure all my tools to use HTTP and then when I forget to enable this it will fall back to getting MITM'd by the Internet? Fails open in the most insecure method ever