[HN Gopher] Show HN: OneCLI - Vault for AI Agents in Rust
___________________________________________________________________
Show HN: OneCLI - Vault for AI Agents in Rust
We built OneCLI because AI agents are being given raw API keys. And
it's going about as well as you'd expect. We figured the answer
isn't "don't give agents access," it's "give them access without
giving them secrets." OneCLI is an open-source gateway that sits
between your AI agents and the services they call. You store your
real credentials once in OneCLI's encrypted vault, and give your
agents placeholder keys. When an agent makes an HTTP call through
the proxy, 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 agent never touches the
actual secret. It just uses CLI or MCP tools as normal. Try it in
one line: docker run --pull always -p 10254:10254 -p 10255:10255 -v
onecli-data:/app/data ghcr.io/onecli/onecli The proxy is written
in Rust, the dashboard is Next.js, and secrets are AES-256-GCM
encrypted at rest. Everything runs in a single Docker container
with an embedded Postgres (PGlite), no external dependencies. Works
with any agent framework (OpenClaw, NanoClaw, IronClaw, or anything
that can set an HTTPS_PROXY). We started with what felt most
urgent: agents shouldn't be holding raw credentials. The next layer
is access policies and audit, defining what each agent can call,
logging everything, and requiring human approval before sensitive
actions go through. It's Apache-2.0 licensed. We'd love feedback
on the approach, and we're especially curious how people are
handling agent auth today. GitHub:
https://github.com/onecli/onecli Site: https://onecli.sh
Author : guyb3
Score : 108 points
Date : 2026-03-12 16:41 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| anthonyskipper wrote:
| The fake key for real key thing seems like a problem. A lot of
| enterprise scanning tools look for keys in repos and other
| locations and you will get a lot of false positives.
|
| Otherwise this is cool, we need more competition here.
| guyb3 wrote:
| It's a good point, I don't think the placeholders we use will
| trigger a secret scanner, but we can adjust if it's an issue.
|
| https://github.com/onecli/onecli/blob/942cfc6c6fd6e184504e01...
| atonse wrote:
| 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 for me to store secrets?
| inssein wrote:
| You use a forward proxy that can MITM.
| atonse wrote:
| So would I have to add that Proxy's certificate to my trust
| store?
| debarshri wrote:
| Does it act like an auth proxy?
| hardsnow wrote:
| 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.
| lancetipton wrote:
| 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
| the secrets, and forwards the request on.
|
| Have you run into any issues with this setup? I'm trying to
| figure out if there's anything I'm missing that might come back
| to bite me?
| hardsnow wrote:
| I've been running this with workloads accessing Anthropic,
| GitHub, Gemini, and AWS & CF R2 APIs for a while now, and
| have not ran into issues. I'm sure there's an API out there
| that won't work out of the box but I'm positive that support
| could be added.
|
| Another thing I did was to allow configuring which hosts each
| credential is scoped to. Replacement /resigning doesn't
| happen unless host matches. That way it is not possible to
| leak keys by making requests to malicious hosts.
| lancetipton wrote:
| The last note about configuring hosts to credentials is an
| excellent idea, and one I did not think to do. Currently
| I'm just doing a replace on any that matches in the
| request. This adds an extra layer of security to it. Much
| appreciated.
| inssein wrote:
| This is basically what https://www.verygoodsecurity.com/ (their
| main product), but it's heavily focused on credit card data.
| semanticc wrote:
| Node 24+ does respect HTTP_PROXY when NODE_USE_ENV_PROXY=1 is
| set.
| sathish316 wrote:
| This can also be done using existing Vaults or Secrets manager.
| Hashicorp Vault can do this and agents can be instructed to get
| secrets, which are set without the agent's knowledge. I use these
| 2 simple scripts with OpenClaw to achieve this, along with time-
| scoped expiration. The call to vault_get.sh is inside the agent's
| skill script so that the secrets are not leaked to LLMs or in any
| trace logs:
|
| vault_get.sh:
| https://gist.github.com/sathish316/1ca3fe1b124577d1354ee254a...
|
| vault_set.sh:
| https://gist.github.com/sathish316/1f4e6549a8f85ac5c5ac8a088...
|
| Blog about the full setup for OpenClaw:
| https://x.com/sathish316/status/2019496552419717390
| rgbrgb wrote:
| 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?
| nonameiguess wrote:
| 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.
| sathish316 wrote:
| 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.
| jpbryan wrote:
| Why not just use AWS Secrets Manager?
| stevekemp wrote:
| A program making a call to github.com needs an authentication
| token.
|
| What are you suggesting? The program makes a call to retrieve
| the secret from AWS? Then has full access to do with it what
| they want? That's exactly the risk and the problem this, and
| related solutions mentioned in this thread, is trying to solve.
| empath75 wrote:
| Don't see any reason to use this over vault.
| captn3m0 wrote:
| 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 the
| backend which injects secrets:
| https://github.com/buzzfeed/sso/blob/549155a64d6c5f8916ed909....
|
| [0]: https://github.com/superfly/tokenizer
| RhodesianHunter wrote:
| 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.
| Olshansky wrote:
| tl;dr "scrt [set|get|list|....]" is also a great option
|
| ---
|
| If this is of interest, I also recommend looking into:
| https://github.com/loderunner/scrt.
|
| To me, it's a compliment to 1password.
|
| I use it to save every new secret/api key I get via the CLI.
|
| It's intentionally very feature limited.
|
| Haven't tried it with agents, but wouldn't be surprised if the
| CLI (as is) would be enough.
| paxys wrote:
| You don't want to give the agent a raw key, so you give it a
| dummy one which will automatically be converted into the real key
| in the proxy.
|
| So how does that help exactly? The agent can still do exactly
| what it could have done if it had the real key.
| brabel wrote:
| For one thing, it cannot leak secrets between services.
| paxys wrote:
| Is that really a problem? All the examples on the repo page
| themselves show LLMs running unintended operations on the
| "correct" service and messing up your data. And that is very
| much still going to happen with this wrapper. If anything it
| is going to provide a false sense of security.
| cataflam wrote:
| it cannot email your secret key to an attacker because of
| prompt injection etc.
| wuweiaxin wrote:
| Secret and credential sprawl is a real problem in agent pipelines
| specifically -- each agent needs its own scoped access and the
| blast radius of a leaked credential is much larger when an agent
| can act autonomously. We ended up with a tiered secret model:
| agents get short-lived derived tokens scoped to exactly the tools
| they need for a given task, not broad API keys. Revocation on
| task completion, not on schedule. More ops overhead upfront but
| caught two misuse cases that would have been invisible otherwise.
| miki_ships wrote:
| wuweiaxin's short-lived-tokens-per-task is the right model, but
| it hits a ceiling: AWS IAM makes it native; most SaaS APIs don't.
| GitHub hands you a bearer token, Stripe too, Notion too. The
| proxy fills that gap. You get per-request scope enforcement
| without depending on the upstream service supporting fine-grained
| auth. That's the actual answer to paxys's question -- it's not
| about preventing the agent from making the same calls, it's about
| enforcing which calls it's allowed to make when the credential
| issuer won't.
| Mooshux wrote:
| Nice. The proxy-intercept approach is the right architecture.
| Agent gets a placeholder, the real credential never touches agent
| memory. Rust is a solid choice for something this sensitive.
|
| The gap that gets teams eventually: this works great on one
| machine, but breaks at the team boundary. CI pipelines have no
| localhost. Multiple devs sharing agents need access control and
| audit trails, not just a local swap. A rogue sub-agent with the
| placeholder can still do damage if the proxy has no per-agent
| scoping.
|
| We ran into the same thing building this out for OpenClaw setups.
| Ended up going vault-backed with group-based access control and
| HMAC-signed calls per request. Full breakdown on the production
| version: https://www.apistronghold.com/blog/phantom-token-
| pattern-pro...
| eikenberry wrote:
| Rust might be a solid choice but most of it is written in
| Typescript... which is not as solid of a choice.
| skywhopper wrote:
| This is slick but the only thing it prevents is agents from
| directly sharing the credentials through git or something.
|
| But that's not the biggest risk of giving credentials to agents.
| If they can still make arbitrary API calls, they can still cost
| money or cause security problems or delete production.
|
| If you're worried about creds leakage only because your
| credentials are static and permanent, well, time to upgrade your
| secrets architecture.
| sethcronin wrote:
| Oops, i read vault and thought obsidian vault haha - but yeah,
| one of the issues is if your agent can _execute_ on the secret at
| all, it can be potentially convinced to use it in a way that does
| not benefit you, even if it doesn't have access to the secret
| itself.
| morphology wrote:
| 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.
| dingdingdang wrote:
| But surely the point is that the proxy key is for your local
| network, it ain't got no value on the interwebz.
| morphology wrote:
| Precisely. You absolutely have to ensure that random agents
| can't join your local network, which means you need a
| deterministic orchestrator or an AI orchestrator that only
| spins up a handful of vetted agents.
| robutsume wrote:
| The mTLS sidecar is the right answer but it's worth noting why
| most people won't do it: the operational complexity is brutal.
| You need cert provisioning, rotation, a CA you actually trust,
| and suddenly your "just give the agent an API key" problem has
| become a PKI problem.
|
| What I find more interesting is the host-scoping approach
| hardsnow mentioned upthread. Even without mTLS, if the proxy
| only injects credentials for requests matching specific
| host+path patterns, you've at least bounded the blast radius. A
| prompt-injected agent can abuse the credentials it has access
| to, sure, but it can't exfiltrate them to arbitrary endpoints.
| That's not perfect security but it's a meaningful improvement
| over "agent has raw Stripe key in an env var."
|
| The real gap nobody's addressing yet is request-level
| authorization. Credential injection solves "who are you" but
| not "should you be doing this." An agent with scoped GitHub
| access can still force-push to main.
| ipince wrote:
| This seems to prevent your keys from being exfiltrated through
| prompt injection. But if your agent could've been prompt injected
| into giving out keys, then it can also be prompt injected into
| using the services it has (fake) keys for to the attacker's
| benefit.
___________________________________________________________________
(page generated 2026-03-12 23:00 UTC)