Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: OneCLI – Vault for AI Agents in Rust

github.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Show HN: OneCLI – Vault for AI Agents in Rust

#51

Post by Jonathanfishner »

captn3m0 wrote: post #12

This 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…

It's not the same. The core overlap is that agents shouldn't be holding raw credentials, that part isn't new, agreed. But the problem space goes further when you're building for agents specifically:

- Requiring human approval before sensitive actions go through (as @guyb3 mentioned in the post)

- Managing short-lived JWT tokens (refresh/access) with tight TTLs.

- Scoping permissions per-session rather than per-service

Auth-proxying solves the "don't give the box your API key" part. But the approval layer and token lifecycle management are what make this agent-specific, not just "SSO proxy repackaged."

Re: Show HN: OneCLI – Vault for AI Agents in Rust

#52

Post by Jonathanfishner »

atonse wrote: post #5

IronClaw 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…

Re IronClaw is probably the most hardened open-source implementation I've seen for this, but a sufficiently clever prompt injection against the built-in tools (especially shell) could still reach secrets.

Re TLS: OneCLI itself runs in a separate container, acting as an HTTPS proxy. The SDK auto-configures agent containers with proxy env vars + a local CA cert. When the agent hits an intercepted domain, OneCLI terminates TLS, swaps placeholder tokens for real creds, and forwards upstream. Containers never touch actual keys.

More here: https://www.onecli.sh/docs/sdks/node#how-it-works

Re 1Password adapters: not yet, but on the roadmap.

Re: Show HN: OneCLI – Vault for AI Agents in Rust

#53

Post by multidude »

captn3m0 wrote: post #12

This 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…

I think you have a point. The credential part feels like a solved problem — auth-proxying has been around for a while. What seems genuinely new to me is the approval layer, the idea that a human should confirm before a sensitive action actually executes. I'm not sure that's covered by tokenizer or SSO proxy, but I could be wrong. Is that the real differentiator here, or am I missing something?

Re: Show HN: OneCLI – Vault for AI Agents in Rust

#54

Post by Jonathanfishner »

c5huracan wrote: post #44

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

that's exactly the idea. appreciate you framing it so clearly

Re: Show HN: OneCLI – Vault for AI Agents in Rust

#56

Post by atonse »

Jonathanfishner wrote: post #52
atonse wrote: post #5

IronClaw 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…

Re IronClaw is probably the most hardened open-source implementation I've seen for this, but a sufficiently clever prompt injection against the built-in tools (especially shell) could still reach secrets. Re TLS: OneCLI itself runs in a separate container, acting as an HTTPS proxy. The SDK auto-configures agent containers with proxy env vars + a local CA cert. When the agent hits an intercepted domain, OneCLI termina…

Ok that's what I assumed it probably did (modify the container's certificate trust store), thanks for the explanation.

Re: Show HN: OneCLI – Vault for AI Agents in Rust

#59

Post by kwstx »

This is a smart approach, giving agents access without exposing secrets is definitely needed. Curious how you handle dynamic access policies for agents that need temporary elevated permissions, or if you integrate with existing IAM systems. Also, do you track or enforce agent-level audit logs for requests that go through the proxy?
Post reply on HN