githuganswered from live GitHub & Hugging Face data
What are the differences in usage scenarios for fine-grained PATs, GitHub App installation tokens, and deploy keys for AI coding agents?
For AI coding agents, use a GitHub App installation token by default. Use a fine-grained PAT only for a short, single-user test. Use a deploy key only for one server that pulls or pushes one repository.
GitHub's docs support this order. GitHub recommends fine-grained PATs over classic PATs, but they are meant for access on behalf of yourself. Long-lived integrations should use a GitHub App (Managing your personal access tokens).
Comparison
| Fine-grained PAT | GitHub App installation token | Deploy key | |
|---|---|---|---|
| Identity | The user who created it | The app, not a user | None. It is tied to the repository |
| Expiry | Optional. Infinite lifetimes are allowed unless an org sets a maximum | 1 hour, or less if revoked | No expiry date |
| Scope | One resource owner, selected repositories, chosen permissions | Selected repositories and chosen permissions, set per token | One repository. Read-only by default, write optional |
| Lifecycle | Stops working if the user loses access | Survives staff changes. Does not use a seat | Stays active after the creator leaves |
| Rate limits | User limits | Dedicated limits that scale with the installation | Not an API credential |
| Setup | Minutes | Create app, store private key, mint tokens in code | Generate SSH key, add to repo |
Sources: Token expiration and revocation, Generating an installation access token, Managing deploy keys.
Fine-grained PATs: a single-user test
- Use when: you test an agent once, or run a short script under your own account.
- Limit: the token acts as you. Commits and PRs show your name, and the agent can do anything you can do within the token scope.
- Gaps: GitHub's docs list gaps. A fine-grained PAT cannot contribute to public repos where you are not a member. It cannot call the Checks API. It cannot reach Packages. It cannot access more than one organization at once.
- Limit on count: each user can create up to 50 fine-grained PATs.
GitHub App installation tokens: the default for agents
- Use when: one or more agents work on repositories in an organization, or run long-term.
- Strength: each token has a 1-hour expiry. You set the repositories and permissions for each token. The token cannot exceed what the app was granted.
- Strength: the app is not a user. It does not depend on one employee's access.
- Cost: you must build the app, store its private key, and mint tokens on demand. The Octokit SDKs can do the token refresh for you.
- Attribution: actions show as the app, which is a bot. Commit authorship and audit trails name the bot, not the human who ran the agent.
Deploy keys: narrow, long-lived, hard to audit
- Use when: one server must clone or deploy one repository over SSH.
- Limit: a key covers one repository only. You cannot reuse a deploy key for several repositories.
- Risk: a key has no expiry and no passphrase in most setups. The docs say to use a GitHub App for finer control.
- Fit for agents: poor. An agent with a deploy key holds a permanent credential on disk. Revoking it means removing the key from the repo.
Recommendation
Use a GitHub App installation token for agents. Generate it per run, and scope it to one repository with the permissions the task needs. Use a fine-grained PAT only when you test an agent under your own account. Avoid deploy keys for agents unless one server must pull one repository.
Choose a fine-grained PAT if you need a fast test under your own name. Choose a GitHub App if more than one agent works in an org, or the work runs for a long time. Choose a deploy key if one server only clones or deploys one repository.
If you want each agent to have its own identity, githug provides this for coding agents. It issues one-hour, single-repo tokens through a GitHub App, and its beta CLI supports Claude Code, Codex, and Cursor.