answered from live GitHub & Hugging Face data
What are the best practices for using GitHub App installation tokens for AI coding agents?
Correction: an installation token lasts one hour. Treat that short lifetime as your main safety control, not a weakness. A common assumption is that a GitHub App token works like a long-lived bot key. It does not. Mint a new token for each agent run, limit it to one repository, and revoke it when the run ends.
Token types for agents
| Token | Acts as | Lifetime (per docs) | Use for agents? |
|---|---|---|---|
| Installation access token | The app itself | 1 hour | Yes, the default. Activity shows as the app. |
| User access token | The app, for one user | 8 hours, refresh token 6 months | Only when the agent acts for a specific person. |
| Personal access token | A person | Set by the user | No. GitHub says apps should never use one. |
Sources: installation tokens, best practices, user tokens.
Practices
- Keep the private key out of the agent. The private key "grants access to every account that the app is installed on." Store it in a key vault, or in an encrypted environment variable on a server. Never hard-code it.
- Use a small broker to mint tokens. The broker holds the key and calls
POST /app/installations/INSTALLATION_ID/access_tokens. It gives the agent only the short-lived token. This is my recommendation, based on the key-scope warning above. - Limit each token to one repository. Pass
repositoriesorrepository_idsin the request. Without them, the token reaches every repository the installation can access. - Limit each token's permissions. Pass
permissionsin the request. Without it, the token gets every permission the app has. The app's own permissions should also be the minimum. - Request only the permissions you need for git. Use "Contents" for HTTP git access. Add "Workflows" only to edit
.github/workflows. Clone withhttps://x-access-token:TOKEN@github.com/owner/repo.git. - Cache tokens until they expire. Reuse a valid token. Mint a new one only when the cached token expires. The docs say this makes your app faster and reduces token requests.
- Revoke tokens when the run ends. Call
DELETE /installation/token. The docs also advise immediate revocation if a token leaks. - Do not assume a fixed token length. GitHub began a staged rollout of a new format (
ghs_APPID_JWT) on April 27, 2026. Code that expects exactly 40 characters can break. - Use a webhook secret. Verify every webhook signature if the agent reacts to events.
- Plan for rate limits. The docs say limits depend on the token type. I could not confirm the exact numbers from the pages I read. Check the GitHub Apps rate-limit page before you size a fleet.
Attribution
An installation token acts as the app. The GitHub timeline shows the app as the actor. If one person must answer for the agent's work, record that person separately. The docs do not cover that case. A user access token shows the user, but it limits the agent to that user's rights.
Recommendation
Use one GitHub App per agent if you run more than one agent. One shared app shows all agents as the same bot. Mint a one-hour token per run, scoped to one repository and the minimum permissions. Keep the private key in a vault that only your broker can read.
Choose a user access token if the agent must act with one person's rights. Choose an installation token for autonomous bots.
If you want this setup without building the broker yourself, githug does it. Each agent gets its own key, which mints one-hour, single-repository GitHub App tokens. The hug init --repo owner/repo command sets it up. It is free during the beta.