There's a philosophical question embedded in every autonomous AI agent: if software can make its own decisions about which APIs to call, should it ever actually handle the passwords?
OneCLI, an open-source project that emerged on March 11, argues the answer is a hard no. The tool positions itself as a transparent proxy that sits between AI agents and the outside world, intercepting their HTTP requests, injecting the real credentials just long enough to authenticate, then scrubbing them from memory. The agent itself never sees the secret. According to its GitHub repository, the project attracted 568 stars within days of launch—a modest but telling signal that developers are actively wrestling with this exact problem.
The premise is deceptively straightforward. AI agents that run behind OneCLI's gateway use placeholder tokens in their code. When they reach out to an external API, the proxy catches the request, matches it against a set of configured policies, swaps in the actual credential at runtime, and forwards everything along. It's credential delivery as a just-in-time service, packaged into a single Docker container that bundles a Rust-based gateway, a Next.js dashboard, and an encrypted vault.
Whether this becomes the standard approach—or simply validates the concept for larger players—remains to be seen. But the speed with which it gained traction suggests the problem is real.
How the Proxy Actually Works
OneCLI operates as an HTTPS proxy. Agents point their HTTPS_PROXY environment variable at the gateway, which listens on port 10255. No code changes. The gateway performs man-in-the-middle interception on HTTPS traffic—decrypting it with a locally generated certificate authority that the agent is configured to trust, then re-encrypting and forwarding the request with live credentials injected inline. A web-based dashboard on port 10254 lets developers manage agents, credentials, and the host-and-path policies that govern which secrets get injected where.
Secrets are stored using AES-256-GCM encryption and only decrypted at the moment a request needs them. By default, the project uses PGlite—a WebAssembly-packaged version of Postgres that runs embedded within the container—though teams can swap in their own PostgreSQL instance if they prefer. Authentication is either single-user local mode or Google OAuth for team setups. A Node.js SDK helps configure containerized agents programmatically; SDKs for Rust, Python, Go, Java, Ruby, and .NET are listed as in development.
The pitch is that OneCLI works with any agent framework capable of setting an HTTPS proxy. The documentation name-checks OpenClaw, NanoClaw, IronClaw, Dify, n8n, and OpenHands, among others. Setup, according to the docs, is a one-liner Docker command: docker run --pull always -p 10254:10254 -p 10255:10255 -v onecli-data:/app/data ghcr.io/onecli/onecli.
That kind of simplicity is intentional. The target audience appears to be developers self-hosting AI workflows who want security without building a multi-service secrets infrastructure.
Under the Hood
The architecture combines per-agent access tokens with host and path matching policies. When an agent makes a request, the gateway checks its scoped token via Proxy-Authorization, matches the destination host and path, determines which credential applies, and decrypts the secret only for that specific transaction. An audit trail logs every API call—what was accessed, which agent made the request, and when.
The GitHub repository shows two contributors: Jonathan Fishner ("johnnyfish") and Guy Ben-Aharon ("guyb1"). The codebase is roughly 66% TypeScript (the dashboard) and 28% Rust (the gateway), with the remainder consisting of Dockerfile, CSS, JavaScript, and Shell scripts. Fishner, who previously built ChartDB—an open-source database diagramming tool that gained some attention in developer communities—posted OneCLI to Show HN in mid-March and followed up with a launch thread on r/selfhosted shortly after. In that post, he outlined a near-term roadmap: more granular credential scoping, expanded audit logging, and human-in-the-loop approval workflows for sensitive operations.
The roadmap items are telling. They reflect the kinds of questions early adopters immediately asked: What about credential rotation? What's the blast radius if the gateway itself is compromised? Can tokens be scoped per-tool rather than per-agent?
Early Reception and Comparisons
The rapid accumulation of GitHub stars and forks—modest by viral open-source standards, but significant for a niche security tool—suggests OneCLI hit a nerve. Discussions in the r/selfhosted thread quickly drew comparisons to HashiCorp Vault, Infisical, and DreamFactory. One commenter asked whether OneCLI supports credential rotation workflows beyond simple fetch-at-runtime. The maintainers acknowledged it as a future priority.
Timing matters here. Over recent weeks, multiple developers have posted about building "credential brokers" or "secretless" architectures for self-hosted AI agents—evidence of active experimentation in a space where established enterprise tools weren't designed for transparent HTTP injection. OneCLI's documentation explicitly argues for what it calls a "CLI over MCP" philosophy, claiming that centralized gateway-based auth reduces context bloat and token costs compared to the Model Context Protocol.
Whether that argument holds up under scrutiny from security teams remains an open question.
The Broader Landscape
OneCLI is entering a space where traditional secret management platforms are being retrofitted—sometimes awkwardly—for AI use cases. HashiCorp Vault has published validated architecture patterns for AI agent identity, emphasizing dynamic secrets and token exchange. Akeyless, an enterprise secrets platform, announced its SecretlessAI approach last summer, focusing on identity-first workflows. Infisical, another open-source contender, now markets a feature called "Agent Sentinel" to govern AI agent access. Doppler, widely used for CLI-based secret delivery, typically injects environment variables at process startup rather than inline during HTTP requests.
A handful of newer projects target the AI-specific niche more directly. Tools like 1Claw, Agentic Vault, and a Rust crate called aivault all position themselves around policy-enforced proxy runtimes tailored for AI workflows. OneCLI differentiates by bundling the vault, proxy, and dashboard into a single container with minimal setup friction—simplicity aimed squarely at developers who want to secure agents without standing up complex infrastructure.
It's a crowded landscape, but perhaps not yet a mature one.
What Comes Next
The project carries an Apache-2.0 license and is developed in the open. The changelog shows rapid iteration in the immediate aftermath of launch: an initial release establishing the core feature set, followed by several patch releases addressing setup flows, Docker ARM builds, and shell keygen compatibility. The maintainers have flagged plans for service-specific credential templates, finer-grained scoping rules, and expanded language SDKs.
OneCLI's landing page mentions "local KMS or OneCLI Cloud" as potential future credential storage options, though as of mid-March, details about a cloud offering or key management service integrations haven't been documented publicly. What is clear is that the proxy model resonates—at least with a subset of developers navigating the strange new challenge of giving autonomous software the keys to the kingdom without actually handing over the keys.
Whether OneCLI becomes the standard or simply proves the concept for better-resourced competitors, it's addressing a friction point that won't go away. AI agents are making more decisions. Those decisions increasingly involve calling APIs that require authentication. And the trust boundary around credentials—once a relatively straightforward problem—has become anything but.
For now, OneCLI offers one answer. The community will decide if it's the right one.
