Credential issuance for AI agents
When you ask an AI to build something, that work has to live somewhere. Developers keep theirs on GitHub — but GitHub expects you to create and manage digital keys, and that's where most people give up.
This bridge handles the keys for you. Connect your GitHub account once. After that, every time your AI needs to save work, it gets a fresh key that opens only the one door it needs — and the key expires in an hour.
That's actually safer than what most professionals do. The common shortcut is one master key that opens everything and lasts for years. Here, there's no master key to lose — and if you ever want out, one click disconnects everything.
You never see a key. You never touch a key. You just ask, and it saves to GitHub.
git-repo-auth-mcphttps://gitauth.klappy.dev/mcp
Live demonstration at 60× speed — a real token lives one hour.
The problem, on the record
How it works
Add the MCP server to your client and log in with GitHub. The connection binds to your installation of the app — you choose which repos it covers. Then your agent calls github_token at need.
Your Cloudflare Worker signs a 10-minute JWT with your App's private key — which lives in worker secrets and never transits chat, disk, or transcript.
GitHub exchanges the JWT for a one-hour installation token, scoped exactly as requested. The agent uses it, and the clock does the rest.
No coding tool required
Claude, ChatGPT, any frontier model — the plain conversation, even from a phone. Append to a repo, cut a branch, open a pull request, mid-conversation. No tool switch, no lost context.
Write straight to main if that's how you roll. Or run strict protected branches with required CI, and let the assistant bridge you into that setup. We don't determine your flow. We let you.
Blank repository to branch protection and a working CI pipeline, set up entirely inside a chat — with Opus, and again with ChatGPT. Not their coding tools. The chat. It works.
Read this before you trust it
Most credential tools bury their threat model. This one leads with it — because the people who should deploy this are exactly the people who will ask.
Each connection is bound by OAuth to one user, one installation — a minted token physically cannot reach another account's repositories; GitHub enforces the walls. The worker stores no GitHub tokens, ever: its only state is its own hashed grants and your quota accounting.
The recommended grant excludes Administration — but Workflows write means a token holder can modify CI, and CI runs with the repo's own credentials. That path is accepted, not eliminated: every CI change lands in PRs and audit logs under the bot identity. Don't want the trade? Drop the Workflows permission.
You never hand over a key — connecting means installing a GitHub App on repos you choose. If this bridge were compromised, exposure is minting over installed scopes, within the app's ceiling — never your account or credentials. Your kill switch is unilateral: uninstall the app and minting ends instantly. Want zero shared trust? Self-host the same code.
$ Reversal is two clicks. The riskiest credential in this system is the one it replaces.
The deal, stated plainly
Tokens live one hour, and a working agent typically mints two — a read-only token to look (the secure default), then a write token to act — so every tier budgets two tokens per agent and the cards below count agents. The mix is unpoliced: two reads, two writes, a read and a write, all the same. Every tier is one human, no seats — the team is your agents, and the per-agent price falls as you climb. Every response shows remaining and window_reset_at, so the wall is never a surprise.
$0
one-time trial — no card$1
per month — $24 billed every 2 years$5
per month — $60 billed yearly$25
per month$100
per month$ Re-requesting the same scope while a token is live is always free, and a mint GitHub refuses never charges — you pay only for tokens you receive. Prices and quotas render from the governance document the server enforces. Prefer your own keys? Self-host for $0, forever — same code.
Setup
Use it: add https://gitauth.klappy.dev/mcp to your MCP client and follow the GitHub login. Operate it: the script here is the self-host runbook — same code, your app, your worker. Details in the README.
Keep your existing PAT until github_token mints its first real token. Retiring the fallback before validating the replacement is how lockouts happen — the README sequences this for you.
# 1 — Create the GitHub App (Contents RW, PRs RW, Metadata R. # Workflows RW optional — see security model. No Administration.) # 2 — GitHub ships PKCS#1; Workers WebCrypto wants PKCS#8: openssl pkcs8 -topk8 -inform PEM \ -in your-app.private-key.pem -nocrypt -out app-pkcs8.pem # 3 — Enable user OAuth on the app: callback = # https://<worker>/callback, generate a client secret. # 4 — Secrets (never committed, never pasted in chat): wrangler secret put GH_APP_ID wrangler secret put GH_APP_PRIVATE_KEY wrangler secret put GITHUB_CLIENT_ID wrangler secret put GITHUB_CLIENT_SECRET # 5 — Ship it: npm install && npm run deploy # 6 — Point any MCP client at https://<worker>/mcp — # OAuth + GitHub login happen in the browser.