Agent credential brokers in 2026: Authsome vs Agent Vault vs Clawvisor vs OneCLI

There are now four open-source credential brokers worth knowing about if you're putting AI agents into production. Each one accepts the same premise: the agent shouldn't hold real credentials. Each one solves the same core mechanic: proxy intercepts outbound HTTP, substitutes the placeholder for the real key, forwards. Where they diverge is the shape of the team they're built for, the operational footprint, and which adjacent problems they try to solve.

This is the post I wished existed when I was picking one six months ago. I'll cover the four, then a decision tree at the end.

The four

• Authsome (github.com/agentrhq/authsome) - Local-first Python CLI plus a daemon, designed for the personal laptop and the single-user dev box. 44 bundled OAuth2 + API-key providers, automatic refresh, device-code flow for headless.
• Agent Vault - Infisical's Go binary, designed to run on a separate host from the agent. Multi-tenant, has a web UI on port 14321, MITM proxy on 14322.
• Clawvisor (github.com/clawvisor/clawvisor) - Authorization gateway with task-scoped human approval. Hosted-first, self-host via Docker. Uses an LLM to verify each request matches the approved task scope.
• OneCLI - Rust HTTP gateway plus a Next.js dashboard. AES-256-GCM at rest, PostgreSQL backend, Bitwarden integration for pull-on-demand secrets.

All four are open source. All four put themselves on the outbound HTTP path between the agent and the destination API. From the agent's point of view, all four behave the same way: the agent makes a normal call, the broker injects the right header, the request goes out.

Side by side

The cell counts hide as much as they show. What matters is the shape of each tool. Below is the longer take on each.

Authsome

Built for: developers running agents on their own laptop, on shared dev boxes, or on small SSH servers. Single user, multiple identities per provider, no SaaS dependency.

Strengths: 44 bundled providers means you can uvx authsome login github and the OAuth app, the scopes, the refresh logic, and the audit metadata are all configured. Headless flow (device code) works out of the box for any SSH session. Refresh is fully automatic for OAuth2 and the broker handles refresh-token rotation. The CLI surface is small: login, list, get, export, run, revoke.

Weaknesses: not designed for multi-user deployment. There's no concept of "team admin sets a policy that all users inherit". If you have 50 engineers, you'd run 50 authsome instances. The local-first stance is a feature for individuals and a limitation for orgs.

Pick it if: you're a solo developer, an indie hacker, or a small team where everyone runs agents on their own machines. Personal laptop, side projects, dev environments, SSH boxes you administer.

Agent Vault

Built for: teams shipping AI agents to production where the agent runs in a container or VM and the credential vault runs in a sibling container or separate host. Multi-tenant, multi-vault, oriented around service deployments.

Strengths: explicit "don't run this on the same host as your agent" architecture, which is the right opinion for production. Has a web UI and CLI both. Supports Docker-native deployment with docker run -p 14321:14321 .... Ergonomic for multi-agent multi-credential setups. The TypeScript SDK lets an orchestrator mint short-lived tokens for sandboxed agents, which is exactly what you want for E2B-style ephemeral compute.

Weaknesses: bring-your-own credential storage means it doesn't have the "log in to GitHub in one command" ergonomics of Authsome. The substitution pattern is dummy strings like __anthropic_api_key__ that the agent passes through, which is more setup than a provider definition. No automatic OAuth refresh; it's an API key vault, not an OAuth client.

Pick it if: you're running agents in production on infrastructure separate from your laptop. Multi-tenant team, ephemeral sandbox use cases, anything where the broker is a service rather than a tool.

Clawvisor

Built for: scenarios where the authorization layer matters as much as the credential layer. A user grants the agent a task scope ("read my emails, but ask before sending"), and Clawvisor enforces that scope on every outbound call. Includes LLM-powered intent verification.

Strengths: task-scoped consent is a real innovation. Most brokers treat "the agent has the credential" as binary; Clawvisor treats it as scoped per task with a time bound and a purpose statement. The LLM-verification feature (each outbound call's parameters are checked against the task's stated purpose) is genuinely useful for high-stakes agents.

Weaknesses: hosted-first means most users will adopt the SaaS, with the open-source self-host as the secondary path. The LLM verification adds latency to every call (it's an extra LLM round-trip). The connected-services model (Gmail, GitHub, Slack, etc.) is curated, not extensible the way Authsome's JSON provider definitions are.

Pick it if: your agents do high-blast-radius things (email send, payments, deploys) and you want per-task human approval baked into the path, not bolted on. Also pick it if you're already running on the hosted plan and self-hosting isn't a constraint.

OneCLI

Built for: teams that want the multi-tenant gateway architecture (like Agent Vault) but with a richer dashboard and Bitwarden-style "fetch on demand" credential model. Two-mode: single-user no-login for local, or Google OAuth for teams.

Strengths: solid Rust gateway, well-engineered MITM, AES-256-GCM at rest. The Bitwarden integration is a clean way to avoid storing secrets in the broker at all - the broker calls Bitwarden for each request and forwards the response. Two-container Docker setup is straightforward.

Weaknesses: PostgreSQL dependency is heavy for the "personal laptop" use case (you have to run a database for one user). Like Agent Vault, no automatic OAuth refresh and no bundled provider definitions; bring your own credentials. The dashboard is the primary interface, which is more clicking than typing if you live in a terminal.

Pick it if: you're already running Postgres, you want a UI-first credential broker, and you'd like to integrate Bitwarden or another password manager as the source of truth.

The decision tree

Are agents running on YOUR machine, with YOUR identities?
├── Yes
│   └── Authsome.
│       Locally, no setup overhead, bundled providers,
│       per-directory identity selection.
│
└── No, they're running on infrastructure I deploy
    └── Do you need per-task human approval flows?
        ├── Yes
        │   └── Clawvisor.
        │       Task-scoped consent + LLM verification is
        │       its differentiator.
        │
        └── No, just credential injection
            └── Do you already have Postgres in your stack?
                ├── Yes
                │   └── OneCLI.
                │       UI-first, Bitwarden integration,
                │       Rust gateway is fast.
                │
                └── No
                    └── Agent Vault.
                        Embedded storage, simpler footprint,
                        TypeScript SDK for orchestration.

This is the "if you have no other constraints" path. Real picks depend on whether you've already invested in one ecosystem, your team's deployment culture, and whether the differentiators (OAuth refresh, task scope, Bitwarden, ephemeral sandbox) matter to you.

A combination that actually works

The four tools aren't mutually exclusive. A pattern I've seen work:

• Authsome on developer laptops for everyday agent work. Each developer manages their own credentials. Per-directory identities. Headless via device code on SSH boxes.
• Agent Vault or OneCLI in production for the deployed agent fleet. Vault tokens issued by your CI to runtime workloads. The production agents never hold real credentials.
• Clawvisor as an optional approval layer in front of high-stakes operations. If an agent wants to do something with real money or real customer data, the request gets approval-routed through Clawvisor.

You don't need all three. Most teams pick one tier and grow into the next. The point is that the category (broker between agent and provider) is solidifying. Specific implementations will keep changing.

What I think is undecided

Three open questions in the space:

Who owns refresh. OAuth2 refresh is annoying. It needs to happen somewhere. The broker is the natural place, but only Authsome handles it automatically across providers. The others assume you bring already-fresh tokens. As more agents land in production, this gap will close, probably by the others adopting Authsome's bundled-provider model.

Whether the proxy needs to be on the agent host. The "deploy on a separate host" stance (Agent Vault) is good security hygiene against a compromised agent host. The "run on the same machine" stance (Authsome) is better DX. For the single-user laptop case the second wins. For a team deployment the first wins. The right answer for the in-between (small team, shared dev boxes) is contested.

Whether brokering is enough. Clawvisor's bet is that no, you also need authorization (per-task scopes, human approval, LLM verification of intent). The other three's bet is that brokering plus standard scope controls is enough for most real workloads. We don't know yet who's right because we don't have enough horror stories from the agent era to calibrate on.

Summary

Pick the broker that matches the shape of your team and where your agents run. Don't pick the broker on a feature checklist alone; the operational footprint matters more than the column count. For most readers of this blog (developers running agents on their own laptop), the answer is Authsome. For production fleets, it's Agent Vault or OneCLI. For high-stakes approval flows, layer in Clawvisor.

Whichever you pick, the meta-point holds: don't put real credentials in the agent process. The category exists because that anti-pattern is bad in 2026, and the brokers above are the four serious answers to it.

Priyansh Khodiyar

Maintainer

Works on authsome and the agentr.dev tooling.