Show HN: OneCLI – OSS credential gateway that keeps secrets out of AI agents

Posted by Jonathanfishner 1 day ago

Counter103Comment31OpenOriginal

hey HN, Jonathan and Guy here, creators of OneCLI (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.

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!

Comments

Comment by sandeepkd 1 day ago

It works great for static credentials. As a product I think about adding couple more things that might be helpful here (Btw I am not the client for this, I just happen to know them as practical problems)

1. Support for OAuth Client credentials - Gateway does the OAuth dance to get the access token, this is quite practical and even useful in case of regular services running across clusters and sharing the same clientId-secretId

2. Support for request retries on certain failures and short circuiting in other cases

Comment by Jonathanfishner 1 day ago

thanks, both are useful.

1. we support OAuth apps today, and we're growing the catalog based on demand. we support rotating and refreshing tokens for those.

2. I'd like to understand your case better. sitting in the request path means we could own retry mechanisms, but I'm curious what made you think of it, what kind of use cases did you have in mind?

Comment by sandeepkd 1 day ago

Almost every API caller has to add the logic for retries based on the response codes, centralizing it with the gateway optimizes the repetitive code across the clients.

Trip breaker patterns are good for resource usage on both sides (client and server) when you know things are not working. In addition to that it also saves on cost for the clients if every call is billed irrespective of success or failure.

Comment by Jonathanfishner 23 hours ago

got it. we have not heard that need from users yet, but, can def see it being usefule as a fallback mechanism, since we are already sit at this network proxy layer.

what type of calls are you aiming to? can share example of that "call is billed.." is that specific apps you have in mind?

Comment by Onavo 23 hours ago

Also it would be nice to support browser cookies and flows too.

Comment by emilsoman 1 day ago

How does it compare to agent-vault and clawpatrol?

Comment by 1 day ago

Comment by vayup 1 day ago

MITM is a feature now.

Comment by redbridgerock 1 day ago

Oo this is interesting, blocking it on the network level is nice

Comment by trallnag 7 hours ago

What happens if the "fake" key gets compromised?

Comment by osinix 1 day ago

This is the same old good way from database world. A db client never touches the disk, but sends requests to a server who owns it. Same in your product. Keys are separated from agents and if needed, agents must send request to a proxy who owns them. Old proven design. Good luck.

Comment by doctorpangloss 1 day ago

does the agent control the environment that onecli is running in? (yes)

Comment by Jonathanfishner 1 day ago

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

Comment by stephantul 1 day ago

It is hilarious to see most comments are people peddling their own products more or less directly.

Comment by rvz 1 day ago

This is what happens when building software goes to 0.

"Build it and they will come" now works well for competition:

- If you build it (and it is not useful) they won't come.

- If you build it (and it is useful and successful) they will come and copy you to build their own.

Comment by adithyassekhar 1 day ago

Holy mother of whatever this is, everyone got the same idea again and there’s a bunch of implementations people are desperate to promote in the comments.

You’re just trading one key for another, whatever abstraction you chose to trust, at some point credentials will pass to your llm of the week.

Comment by mjg59 1 day ago

> at some point credentials will pass to your llm of the week.

How?

Comment by theapiartist 1 day ago

I happen to know a solution where credentials wouldn't get to the agent. It's structurally impossible

Comment by throw1234567891 1 day ago

I know one, too.

Comment by theapiartist 18 hours ago

Do tell

Comment by notaharvardmba 1 day ago

oauth, saml, oidc accomplish the same thing in a way more mature way, so if you’re already using SSO just do that instead of adding another point of failure..

Comment by mjg59 1 day ago

No they don't - you're still giving the agent a static token that can be exfiltrated and used elsewhere.

Comment by hmokiguess 1 day ago

doesn't the token has an expiry window though? if you're using oidc/sso with aws for example it is short lived and can be revoked

Comment by mjg59 1 day ago

The refresh token is often going to be good for a week, even if the access token isn't.

Comment by gdemartino 12 hours ago

[flagged]

Comment by winterrx 1 day ago

nice 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

Comment by bstsb 1 day ago

+1 on infisical. brilliant self-hosted offering, i love their CLI and it works well with CI pipelines

Comment by aliasxneo 1 day ago

Curious how you justify their pricing? Last I checked the $/identity extended to machine accounts which absolutely blew my mind.

Comment by aiman_alsari 1 day ago

If you want fully free and open source enterprise features you're better off going to OpenBao

Comment by wulfkaal 6 hours ago

[flagged]

Comment by chris_fa__ 13 hours ago

[flagged]

Comment by feiz45607 13 hours ago

[dead]

Comment by frank-bee 1 day ago

[flagged]

Comment by russelmelroy 15 hours ago

[flagged]

Comment by jules_sarah088 16 hours ago

[flagged]

Comment by theozero 1 day ago

Looks great. The "credential broker" pattern (inject placeholders, replace in proxy) is something we just added to https://varlock.dev (totally free and open source).

Rather than using a dashboard, ours is configured within a .env.schema file, and rather than our own vault, we can pull secrets using our plugins (16 and counting) including Infisical, 1Password, Bitwarden, AWS, GCP, Azure, more. Also very useful for coding tasks in general, as we have integrations for most frameworks, and add built in validation, type safety, leak detection, etc.

Will definitely be keeping an eye on OneCLI to compare notes.

Comment by rahulr0609 1 day ago

+1 to Infisical.

We added Hashicorp Vault support here: https://github.com/Infisical/agent-vault/pull/256

Comment by denysvitali 1 day ago

Nice! I've built something like this, although specific to GitHub: 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

Comment by felixlu2026 14 hours ago

[dead]

Comment by oliver236 1 day ago

why not just use 1password

Comment by Jonathanfishner 22 hours ago

[dead]