Dev ToolsArticle OneCLI injects real credentials at the proxy, so a prompt-injected agent has nothing worth stealing.
Lenn Voss Environment variables were a fine place for API keys back when the only thing reading your shell environment was you. That assumption quietly died the day coding agents started running arbitrary commands in your terminal. Last August's Nx "s1ngularity" supply-chain attack made the new reality concrete: a malicious postinstall script enlisted locally installed AI CLIs to hunt for credentials, harvested 2,349 secrets from over a thousand developer machines, and the follow-on wave used those stolen tokens to flip nearly 11,000 private repos public. The agent on your laptop is now the most credential-rich, most manipulable process you run.
OneCLI, an Apache-2.0 project that just hit the Hacker News front page, is one of the cleaner answers to this I've seen — not because it's novel, but because it commits fully to a principle the rest of the tooling ecosystem only flirts with: the agent should never hold a real secret at all.
Placeholder keys and a proxy in the middle #
The architecture is three pieces: a Rust HTTP gateway, a Next.js dashboard backed by Postgres for managing agents and permissions, and an AES-256-GCM-encrypted secret store (which can also pull from Bitwarden or 1Password instead of holding keys itself). You store your real credentials once. Your agent gets two things: a scoped access token it presents via Proxy-Authorization
, and placeholder keys — fake strings shaped like the real ones.
The agent then makes normal HTTP calls, routed through the gateway with HTTPS_PROXY
and an injected CA cert. The gateway matches each outbound request by host and path, checks that this particular agent is allowed to hit that service, swaps the placeholder for the real credential decrypted at request time, and forwards it. Rules can block operations, rate-limit sensitive actions, and scope access per agent, with an audit trail of what every agent actually did.
Getting it running is a docker compose up
(or curl -fsSL https://onecli.sh/install | sh
), dashboard on one port, gateway on another. The whole thing is self-hosted; nothing leaves your infrastructure.
Why this beats what you're probably doing instead #
The interesting comparison isn't OneCLI versus nothing — it's OneCLI versus the mitigations developers actually reach for, and each of them leaks in a way this pattern doesn't.
op run
and its cousins from 1Password inject secrets at process start, which keeps them out of dotfiles — but the real key still lands in the process environment the agent inherits. One env
command, one prompt-injected "debug this by printing your configuration," and it's in the context window and potentially in a transcript on someone else's server. HashiCorp Vault's dynamic secrets are the gold standard for services, but they assume the application integrates with Vault; a coding agent driving curl
doesn't. Sandboxes attack the adjacent problem: Anthropic's open-source sandbox runtime mediates network access through allowlisting proxies, which stops exfiltration to attacker-controlled hosts but doesn't remove the credentials from the environment in the first place.
The egress-injection pattern inverts all of this. The secret never exists in the agent's environment, memory, shell history, or context window — so there's nothing to print, nothing to accidentally commit, nothing for a s1ngularity-style scanner to find. A leaked placeholder is worthless off-network. A leaked proxy token is revocable in one click and only ever granted access to a scoped slice of services. That's a categorically better failure mode than "rotate the AWS root key and pray."
What it doesn't solve, and what the HN crowd got right #
The skeptics in the launch thread landed some real punches, and it's worth being precise about which ones connect. "You're just trading one key for another" is true but misses the point — a scoped, revocable, auditable capability is exactly what you want to trade a long-lived bearer token for. That's not a flaw; that's the design.
The critique that does land: OneCLI can't stop an agent from misusing access it legitimately has. If your agent is allowed to call the Stripe API and gets prompt-injected into issuing refunds, the gateway will faithfully inject the credential and forward the request. This is the confused-deputy problem, and no credential gateway solves it — the rate limits and operation blocking help at the margins, but semantic misuse of granted permissions is a policy problem the industry hasn't cracked for agents yet.
There's also an honest trust-shift to acknowledge. You're routing your HTTPS traffic through a young open-source service and concentrating every credential you own into one box. The Rust gateway hasn't had a third-party audit that I can find, and the Docker-plus-Postgres-plus-dashboard footprint is a lot of machinery for a solo developer running one agent on a laptop. The crown jewels now live behind the gateway's own auth — get that wrong and you've built a very convenient one-stop shop for an attacker.
The pattern will outlive the tool #
Here's my read: the architecture is right, and it's where the space is heading regardless of whether OneCLI specifically wins. Credential injection at the egress proxy is the same move the database world made decades ago with connection poolers holding credentials on behalf of untrusted clients — and the crowded field (Infisical, agent-vault, varlock, and a half-dozen others circling the same problem) tells you the demand is real. I'd bet money that 1Password and friends ship native agent-gateway modes within a year, at which point a standalone tool needs a reason to exist beyond being first.
If you're running a fleet of agents — CI bots, background Claude Code sessions, anything autonomous with real API access — deploy something in this category now, and OneCLI is a credible, inspectable place to start. Treat it as a serious mitigation for credential theft, not a security boundary against credential misuse, and keep the blast-radius thinking you'd apply to any secret store. If you're one developer with one agent, the calculus is thinner: start by getting keys out of .env
files and your agent's reach, even crudely, because the s1ngularity playbook is public and the next campaign is a matter of when.
Either way, stop letting your agent read your keys. That era's over.
Sources & further reading #
[OneCLI - Open-source credential gateway with a built-in vault](https://github.com/onecli/onecli)— github.com -
[Show HN: OneCLI - OSS credential gateway that keeps secrets out of AI agents](https://news.ycombinator.com/item?id=49023427)— news.ycombinator.com -
[Credential and Policy Layer for AI Agents - OneCLI Docs](https://onecli.sh/docs)— onecli.sh -
[The Nx s1ngularity Attack: Inside the Credential Leak](https://blog.gitguardian.com/the-nx-s1ngularity-attack-inside-the-credential-leak/)— blog.gitguardian.com -
[Anthropic sandbox runtime (srt)](https://github.com/anthropic-experimental/sandbox-runtime)— github.com
[Lenn Voss](https://sourcefeed.dev/u/lennart_voss)· Cloud & Infrastructure Writer
Lenn writes about cloud platforms, Kubernetes internals, and the infrastructure decisions that quietly make or break engineering organizations. Based in Berlin's vibrant tech scene, they have a talent for turning dense platform-engineering topics into prose that people actually finish reading.
Discussion 0 #
No comments yet
Be the first to weigh in.