Credentials for AI agents: what a gateway protects and what remains open
OneCLI keeps real keys away from the model, but it does not make every authorized action safe. Its architecture helps separate custody, permission, execution and auditing.
On July 24, 2026, OneCLI offered a concrete answer to a problem that appears when an assistant stops drafting and starts acting: how can it call GitHub, Stripe or a cloud service without receiving the real key? The project inserts a gateway that stores the credential, examines the request and adds the secret after the request has left the agent process. The design reduces one class of exposure, but it does not make the agent trustworthy or every operation harmless. Any similar product can be assessed through four separate questions: who holds the secret, who may request its use, what the service permits and what evidence remains.
The primary architecture documentation describes an HTTP proxy written in Rust. An agent receives its own token and sends an ordinary request through the gateway. Before touching a secret, the system checks identity, destination and policy; if the operation is allowed, it finds a credential by service, host and path, decrypts it and injects it into a header or URL parameter. The response returns to the agent, but the real key need not enter its prompt, environment file or memory.
Holding a key is not the same as authorizing an action
This distinction prevents the most common error in discussions of agent vaults. A credential answers, “Which identity authenticates this request?” A policy answers, “May this identity perform this operation on this resource now?” An agent may know nothing about a Stripe key and still be authorized to create a charge through the gateway. If it misreads an instruction, repeats a loop or accepts malicious content, the secret stays hidden while the charge may still go through.
The vendor says so in a scope-and-limitations account published on March 16, 2026: OneCLI aims to prevent credential theft, not misuse of legitimate access. The page warns that an authorized API request will be forwarded even when the agent hallucinates the operation. It also lists what remains outside the boundary: traffic that bypasses the proxy, a fully compromised host and damaging actions that need no API key, such as deleting local files or using an existing authenticated session.
That admission supports a testable threat model. First define the asset: the key, money, data or repository. Then list the routes: copying the secret, using it through the broker, bypassing the broker or acting over another channel. Finally assign one control to each route. A vault limits copying; a method-and-path rule constrains use; the network forces traffic through the proxy; isolation restricts the host; and human approval protects high-consequence operations. If a row has no control, the product name does not cover it by implication.
Prompt injection changes the calculation
An agent processes text from people, webpages, tickets and tool results. Some of that material can contain hostile instructions. OWASP defines prompt injection as input that changes model behavior or output in unintended ways and identifies an indirect form in which the instruction arrives inside an external source. Possible consequences include sensitive-data disclosure, unauthorized function use and command execution in connected systems.
Keeping keys hidden reduces what a model can reveal literally. It does not eliminate the possibility that the model uses a valid capability for an attacker's benefit. OWASP therefore recommends least privilege, functions mediated by code and human approval for high-risk actions. Those controls sit outside the model's probabilistic reasoning. A sentence in a prompt can guide; a denial at the proxy or API decides.
The practical test treats the agent as an untrusted client. Test requests to the right host with a forbidden method, near-matching paths, unexpected parameters, redirects, subdomains, alternative destination encodings and direct egress that skips the proxy. Also test what happens when no policy rule matches. In security, “no rule” needs an explicit outcome. If it means allow, every configuration gap expands access.
Four boundaries that must remain distinct
The first boundary is custody. The public OneCLI repository declares AES-256-GCM encryption at rest and decryption while a request is prepared. That protects stored material against some database or disk access, but the encryption key and proxy memory become critical assets. A team needs to know where the master key lives, who can read it, how it is rotated, which copies exist and what happens when the service is unavailable.
The second boundary is identity. Sharing one token among several agents prevents attribution and forces administrators to revoke them as a group. Each process needs its own identity, and development, test and production environments need separate credentials and rules. NIST defines least privilege as restricting each user or process to the minimum resources and authorizations required for its function. Here, granting “GitHub” is too broad: access should be narrowed by repository, operation and resource whenever the provider supports it.
The third boundary is decision. OneCLI's current documentation describes organization rules and per-agent grants evaluated before credential injection, with blocking, rate limits and approval as possible actions. Ordering matters: if the engine takes the first match, a broad permissive rule placed early can swallow a later exception. A policy inventory should record priority, owner, rationale and tests demonstrating both permitted and denied behavior.
The fourth boundary is execution. Proxy policy does not replace permissions at the provider. If one key can administer an entire account, an error in the gateway still leaves an enormous blast radius. Whenever possible, the destination service should issue separate credentials, OAuth scopes or restricted IAM roles. The gateway adds a decision; it should not become the only decision.
The proxy becomes sensitive infrastructure too
OneCLI intercepts HTTPS so it can inspect destinations and inject credentials. That requires installing trust in the gateway's certificate and operating the cryptographic chain correctly. This is not inherently unsafe, but it moves the boundary: whoever controls the proxy or its certificate authority may observe or alter traffic that previously went straight to the service. Teams should isolate that infrastructure, restrict administration, protect logs and document certificate renewal and revocation.
Forcing traffic through the gateway is a separate control. The limitations page explains that OneCLI cannot intercept connections when an agent can reach the network outside the proxy. Containers or clusters can enforce egress rules; a general-purpose host needs an equivalent network control. The meaningful test is not that a configured request uses the proxy. It is that an unconfigured request cannot reach the Internet by another route.
Availability matters as well. Centralized rotation and revocation simplify operations but concentrate dependency. Before putting a gateway in front of a critical process, decide whether a failure closes or opens access, how long responses may be cached, how the service is recovered and which emergency operations exist. Failing open preserves continuity by disabling the control at the moment visibility is weakest.
Audit the effect, not merely the calls
A useful record answers who requested what, when, against which destination, under which rule and with what result. It should not contain the credential or sensitive request bodies by default. It also needs integrity, retention and actionable alerts: one hundred denials may indicate a loop, an attack or a broken rule. Seeing a request list after an incident is not the same as detecting it in time.
Evaluation can be organized as a test matrix. For every agent, list required operations, forbidden operations and operations that need approval. Run positive and negative cases, rotate a key, revoke a token, attempt to bypass the proxy and inspect the log. Then repeat with a hostile instruction hidden inside a webpage or issue. Success means more than preventing the secret from appearing: an action that policy was meant to stop must not complete either.
This is how to judge OneCLI — or any agent vault — without confusing one valuable property with complete security. Keeping a key outside the model reduces exposure and simplifies revocation. System security additionally depends on narrow provider permissions, deterministic policy, controlled network egress, host isolation, proportionate approvals and protected records. The transferable skill is to turn every promise into a boundary and attack it from both sides: verify what it blocks and, above all, discover what an authorized agent can still do.
This article was produced with artificial intelligence under human editorial oversight.
