Why agents need this
Agents run outside interactive sessions: in CI, over SSH, in cron jobs, in background workers, or in parallel pipelines. They need API access that survives without a human in the loop. Hardcoded environment tokens leak or go stale. Building auth flow logic, token storage, refresh handling, and per-provider config into every project forces you to rebuild the same plumbing every time. Authsome acts as the credential broker agents call at runtime.- No credential sprawl. One encrypted store, every provider, every agent, one place.
- No SaaS dependency. Self-host the daemon; credentials stay under your control.
- No browser required at runtime. You set up once using a browser or terminal prompt. After that, agents run headlessly.
How it works
The CLI is the agent’s interface. Set up once, then inject fresh credentials whenever a tool runs.authsome run).
Start here
Quickstart
Install authsome, log in to your first provider, and run an agent in under 5 minutes.
CLI reference
Every command, every flag, every exit code.
Architecture
The five layers (identity, policy, vault, auth, audit) and the proxy that ties them together.
Custom providers
Add any OAuth2 or API-key service that authsome doesn’t ship out of the box.
Pick your path
Log in with OAuth
Browser-based PKCE flow for services like GitHub, Google, Linear.
Use API keys
Secure browser bridge for OpenAI, Anthropic, and similar providers.
Run agents with the proxy
Inject auth headers without exposing raw secrets to the child process.
Headless setup
Authenticate over SSH or in CI with the device code flow.
Authsome compared
| authsome | Hardcoded env tokens | DIY | |
|---|---|---|---|
| Automatic token refresh | Yes | No | Build it |
| OAuth2 + API keys | Yes | No | Build it |
| Runtime headless use | Yes | Yes | Varies |
| Local, no SaaS dependency | Yes | Yes | Yes |
| Built-in providers, zero config | Yes | No | No |
| Multi-account per provider | Yes | No | Build it |