6 ms·
Show HN: OneCLI – OSS credential gateway that keeps secrets out of AI agents
hey HN, Jonathan and Guy here, creators of OneCLI (https://onecli.sh/ https://onecli.sh/). OneCLI is an open source vault for AI Agents.
Traditional vaults are used to store your secrets and, on demand, provide them to you all in a secure way, trusting the person to keep them safe. We figured that in the agent's world, this is not the case, as you don't know what happens with the secret after it's delivered to the agent, or where it was saved. Or maybe someone even manipulated them to hand them over...
From that understanding, we decided to build a network gateway that sits between your AI agents and the services they call. OneCLI matches the request by host/path, verifies the agent should have access, swaps the placeholder for the real credential, and forwards the request.
the secrets set inside the OneCLI vault, encrypted on rest, or could fetch in realtime from your bitwarden / 1password wallets.
Demo - https://www.youtube.com/watch?v=5e5pbPEzZfY https://www.youtube.com/watch?v=5e5pbPEzZfY.
We started working on this by accident, even though our careers were in the security space. We were working on a devtool called ChartDB, an open-source DB tool. When OpenClaw took off back in January, we started using it to orchestrate agents on top of ChartDB. We quickly understood there is a big issue around auth. Agents need credentials to do real work, but to give them those secrets would not be the best idea. they keep them in their memory and also write them down to local files and their sessions as plain text. And we knew that agents can easily be fooled into giving up those API keys/secrets. So we needed some way to control the agent and stop prompt injections from tricking it into using its services for an attacker's benefit. Not providing the keys to the agent + adding alerts or human-in-the-loop for sensitive operations, in case someone manipulates the agent, and access logs are being audited.
We use it ourselves daily. My OpenClaw runs my day across Attio, Gmail, and my calendar, with human-in-the-loop approval on sensitive actions. The approval is enforced at the network layer, so it holds whether the agent goes through MCP, CLI, curl, or code it wrote on the fly. Guy uses it to review PRs but can't merge without his approval.
Companies mostly use it for coding agents currently, which get creative about finding ways to elevate their permissions to reach the goal. With OneCLI, it doesn't matter what the agent finds: if the request isn't in policy, it will not go through.
The proxy is written in Rust, the dashboard is Next.js, and secrets are AES-256-GCM encrypted at rest. Everything runs in a Docker container. It works with any agent framework (Claude Code, Codex, Cursor, OpenClaw, Hermes or anything that can set an HTTPS_PROXY).
It won't stop an agent from misusing access it legitimately has, so scope policies tightly!
happy to answer anything. We believe we can't trust the model to behave and have to set deterministic rules to stay in control. Comments welcome!
- winterrx 2mo agonice launch. i have started to use a secrets manager (infisical) recently for my different projects and it's been really helpful. are your customers solo hackers, small startups or large enterprises that are looking for this kind of solution? i like to see competition in the space
- bstsb 2mo ago+1 on infisical. brilliant self-hosted offering, i love their CLI and it works well with CI pipelines
- aliasxneo 2mo agoCurious how you justify their pricing? Last I checked the $/identity extended to machine accounts which absolutely blew my mind.
- aiman_alsari 2mo agoIf you want fully free and open source enterprise features you're better off going to OpenBao
- doctorpangloss 2mo agodoes the agent control the environment that onecli is running in? (yes)
- Jonathanfishner 2mo agoyes the agent controls its environment which is exactly why nothing sensitive should live there. The gateway and the real secrets sit outside the sandbox. that said, not holding the secrets doesn't make the agent harmless. It still acts autonomously, and it can use whatever access those credentials grant. do you see the second half as the bigger risk? curious how people are thinking about it.
- denysvitali 2mo agoNice! I've built something like this, although specific to GitHub: https://github.com/denysvitali/gh-proxy https://github.com/denysvitali/gh-proxy The idea being that if the fake token leaks from my sandbox - it would be completely useless for an attacker