Bitwarden's Agent Access SDK Now Integrates with OneCLI

Bitwarden just launched their Agent Access SDK, and OneCLI is one of the first integrations. Their team wrote about it in detail on their blog, and I want to share what this means from our side.

Why this matters

Most agent credential setups today work like this: you store your API keys somewhere (env vars, a secrets manager, a password vault), the agent fetches the key, and from that point on the key lives in the agent's context. Extractable. Loggable. Leakable via prompt injection.

Secrets managers solve storage. They do not solve what happens after the agent has the key.

Bitwarden's Agent Access SDK takes a different approach. Every credential request goes through a human-in-the-loop approval flow. The agent asks for access, the user approves it through the Bitwarden CLI, and the credential gets injected without the agent ever seeing the raw value in plaintext.

Where OneCLI fits

OneCLI sits between the agent and the external services it calls. It intercepts API requests, pulls the credential from Bitwarden's vault via their SDK, injects it into the outgoing request, and forwards it. The agent never holds the key. The LLM provider never sees it.

This is the same gateway architecture we use with every credential source, but Bitwarden adds something we did not have before: a mature approval workflow backed by enterprise key management. When Bitwarden's user approves a credential request, OneCLI handles the injection and policy enforcement on every subsequent API call.

# Configure Bitwarden as credential source
onecli provider add bitwarden \
  --vault-url "https://vault.bitwarden.com"

# Rate-limit API calls per service
onecli rules create \
  --name "Stripe rate limit" \
  --host-pattern "api.stripe.com" \
  --action rate_limit \
  --rate-limit 10 \
  --rate-window 1h

# Configure Bitwarden as credential source
onecli provider add bitwarden \
  --vault-url "https://vault.bitwarden.com"

# Rate-limit API calls per service
onecli rules create \
  --name "Stripe rate limit" \
  --host-pattern "api.stripe.com" \
  --action rate_limit \
  --rate-limit 10 \
  --rate-window 1h

What users get

With the Bitwarden + OneCLI integration:

• Credentials stay in Bitwarden's encrypted vault until explicitly approved by a human.
• OneCLI proxies every API call the agent makes, injecting credentials at the network layer.
• Rate limiting and policy enforcement apply to every proxied request.
• The agent and the LLM provider never see raw API keys, tokens, or passwords.
• Audit trail covers both the approval (Bitwarden side) and the usage (OneCLI side).

This works with any agent framework. If your agent makes HTTP calls to external services, OneCLI can proxy them regardless of whether you are running NanoClaw, OpenClaw, or something custom.

Two layers, one flow

Bitwarden handles the vault, encryption, and approval. OneCLI handles the proxying, injection, and policy enforcement. The agent just makes API calls. It does not know or care where the credentials come from.

That separation matters. The credential source and the credential gateway are different problems. Bitwarden has spent years building enterprise key management. We have spent our time building the runtime enforcement layer. Combining them gives you both without either project trying to be something it is not.

Try it

Both projects are open source. The integration is live in alpha.

• Bitwarden's blog post: bitwarden.com/blog/introducing-agent-access-sdk
• Bitwarden Agent Access SDK: github.com/bitwarden/agent-access
• OneCLI: github.com/onecli/onecli

If you are running agents in production and thinking about how to handle credentials safely, this is worth looking at. The combination of human-in-the-loop approval with runtime policy enforcement is the closest thing to a real trust layer we have seen.