--- title: "GitHub - onecli/onecli: Open-source credential vault, give your AI agents access to services without exposing keys." url: https://daily.dev/posts/github---onecli-onecli-open-source-credential-vault-give-your-ai-agents-access-to-services-without-5idhivxuo source_url: https://github.com/onecli/onecli type: article source: "Hacker News" published: 2026-03-12T20:20:21.895Z updated: 2026-07-23T20:13:28.900Z tags: ["typescript", "ai-agents", "rust", "openclaw"] reading_time: 4 upvotes: 1 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # GitHub - onecli/onecli: Open-source credential vault, give your AI agents access to services without exposing keys. **[Hacker News](https://daily.dev/sources/hn)** · 4 min read · 1 upvotes · 0 comments ## Summary OneCLI is an open-source credential vault and HTTP gateway designed to give AI agents access to external APIs without exposing real API keys. Agents use placeholder keys and make normal HTTP calls through the OneCLI proxy, which transparently swaps in the real credentials at request time. The gateway is built in Rust for performance and memory safety, while a Next.js dashboard handles secret management and permissions. Secrets are stored with AES-256-GCM encryption and decrypted only at request time. It supports multi-agent setups with scoped access tokens, runs with an embedded PGlite database (no external dependencies), and can be deployed via a single Docker command. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 150 comments across hackernews (as of 2026-07-23). **TL;DR:** The community broadly agrees that keeping credentials out of agent hands is the right idea, but is split on whether OneCLI adds meaningful value over existing tools (Vault, AWS Secrets Manager, auth-proxying) and skeptical that it truly solves the deeper problem of prompt-injection-driven misuse of legitimate API access. **Sentiment:** 30% positive · 45% mixed · 25% skeptical **The case for** - Agents never hold real credentials, preventing direct key exfiltration via prompt injection or accidental logging. - Scoping credentials to specific hosts (as noted by practitioners) adds a meaningful extra security layer. - Combining credential storage and proxy in one tool is seen as a practical convenience over stitching together separate solutions. - The human-approval layer and per-session permission scoping are cited as genuinely agent-specific features not covered by existing auth-proxy tools. - Running as a separate container outside the agent sandbox is recognized as architecturally sound. **The pushback** - Multiple commenters argue the core pattern (auth-proxying / credential injection) is a well-solved, decades-old problem and not agent-specific. - A prompt-injected agent can still misuse legitimate API access even without ever seeing the real key, so the threat model is incomplete. - Node.js historically ignores HTTP_PROXY, requiring iptables/sidecar workarounds that add operational complexity. - AWS SigV4 request signing cannot be handled by simple credential swap and requires non-trivial re-implementation. - The comment section is heavily populated by people promoting competing or similar projects, raising questions about the space's fragmentation. - Fake placeholder keys could trigger enterprise secret-scanning tools with false positives. - The tool adds another trust boundary (the proxy itself) that users must vet, rather than relying on battle-tested solutions like HashiCorp Vault. **By community** - hackernews (mixed): HN commenters appreciate the architectural direction but extensively debate whether it's genuinely novel versus a repackaging of existing auth-proxy patterns, and question whether it meaningfully reduces risk from prompt-injection-driven API misuse. **Hottest debate:** Whether the credential-proxy approach is a meaningfully new, agent-specific solution or simply a rebranding of long-established auth-proxying techniques that don't address the real risk of agents being manipulated into misusing legitimate API access. **Open questions** - How does OneCLI defend against prompt-injection attacks that cause the agent to call legitimate endpoints but exfiltrate sensitive data through the response? - How are dynamic or temporary elevated permissions handled, and does it integrate with existing IAM systems? - Will adapters for existing secret stores (1Password, HashiCorp Vault, AWS Secrets Manager) be supported? - Does it provide agent-level audit logs for all proxied requests? - How does it compare to similar tools like agent-vault and clawpatrol? **Highlights** > This 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 system needs to run outside of the execution sandbox so that the agent can’t just read the keys from the proxy process. For Airut I settled on a transparent (mitm)proxy, running in a separate container, and injecting proxy cert to the cert store in the container where the agent runs. This solved 1 and 3. > — [hardsnow on hackernews · 5 comments](https://news.ycombinator.com/item?id=47354122) > 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. > — [nonameiguess on hackernews](https://news.ycombinator.com/item?id=47355168) > 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. > — [c5huracan on hackernews · 1 comments](https://news.ycombinator.com/item?id=47359912) > I 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 that up as well. It seems the only sound solution is to have a sidecar attached to the agent and have the sidecar authenticate with the gateway using mTLS. The sidecar manages its own TLS key - the agent never has access to it. > — [morphology on hackernews · 1 comments](https://news.ycombinator.com/item?id=47356645) > 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." > — [Jonathanfishner on hackernews](https://news.ycombinator.com/item?id=47362315) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=47353558) · 161 points · 104 comments - [hackernews](https://news.ycombinator.com/item?id=49023427) · 52 points · 46 comments ## Similar posts on daily.dev - [GitHub - Infisical/agent-vault: A HTTP credential proxy and vault for AI agents](https://daily.dev/posts/github---infisical-agent-vault-a-http-credential-proxy-and-vault-for-ai-agents-uqhfhmxsr) · Hacker News · 1 upvotes · 0 comments - [NanoClaw Adopts OneCLI Agent Vault](https://daily.dev/posts/nanoclaw-adopts-onecli-agent-vault-pqz3ombky) · Hacker News · 17 upvotes · 1 comments - [Untitled](https://daily.dev/posts/untitled-kckcjr4lw) · SitePoint · 0 upvotes · 0 comments --- Tags: [#typescript](https://daily.dev/tags/typescript), [#ai-agents](https://daily.dev/tags/ai-agents), [#rust](https://daily.dev/tags/rust), [#openclaw](https://daily.dev/tags/openclaw) [View this post on daily.dev](https://daily.dev/posts/github---onecli-onecli-open-source-credential-vault-give-your-ai-agents-access-to-services-without-5idhivxuo)