OneCLI: Managing AI Agent Secrets from Scratch
Instead of the agent holding the key, OneCLI acts as a network gateway. The agent sends a request with a placeholder, and the gateway swaps it for the real credential at the network layer before forwarding it to the service. This means the agent never actually "knows" the secret.
Deployment and Integration
Since the proxy is written in Rust and packaged as a Docker container, getting it running is straightforward. It supports any tool that can configure an HTTPS_PROXY, making it compatible with a wide range of AI workflows:
- Compatible Tools: Claude Code, Cursor, OpenClaw, or any custom LLM agent.
- Secret Sourcing: You can store secrets directly in the vault (AES-256-GCM encrypted) or sync them in real-time from 1Password or Bitwarden.
- Control Layer: You can set up human-in-the-loop approvals. Even if an agent decides it needs to perform a sensitive action, the request is blocked at the proxy level until a human clears it.
Practical AI Workflow Benefits
The real-world value here is preventing "permission creep." Coding agents are notorious for trying to find creative ways to elevate their own permissions to finish a task. By moving the authorization to a deterministic proxy, you stop relying on the model's "behavior" and start relying on hard network policies.
For example, if you're using a deployment agent, you can allow it to trigger a build but require manual approval before it can actually merge a PR or push to production, regardless of what the agent's internal logic thinks.
Technical Trade-offs
- Performance: The Rust core keeps latency low, but it is still an extra hop in the network path.
- Scope: It doesn't stop an agent from misusing a permission it actually has. If you give the agent broad access to a database via the proxy, it can still delete tables. Tight scoping of policies is mandatory.
For anyone building a production-grade LLM agent, this is a much safer architecture than the standard "env file" approach.
https://onecli.sh/