OneCLI: A Credential Isolation Gateway That Lets AI Agents Use Keys Without Seeing Them

A Misalignment in Agent Security

As AI Agents increasingly take over automated tasks—calling APIs, accessing databases, operating external services—a long-overlooked question has surfaced: Should Agents directly hold real credentials?

In traditional software architecture, credential management already has mature practices—tools like HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault form the foundation of enterprise-grade secret management infrastructure. But the emergence of AI Agents breaks the underlying assumptions of this system: traditional application code is deterministic, and developers have full control over where credentials flow. AI Agents, however, behave non-deterministically—large language models may output credential contents into logs during reasoning, return them to users, or even have them maliciously extracted through Prompt Injection attacks. This fundamental difference creates a systemic security gap in traditional secret management solutions when applied to Agent scenarios.

In most current practices, we stuff API Keys and access tokens directly into prompts, environment variables, or tool configurations. This approach seems convenient but actually places the permission boundary in the wrong position. Once an Agent can read the raw secret, it means the model itself, the model's context, and even logs and caches can all become channels for credential leakage. Prompt Injection is one of the core security threats facing LLM applications today—attackers embed malicious instructions in inputs to trick models into performing unintended actions. OWASP lists it as the top risk in its LLM Application Security Top 10. When credentials like API Keys exist directly within an Agent's context window, attackers can use indirect injection (for example, embedding instructions in web pages or documents the Agent reads) to exfiltrate credential contents. Since 2023, multiple public cases have demonstrated that even safety-aligned commercial models cannot fully withstand carefully crafted injection attacks.

OneCLI was born precisely to address this misalignment. According to a quick review by Bilibili creator wanikly, its core proposition is restrained yet hits the nail on the head: Agents should be able to use keys, but they shouldn't be able to see them.

What OneCLI Actually Does

OneCLI is an open-source credential injection gateway specifically designed to inject real credentials on behalf of AI Agents. Its position is critical—it sits between the Agent and external services, acting as a trusted intermediary layer.

This "trusted intermediary" pattern has deep theoretical roots in security architecture. It is essentially an implementation of a Reference Monitor—all access to protected resources must pass through an unbypassable, verifiable mediator. This concept was first proposed by James Anderson in 1972 and later became the cornerstone of operating system security kernel design. In modern microservice architectures, the Sidecar Proxy pattern in Service Meshes (such as Envoy) adopts a similar approach: applications don't handle mTLS certificates directly; instead, the proxy layer transparently handles authentication and encryption. OneCLI migrates this pattern to the AI Agent domain, with its innovation lying in adapting it to the specific threat model of LLMs.

According to the official documentation, its core action can be broken down into three steps:

1. Real credentials are stored in OneCLI first: Keys no longer scatter across the Agent's runtime environment but are centrally managed within the gateway and stored encrypted.
2. The Agent only receives fake keys: What the model sees are always placeholders or pseudo-credentials that cannot be reverse-engineered to reveal real values.
3. The gateway injects on demand: When a service request passes through the gateway, OneCLI matches based on the target host and path, decrypts the real credentials, injects them, and forwards the request to the external service.

In other words, throughout the entire process, keys never reach the Agent's hands. The Agent continues sending what it considers "normal" requests, while all credential substitution is completed inside the trusted gateway.

Key Design: Separating "Can Use" from "Can See"

The most commendable aspect of OneCLI isn't simply "storing keys somewhere else." Changing the storage location doesn't solve the fundamental problem—as long as the Agent can ultimately read the plaintext, the risk persists.

Its real highlight is: completely separating "can use" from "can see."

• The Agent has the ability to "use": It can initiate calls to external services, and tasks proceed as normal.
• The Agent doesn't have the permission to "see": It never touches reusable raw credentials.

This separation restores the trust boundary to the correct position. The Principle of Least Exposure it embodies is a core component of Zero Trust Architecture. The fundamental assumption of Zero Trust is "never trust, always verify"—no entity within the network should be trusted by default. NIST SP 800-207 defines the reference model for Zero Trust Architecture in detail. In Agent scenarios, this means that even if an Agent runs in a trusted internal environment, it should not hold credentials beyond what the current task requires.

Compared to the traditional approach of stuffing real keys into prompts, environment variables, or tool configurations, OneCLI's architecture better adheres to the Principle of Least Exposure. Each Agent can also hold independent access tokens, effectively implementing identity-based Micro-segmentation. This ensures that when a single Agent is compromised, credentials don't spread laterally, further enabling fine-grained identity differentiation.

Don't Treat the Gateway as a Universal Security Switch

That said, it's equally important to view any tool rationally. OneCLI's proven boundaries are clear:

• The project's positioning (credential injection gateway);
• Encrypted storage;
• Matching rules based on host and path;
• Independent access tokens for each Agent.

But the problems it cannot solve for you are equally explicit:

• It can't prove that your deployment environment itself is reliable—if the machine hosting the gateway is compromised, all assumptions collapse;
• It can't replace the Principle of Least Privilege—the permission scope of the credentials themselves still needs to be narrowed by you;
• It can't replace key rotation and auditing—credential lifecycle management remains an operational responsibility.

Key Rotation and Audit are indispensable parts of the credential security lifecycle. Key rotation means periodically replacing credentials to limit the impact window after a leak—AWS IAM best practices recommend rotating access keys every 90 days. Auditing requires recording the time, source, and target of each credential usage to reconstruct attack paths during post-incident forensics. Compliance frameworks like SOC 2 Type II have explicit requirements for this. As a gateway, OneCLI actually provides a natural enforcement point for both capabilities—all credential usage passes through the gateway, so in theory, rotation triggers and access log recording could be centrally implemented here. However, these capabilities require additional engineering effort and are not available out of the box.

In other words, OneCLI is one link in a security architecture, not a "one-click fix-all" universal switch. Treating the gateway as the entirety of your security assurance is itself a new form of misalignment.

Why This Is the Step Agent Security Should Take First

Overall, OneCLI addresses a problem in Agent security that truly deserves priority attention: Don't let the model touch reusable raw credentials.

As Agents are deployed at scale, the model's context window, logs, and caches are continuously expanding the attack surface. Once raw credentials enter the model's visible range, leakage shifts from "whether it will happen" to "when it will happen." OneCLI moves this line of defense forward to the stage where credentials never enter the model at all—this is closer to the root of the problem than post-hoc auditing and rotation.

If you're building automated Agents that call external services, this kind of "credential isolation gateway" is worth including in your technology selection considerations. Of course, as the original review emphasizes—don't follow hype blindly, verify your sources, and before making a selection, be sure to go back to the project repository to confirm its specific implementation and security boundaries.

Key Takeaways