OneCLI offers a credential firewall for AI agents
The open-source project places a gateway between AI agents and external APIs so models never receive the real keys. It centralizes permissions, rotation and access logs.
OneCLI is an open-source project designed for an increasingly common problem: AI agents need to query external services, but doing so typically requires access keys that should not end up in their instructions, memory or logs. Its approach is to place a gateway between the agent and the APIs, allowing the agent to make the call without knowing the real credential.
The idea is simple, but it addresses a specific risk. An agent that uses tools may access databases, payment platforms, cloud storage or language model services. If it is given an API key directly, that key may be exposed in a conversation, a debugging log, a misconfigured tool or a prompt injection attack: malicious instructions embedded in the data processed by the model in an attempt to make it act against its intended rules.
A fake key for the agent, the real one for the API
The OneCLI repository describes a credential substitution mechanism. The administrator stores the real key in the system and gives the agent a placeholder, such as FAKE_KEY. When the agent makes an HTTP request through the gateway, OneCLI identifies the destination, retrieves the corresponding credential and inserts it into the outbound request. The agent never sees the real key.
This resembles the role of a traditional secrets manager, but adapted for software that makes decisions and executes calls autonomously. Rather than distributing the same key across several processes, each agent can have its own access token and permissions limited to specific services, domains or API routes.
The main advantage is not merely hiding a password. It also makes it possible to revoke an agent's access without changing the rest of the integrations, rotate a compromised key from a single location and review which agent used each service. For a company testing several internal assistants, that control keeps credentials from being scattered across scripts, configuration files and development environments.
A Rust-based local gateway
The published architecture combines an HTTP gateway written in Rust with a Next.js web dashboard and a PostgreSQL database. Credentials are stored encrypted with AES-256-GCM, a widely used authenticated encryption standard, and decrypted when the request is prepared. The system can inject them as HTTP headers or URL parameters, depending on what the external service requires.
OneCLI includes a local mode for a single user and a Google authentication option for teams. It also announces Bitwarden integration, allowing credentials to be retrieved on demand from a password manager rather than remaining stored on the OneCLI server.
The project is distributed under the Apache-2.0 license, which allows it to be used, modified and deployed in commercial environments with few restrictions. Its quick installation starts the dashboard, gateway and PostgreSQL through Docker, a convenient way to test it, although it does not replace a security review before putting it in front of critical systems.
Centralizing secrets also concentrates risk
The proposal addresses a genuine weakness in agents, but shifts trust to the gateway. If the OneCLI server, its encryption key or the accounts with access to the dashboard are compromised, an attacker would gain a highly valuable point from which to manage credentials. Centralization improves operational control, but requires especially strong protection for this new perimeter.
The gateway's HTTPS traffic interception also deserves attention. To insert credentials into encrypted connections, this type of proxy must sit between the parties communicating and be configured correctly. It is a common technique in enterprise tools, but adds certificate, auditing and network-control requirements that may be excessive for small projects.
OneCLI's usefulness will depend on whether teams adopt a clear least-privilege discipline: a support agent should not inherit the access of a finance agent, nor should a local test reuse production keys. The tool provides a layer for enforcing that separation; it cannot decide on its own which permissions are reasonable or prevent an authorized agent from carrying out an erroneous action.
This article was produced with artificial intelligence under human editorial oversight.