The security question is larger than where a key lives
Putting an API key in an environment variable is a reasonable starting point for one local script. It gets much harder to reason about when several agents, services, and automation jobs can all make external calls.
At that point, the important question is not only “can this agent read the secret?” It is “which outbound request is this identity allowed to make with it?”
OneCLI is an open-source project that makes that design trade-off visible. Its README describes a credential gateway: an agent sends a request with a placeholder credential, and the gateway matches host and path rules before injecting the real credential for the outbound request. The repository describes a Rust gateway, a web dashboard, and encrypted credential storage.
I have not tested or run OneCLI. This is a reading of its public repository and documentation, not a security assessment or a deployment recommendation.
What a gateway can improve
A common credential distribution model is simple: give each agent a secret through .env, a configuration file, or a hosted secret manager. That can work, but it makes revocation, rotation, and audit increasingly fragmented as the number of agents grows.
A gateway creates a policy point in the request path. In principle, it gives a team one place to decide:
- which agent identity may call which external destination;
- how a credential is selected and rotated;
- what gets logged and redacted;
- how access is revoked when an agent or task changes.
That is why the interesting part is not merely hiding a raw key from model context. It is making outbound authority explicit.
The new boundary also needs review
Moving credential injection into a proxy does not remove trust; it concentrates it. The proxy, its rule engine, its logs, and its access tokens become security-critical.
Before adopting a system in this category, I would review host/path matching behavior, redirect handling, token scope, log redaction, network isolation, and the lifecycle of decrypted values. OneCLI’s vault integration documentation describes a Bitwarden fallback and a 60-second in-memory cache; those are documented project claims that I have not independently verified.
Who should care
Teams operating multiple agents that call many third-party APIs may benefit from treating external calls as policy-controlled capabilities. A single local script may not: adding a gateway introduces another component to secure and operate.
The project is Apache-2.0 licensed, and its gateway source tree is a sensible place to begin source review. Do not run its quick-start or install commands just because a README offers them; validate the deployment and threat model for your environment first.
Top comments (0)