We Couldn't Push to Our Own Repo
There's a particular flavor of irony that hits different when you're building an authentication platform for AI agents and your own AI agent can't authenticate.
That's the story of TapAuth's first week.
The Setup
We're a small team — and when I say small, I mean our engineering is done by an AI agent called Claudex. Claudex writes features, creates pull requests, handles rebases, and iterates on review feedback. I review every PR. Every line ships with human approval. That's not just a workflow preference — it's the product thesis.
But before we could ship anything, Claudex needed to push code to GitHub.
Simple, right? Just generate a personal access token, paste it into the environment, and go. Except that token gives full repo access. Read, write, delete, admin — the works. For an AI agent that should only be creating branches and opening PRs, that's like giving a contractor the keys to every building in the city because they need to paint one room.
The Credentials Problem
So we tried GitHub Apps instead. Better scoping, right? Sure — if you enjoy a 47-step setup process involving JWTs, installation tokens, private keys stored as environment variables, and a token refresh dance that would make OAuth 1.0 blush.
We got it working. It took a full day. And every time the token expired (every hour), we had to handle the refresh. Our agent needed a python3 ~/.secrets/github-app-token.py script that generates a fresh JWT, exchanges it for an installation token, and updates the git remote URL. Before every. Single. Push.
We were building an auth platform and our own agent's auth was held together with shell scripts and prayer.
The Lightbulb Moment
Here's what we realized: every team building with AI agents is going through this. Not just with GitHub — with every service their agents need to touch.
Need your agent to read Google Calendar? Here's a client ID, client secret, redirect URI, consent screen configuration, OAuth scope selection, token storage, and refresh token rotation. Need it to send a Slack message? Different OAuth flow, different scopes, different token format. Need it to check Linear tickets? API key in an environment variable that never expires and has full access.
The pattern is always the same: too much access, too much setup, or both.
What We Actually Wanted
What we wanted was dead simple:
- Agent says "I need to push to the tapauth/tapauth repo"
- A human (me) gets a notification: "Claudex wants write access to tapauth/tapauth. Approve?"
- I tap approve, select the specific permissions, set a time limit
- Agent gets a scoped, time-limited token
- Token expires. No cleanup needed.
That's it. No API keys to rotate. No secrets in environment variables. No shell scripts. The human stays in control, and the agent gets exactly what it needs — nothing more, nothing less.
So We Built It
TapAuth is the tool we needed on day one. One API call from the agent's side. One tap from the human's side. The agent gets a scoped OAuth token for the service it needs, and the human sees exactly what they're granting.
We call it the trust layer. Because as AI agents become more capable and more autonomous, the question isn't whether they can do things — it's whether they should, and who decides.
Right now, the answer to "who decides" is usually "whoever set up the API key three months ago and forgot about it." That's not good enough.
The Meta Part
Yes, we're aware of how meta this is. We built an auth layer for AI agents, using AI agents, because our AI agents couldn't authenticate properly. The snake is eating its own tail and honestly, the tail tastes pretty good.
Claudex now uses TapAuth to get the tokens it needs. When it needs to push a branch, it requests access. I get a link. I approve it on my phone. Claudex pushes. The grant expires after the session.
It's boring now. That's the point. Auth should be boring. It should just work, with the right person in control, and no secrets sitting in plaintext on a filesystem somewhere.
What's Next
If you're building with AI agents — and in 2026, who isn't — you've probably hit some version of this problem. Too many API keys. Too much access. No visibility into what your agents are actually doing with the credentials you gave them.
We're building TapAuth to fix that. Not just for us, but for every developer who's tired of the three-API-keys-before-lunch dance.
Check out the docs or try the API. One call. One tap. That's it.