OneCLI: Open-Source Credential Gateway for AI Agents

OneCLI is an open-source credential gateway designed to decouple sensitive API keys from AI agents. By acting as an intermediary, OneCLI allows agents to use placeholder keys while the gateway injects the actual credentials into outbound requests, ensuring that raw secrets are never exposed to the AI model or the agent's environment.

Architecture and Technical Implementation

OneCLI utilizes a three-tier architecture to manage and inject secrets without exposing them to the client agent.

Rust Gateway

The core of the system is a high-performance HTTP gateway written in Rust. This gateway intercepts outbound requests from AI agents. Agents authenticate with the gateway using access tokens via Proxy-Authorization headers. The gateway then performs a "swap" operation: it identifies the placeholder key (e.g., FAKE_KEY) in the request and replaces it with the decrypted REAL_KEY before forwarding the request to the destination service.

Web Dashboard and API

A Next.js application provides the management interface for administrators to define agents, store secrets, and configure permissions. This dashboard serves as the API that the Rust gateway queries to determine which specific credentials should be injected for a given request based on host and path patterns.

Secret Store

Credentials are stored using AES-256-GCM encryption at rest. Secrets are only decrypted at the moment of the request, minimizing the window of exposure. OneCLI also supports integration with external password managers like Bitwarden to enable on-demand injection without storing secrets on the OneCLI server itself.

Key Features

OneCLI provides several mechanisms to secure AI agent workflows:

• Transparent Injection: Agents make standard HTTP calls; the gateway handles the authentication logic invisibly.
• Pattern-Based Routing: Secrets are routed to specific API endpoints using host and path matching.
• Scoped Permissions: Each agent is assigned its own access token, allowing administrators to restrict which secrets a specific agent can access.
• Flexible Deployment: The system supports a single-user local mode for developers and a Google OAuth-enabled mode for team environments.

Community Perspectives and Technical Trade-offs

Discussion among developers highlights both the utility of the "credential broker" pattern and the inherent trade-offs of introducing a proxy.

The Credential Broker Pattern

Some users compare OneCLI's approach to traditional database client architectures, where the client never touches the disk but sends requests to a server that owns the credentials. This design is praised for preventing the leak of high-value secrets if an agent's sandbox is compromised, as the leaked "fake" token would be useless to an attacker without access to the gateway.

Potential Limitations and Enhancements

Community feedback suggests several areas for evolution:

• Dynamic Credentials: While OneCLI handles static credentials, users have suggested adding support for OAuth Client Credentials flows, where the gateway would handle the "OAuth dance" to retrieve access tokens dynamically.
• Reliability: Suggestions include implementing request retries and short-circuiting for better fault tolerance.
• Architectural Concerns: Some critics argue that the system simply trades one key for another (the agent's access token for the API key) and that mature SSO standards like OAuth, SAML, and OIDC may be more appropriate for enterprises already using single sign-on.

Comparative Landscape

Other tools mentioned in the community as alternatives or complementary solutions include Infisical, Varlock, and HashiCorp Vault, emphasizing a growing trend toward centralized secret management for AI-driven automation.