Skip to main content
Most people using agents today either hardcode API keys in environment variables or pull them from a secrets manager. Tools like HashiCorp Vault and AWS Secrets Manager solve storage, but they don’t solve what happens when the agent actually uses a credential.

​
The gap

Here’s the typical flow with a traditional secrets manager:
  1. Agent starts up and fetches an API key from the vault
  2. The key is now in the agent’s memory
  3. The agent makes requests using that key directly
  4. The vault is out of the picture
The vault protected the secret at rest. But once the agent has it, the key is in the agent’s memory, potentially in its logs, and extractable via prompt injection. The vault has no visibility into how the key is being used, no ability to enforce rate limits, and no way to revoke access mid-session without rotating the entire credential. This was fine when the only consumers of secrets were deterministic applications with predictable behavior. It’s not fine when the consumer is a language model that might decide to do something unexpected.

​
What the Agent Vault does differently

OneCLI’s Agent Vault sits between the agent and the services it calls. Your credentials still live wherever you keep them today (in OneCLI’s encrypted store, in Bitwarden, wherever). But instead of handing the raw key to the agent, the vault proxies the request:
  1. Agent makes a normal HTTP request through the gateway
  2. The gateway matches the request by host and path
  3. Credentials are decrypted, injected into the request headers
  4. The request is forwarded to the target service
  5. The response passes back to the agent
The agent never sees the key. Never holds it. Never logs it. If the agent is compromised via prompt injection, the attacker gets a proxy URL and an agent-scoped access token, not your raw API keys.

​
Deterministic safety, not prompt-based hope

There’s a deeper problem with giving agents direct access to credentials. Even if the agent itself isn’t compromised, it’s still a language model, non-deterministic by nature. You can write “never delete emails without my approval” in your system prompt, but that’s a suggestion the model interprets, not a rule it’s bound by. The agent might misinterpret the instruction. It might be too eager to help and take an action it thought you wanted. It might get manipulated through prompt injection into doing something it was told not to. OneCLI’s Agent Vault moves the security boundary out of the agent’s context and into a layer the agent can’t reach. Rules are enforced at the gateway: deterministically, on every request, regardless of what the agent was told or tricked into doing. A rate limit of 3 deletions per hour isn’t something an agent can talk its way around. A blocked endpoint is blocked, period. This is the fundamental difference between prompt-based safety (“please don’t do that”) and infrastructure-level enforcement (“you can’t do that”). One depends on the model behaving as expected. The other doesn’t.

​
Policies, not just proxying

If all the Agent Vault did was swap keys, it would be useful but limited. The real value is the policy layer on top. You can set rules that control what agents are allowed to do with the services they have access to:
  • Block specific operations entirely (e.g., no DELETE requests to your email API)
  • Rate limit sensitive operations (e.g., max 3 email deletions per hour)
  • Scope rules to specific agents or apply them globally
Consider this scenario: a director of AI alignment at Meta gave an agent access to her email and explicitly told it not to take any action without her approval. The agent started mass-deleting emails anyway. She couldn’t stop it from her phone and had to physically run to her computer to kill the process. If there had been a rate limit of 3 email deletions per hour, the damage would have been 3 emails, not an entire inbox. The agent would have hit the limit, the user would have been notified, and it would have been a minor annoyance instead of a cautionary tale.

​
Comparison

CapabilityTraditional secrets managerOneCLI Agent Vault
Encrypted storage at restYesYes
Agent never holds raw keysNoYes
Per-request credential injectionNoYes
Block specific operationsNoYes
Rate limiting per agentNoYes
Audit log of every requestNoYes
Works with existing credential sourcesN/AYes (Bitwarden, more coming)

​
The tradeoff changes

The value of agents comes from giving them access to real systems and real data. An agent that can’t touch anything is just a chatbot. But an agent that can touch everything, with no policies, no rate limits, no approval flows, is a liability. The Agent Vault changes what you’re comfortable letting an agent do. Instead of choosing between “full access” and “no access,” you get fine-grained controls: which services, which operations, how often, and for which agents. Even for a single user running agents on their own machine, the ability to say “you can access my email but you can only delete 3 messages per hour” makes the difference between cautious experimentation and confident deployment.