Running agents without losing my keys: a month with authsome | by Priyansh Khodiyar | May, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Running agents without losing my keys: a month with authsome

Priyansh Khodiyar

13 min read·<br>6 days ago

Listen

Share

Press enter or click to view image in full size

I run a small handful of agents on my laptop and a shared box. One drafts release notes from GitHub PRs. One scrapes SaaS dashboards for a Friday digest. A third runs over SSH on a CI box and pokes our staging APIs after every deploy. All three need credentials. Until recently, my “credential management” was a `.env` file at the project root, a second one I never committed, and a third one in `~/.zshrc` that I told myself was temporary in 2024.<br>This post is what happened when I replaced all of that with authsome- https://github.com/agentrhq/authsome, an open-source credential broker that runs locally on my machine.<br>I’m not going to argue you should switch. I’m going to walk through what I actually do with it, what surprised me, and what I’d warn the next person about.<br>Most of the rough edges aren’t deal-breakers, but several of them aren’t documented as loudly as they should be either.<br>Before<br>Three problems pushed me into looking for something:<br>The first was that I’d lost track of which key was which. I had four OpenAI keys at one point -personal, team, a Stripe-paid test account, and one I’d generated on a flight and forgot to delete. None of them were named anything meaningful in their `.env` lines.<br>When the OpenAI dashboard started flagging “key seen in commit”, I had to bisect through three repos and a Notion page to find which one.<br>The second was that my GitHub agent kept hitting `Bad credentials` once a quarter or so. GitHub fine-print OAuth tokens have a sliding-window expiry that I had not internalized.<br>Every time, the fix was the same: log in to GitHub manually, click through the SSO redirect, copy a fresh `ghp_…`, paste it into the right `.env`, restart the agent. Forty-five seconds of work and an hour of frustration before I realized what had broken.<br>The third was that I started running agents under Claude Code — https://claude.com/claude-code and Cursor, and both of them inherit my shell environment by default.<br>Which meant every agent had access to every key, including the ones it didn’t need. A coding agent doesn’t need my Stripe key. It just had it because zsh had it.<br>I looked at three categories of tool:<br>- A SaaS secrets manager. Vault, Doppler, 1Password Secrets Automation. All of them store values; none of them run the OAuth flow. I’d still be the one logging in to GitHub every quarter, just with an extra round-trip to a cloud service that costs money and adds a network dependency. Pass.<br>- The OS keychain. I already use it. It’s a `dict[str, str]`. No expiry, no refresh, no notion of “this key belongs to this service”. Insufficient on its own.<br>- Roll my own. I have rolled my own before. I’ve also rolled my own OAuth client. I won’t do either again on my own time.<br>Authsome got my attention because it was the only thing in the “agent credentials” space that did the OAuth dance plus the storage plus the runtime injection, and ran entirely on my machine.<br>The pitch read more honestly than the SaaS pitches did - it has an explicit “what authsome is not” page, which is unusual for a project that wants you to adopt it.<br>What it actually is<br>Authsome is a Python CLI plus a local daemon. The daemon runs on `127.0.0.1:7998` and owns three things: an encrypted SQLite vault under `~/.authsome/profiles//store.db`, a small HTTP API that the CLI talks to, and a transparent HTTP proxy that you can run a subprocess underneath.<br>The proxy intercepts outbound HTTP requests from whatever you put behind it, matches the destination host against a registered provider, and injects the right `Authorization` header. The subprocess never sees the real secret.<br>The CLI surface is small enough to memorize:<br>uvx authsome login github # OAuth or API-key flow<br>uvx authsome list # what’s connected<br>uvx authsome get github # metadata, secret redacted<br>uvx authsome export github # KEY=value lines for the shell<br>uvx authsome run — python agent.py # run under the proxy<br>uvx authsome scan — import # pick up keys from .env files<br>uvx authsome revoke github # nuke the connection<br>Behind that surface there’s a layered architecture with five layers — vault, auth, identity, policy, audit — though only three of those are actually implemented in v1.<br>The design doc admits this openly; identity and policy are aspirational. I’ll come back to what that means in practice.<br>Setting it up<br>I’ll be honest about the friction first. `uvx authsome` works out of the box on a Mac if you already have `uv` installed. The first invocation initializes `~/.authsome/` and generates a master key. That’s seamless.<br>The first OAuth login is **not** seamless. Here’s what actually happened the first time I ran `uvx...