OneCLI

Open-source credential gateway for AI agents: store once, inject anywhere, keys are never visible to the agent

Agent identification 凭证网关

https://onecli.sh/

Visit Website

In-depth Report

OneCLI is an open source credential gateway for AI Agents incubated in the Y Combinator Summer 2026 batch and has over 2,800 stars on GitHub. It solves one of the most difficult security problems in the Agent era: the Agent needs to call external APIs, but directly handing over the key to the Agent is equivalent to sticking the safe password on the door. OneCLI's solution is to insert a transparent proxy gateway between the Agent and the target service. The real credentials are encrypted and stored in the gateway. The Agent only holds the placeholder token, and the gateway completes the replacement of "fake key → real key" at the moment the request is sent. At the time of writing, the project has been downloaded more than 320,000 times and has been selected as the default credential tier by NanoClaw.
OneCLI was co-founded by Guy Ben Aharon and Jonathan Fishner. The two founders’ backgrounds focus on security engineering: Guy was the first engineer at Argon (later acquired by Aqua Security), and Jonathan worked on zero-trust network access at Axis Security (later acquired by HPE), both coming from Israeli military intelligence. Previously, the two worked together on the open source database tool ChartDB (20,000+ stars on GitHub). The motivation for the creation came from personal experience: when they were building the Agent orchestration layer for ChartDB, they could not find a secure way to distribute credentials to autonomous Agents. Team research found that almost all teams using Agent either hard-coded the API Key into the .env file or improvised the agent solution. In July 2026, the project was officially open sourced and appeared on Hacker News "Show HN", quickly gaining community attention. Y Combinator publicly promoted OneCLI through its official X account on July 23, 2026, defining it as an infrastructure layer that “allows AI Agents to do real work without storing passwords.” OneCLI uses the Apache-2.0 license and is still in the early rapid iteration stage (v1.42.0+), but companies such as Docker, MindsDB, Zoho, Coralogix, etc. have begun to use it.
OneCLI's core workflow is divided into three steps. In the first step, the operator stores the real API credentials into OneCLI's encrypted vault; in the second step, a placeholder key (such as FAKE_KEY) is issued to each Agent, and the Agent uses these fake keys when making HTTP requests; in the third step, the OneCLI gateway intercepts the request, completes the decryption and replacement of the credentials before the request leaves the gateway according to the host and path matching rules, and finally forwards the request carrying the real credentials to the target service. During the entire process, the Agent never comes into contact with the real key at any point. On the technology stack, OneCLI consists of three layers. The high-performance HTTP gateway written in Rust is responsible for intercepting outbound requests and injecting credentials. The Agent carries the access token through the Proxy-Authorization header to complete identity authentication. The web dashboard built by Next.js is used to manage Agents, keys, and permissions. The gateway dynamically parses which credentials should be injected for each request through the API exposed by the dashboard. The credential storage layer uses AES-256-GCM encryption. The key is only decrypted when a request occurs. After decryption, it is strictly matched according to the host and path patterns and then injected in the form of request headers or URL parameters. Deployment is extremely simple and can be started with just one command: docker run -d --name onecli -p 10254:10254 -p 10255:10255 -v onecli-data:/app/data ghcr.io/onecli/onecli After startup, visit http://localhost:10254 to create an Agent, add a key, and then point the Agent's HTTP proxy to localhost:10255. The Agent framework does not require any code modification - it can be accessed as long as it supports setting the HTTPS_PROXY environment variable. This includes Claude Code, Codex, Cursor, Cline, and mainstream frameworks such as OpenClaw, NanoClaw, LangChain, and CrewAI. OneCLI also provides the onecli CLI command line tool, which allows Agents to autonomously manage their own identities and keys through Shell commands - the Agent Orchestrator can create new Agents, assign credentials, and configure rules in a script without manual operation of the dashboard.Local mode supports single-user login-free operation without configuring NEXTAUTH_SECRET. Team Collaboration can enable Google OAuth authentication. All environment variables have reasonable default values, which are automatically generated when SECRET_ENCRYPTION_KEY is not set.
OneCLI is currently completely free and open source (Apache-2.0). The free tier supports up to 2 Agents and no credit card is required. The project team is currently a startup company incubated by Y Combinator and has not yet announced a specific pricing plan for the official commercial version. Predictable business paths include multi-agent support for enterprise editions, advanced policy engines, organization-wide identity provider integration, and managed cloud services.
The overall community response to OneCLI has been positive, especially within the Agent security community. Some developers in the Hacker News discussion thread pointed out that solutions such as credential agent solutions are not new (such as Fly.io’s Tokenizer, BuzzFeed SSO agent, etc.), but implementations tailored for AI Agent scenarios have indeed lowered the threshold for implementation. Some developers also shared plans to use HashiCorp Vault with scripts to achieve similar effects, but admitted that OneCLI's "out-of-the-box" experience is better. The demo video promoted by Y Combinator's official account shows the complete process of Claude Code calling the GitHub API through the OneCLI gateway - the Agent only holds FAKE_KEY throughout the process, and the real PAT is injected by the gateway at the moment the request is made. The evaluations from the Chinese community are mainly constructive. Some developers on the blog park have conducted actual tests on OneCLI and believe that its "transformation cost is close to zero." However, for teams that are already running production environment Agents, special attention needs to be paid to the gateway's HTTPS certificate management and network isolation. Others commented that centralized management of credentials also means centralized risk - if the OneCLI server is compromised, the attacker will have an extremely valuable target.
OneCLI has received positive press from multiple authoritative sources. Y Combinator's public promotion is seen as a signal to the industry that the accelerator believes that agent security infrastructure is an independent track worthy of focus. The Agent Times, World AI 360 and other media have reported on it, and it is generally believed that OneCLI's design pattern - isolating credentials outside of Agent memory - is expected to become a standard security layer for Agent architecture. From the perspective of the competitive product landscape, the main competition OneCLI faces comes from two types of solutions. One type is traditional key management tools (HashiCorp Vault, AWS Secrets Manager, 1Password). These tools solve the storage problem, but do not solve the injection problem - there is still a risk of leakage after the Agent obtains the key. The other type is the emerging Agent framework (such as MCP protocol), but the MCP tool definition consumes the Agent's context window, and each MCP server handles authentication independently, lacking unified credential management. OneCLI's differentiated positioning is to find a blank space between these two types of solutions: solving both storage and injection without consuming the Agent's context window.
OneCLI is not without risks. The core problem lies in the MITM CA model - the gateway needs to hold the CA key to issue certificates for arbitrary targets, which means that on a shared or multi-tenant machine, a privilege escalation vulnerability can expose the CA key. Deployment requires extra care with Docker container isolation and network namespaces. Although the project iterates quickly and the community grows rapidly, it is still in the v1.x stage, and the API and configuration format may change with version upgrades. For enterprises that require long-term stability guarantees, it is recommended to use OneCLI as an evaluable solution for prototype verification, while retaining traditional credential management as a fallback solution. Another issue that cannot be ignored is centralized trust - centralizing credentials in one gateway management improves operation and maintenance efficiency, but it also means that the gateway itself becomes a single point of blasting target. Operators need to perform additional hardening of the gateway, including but not limited to: restricting dashboard access IPs, enabling external storage of audit logs, and regularly rotating encryption keys.
OneCLI is best suited for both types of teams. The first category is development and operation teams that are running coding agents (Claude Code, Codex, Cursor). These agents need to frequently call external APIs such as GitHub, Slack, Jira, etc., and each line of output may contain keys. The second category is a team building a multi-Agent collaboration system that needs to uniformly manage and audit the API access of all Agents. Scenarios that are not suitable include: Agents that only run in completely isolated networks, teams that already have mature HashiCorp Vault deployments and are unwilling to add additional infrastructure, and benchmark enterprises that require strict compliance audits (such as SOC 2 Type II). For the latter, it is recommended to wait until OneCLI completes a third-party security audit before considering production-level deployment.
OneCLI accurately hits a real pain point in the popularization of AI Agents - credential security - and provides an engineering elegant and practical solution. Its core judgment is that "Agent should not even touch the key" and implements this principle to the architectural level. During the critical transition period for Agents from toys to productivity, OneCLI is expected to become the security standard for Agent infrastructure. But its true value cannot be fully verified until a third-party audit is completed and stable version 2.0 is released.

User Reviews

2hyqkek

—

Gave OneCLI a try and it completely solved Claude Code's key management problem. I used to stuff all kinds of API keys into .env; now one docker command spins it up and the Agent never sees the real keys. Massive boost in peace of mind.

珊瑚37

—

Some people compare it to HashiCorp Vault, but I think the positioning is different. Vault is too heavyweight — for a small team doing Agent development, OneCLI's one-click deployment is genuinely hassle-free.

RGonzales_Plus

—

An HTTP gateway written in Rust — performance is rock solid. I measured the latency: after adding the OneCLI proxy there's almost no perceptible overhead, way faster than fetching keys from Vault on every call.

王月珍

—

Saw YC's official account promoting OneCLI and looked into it. The idea is genuinely good — it's not about blocking the Agent from calling APIs, but making sure the Agent never even touches the keys. I fully endorse this design philosophy.

FrankHicksIII

—

Someone on Hacker News questioned whether this is just an auth proxy — and yes, similar solutions have existed before. But it's optimized specifically for Agent scenarios and works out of the box, and that's enough.

AnnGray

—

Deployment is simple — a single docker run gets it going. But there's one gotcha: you have to handle the self-signed certificate issue yourself. If the Agent container doesn't trust the CA cert, HTTPS traffic won't get through.

流年472

—

OneCLI's approach reminds me of a real case I read about: a security lead at a big company authorized an Agent, and it went on a rampage deleting emails. If there had been a gateway policy layer back then, maybe only a few emails would have been deleted instead of all of them.

8j0wz

—

Tried OneCLI together with NanoClaw and the experience was silky smooth. The Agent has no idea the keys even exist, so leaking them is impossible. For security-sensitive teams, this combo is worth a shot.

HaroldStephensIII

—

Already integrated OneCLI into my Cursor workflow, with the GitHub, OpenAI and Slack APIs all configured. Setup was intuitive — the web panel manages Agents and keys, and the permission granularity is fine enough.

AshleyOrtiz

—

My only concern is centralization risk. All keys go through the OneCLI gateway, and if that gateway gets compromised, everything is gone. The encrypted storage is well done, but I'm still a bit wary of a single point of failure in production.

康明_1

—

Compared several credential management tools, and OneCLI is the friendliest for individual developers. Authsome is zero-infrastructure but has no auditing; Vault is too heavy. OneCLI hits the sweet middle tier.

Isabella.Morgan

—

The Bitwarden integration is a sweet touch — keys don't need to live in OneCLI's local database, they're pulled straight from Bitwarden. Migration cost is very low for teams already on a password manager.

KeithStewartJr

—

Took a look at the code — the Rust gateway layer is solidly written. AES-256-GCM encryption at rest, decrypted only at request time, no obvious weakness in the design. Looking forward to them adding approval workflows and monitoring rules.

Jacqueline.Adams

—

OneCLI can prevent key leakage, but it can't stop an authorized Agent from going rogue. If an Agent has permission to call the Stripe API, it can charge at will. That problem still needs approval workflows — a gateway alone isn't enough.

Laura_MooreIII

—

Been following it since Show HN, and it's at 2800+ stars now — growth is genuinely fast. Shows this pain point really hits home for a lot of people. Apache-2.0 license plus YC backing, worth watching.

7wnel5q

—

An unexpected bonus after deploying OneCLI: the audit logs are fantastic. Before, which APIs an Agent called and when was completely invisible; now it's all laid out clearly, and troubleshooting is way more efficient.

EHughesIII

—

The Gateway + Dashboard + encrypted storage trio makes for a very clean architecture. The Rust gateway's performance is a non-issue and the Next.js panel is smooth to use. The docs are a bit too terse in places though — newcomers may need some extra fumbling.

smallpeacock198

—

Followed that hands-on article on Cnblogs step by step, local deployment took under ten minutes. Called the GitHub API with Claude Code and only ever saw FAKE_KEY the whole time. This transparent substitution honestly feels like black magic.

Brian.Martinez168

—

For someone like me doing AI Agent development, OneCLI solves the most annoying problem — having to check before every demo whether the .env file got accidentally committed. No more worrying about that now.

Web_3Wave

—

It's still in the 1.x stage, so the API may change fairly often. If you're using it in production, pin the version, otherwise a config format change after an upgrade will be a headache.

purplepanda996

—

Plugged OneCLI into our team's multi-Agent system, with three projects each isolating their own keys and policies. This project-level isolation design is really practical — different clients' data never gets mixed up.

许桂强

—

I just want to know when it will support 1Password integration. Only having Bitwarden is a bit limiting. Plenty of people on my team use 1Password, hope they add it.

DianeMitchell_Plus60

—

One Docker command and it was up, really convenient. But when I tried a Node.js Agent, the HTTP_PROXY environment variable isn't well supported on older Node versions — you need 22+.

LoganRodriguez_20234

—

Thumbs up. I ran an experiment before where a plain prompt injection attack tricked the OpenAI key out of environment variables. After deploying OneCLI I tried the same attack again — the Agent simply doesn't hold the key, so there's nothing to leak.

OMpow

—

The policy engine design is solid — you can configure separate allow/block rules and rate limits for each Agent. This goes much deeper than simple key management; it's essentially permission control at the network layer.

云烟737

—

The PostgreSQL dependency is a barrier. Having to install a database just to run it feels a bit overkill for solo devs. The good news is they mentioned a PGlite embedded version so you won't need a standalone database — looking forward to official support.

AfraRomkes

—

Chatted with our team's DevOps guy. He thinks OneCLI's MITM proxy approach carries compliance risks for domestic secure-IT environments. Self-signed certificates aren't necessarily accepted in MLPS audits — worth keeping an eye on this point.

WLopezX736

—

That analysis piece from The Agent Times was well written and nailed the key issue: OneCLI solves key leakage, but it can't solve Agents abusing granted authorization. Still, the flaws don't outweigh the merits — at least the most critical problem got solved first.

goldendog167

—

Opened an Issue asking about approval workflows, and the developer replied quickly, saying it's already on the roadmap. It's a project backed by Y Combinator, so the iteration pace shouldn't be slow.

星辰_14

—

After reading the take on CLI and Agents that karpathy retweeted, OneCLI's design really does fit the thesis. The CLI is the native interface for Agents, and doing credential management at the CLI layer is more fundamental and more universal than doing it at the application layer.