Default to the built-in GITHUB_TOKEN with minimum permissions. When a workflow must reach another repository or the organization, use a GitHub App installation token. Reach for a personal access token last, because it is tied to a person and usually lives longer than the job needs.
What each one is
GITHUB_TOKEN. Created automatically for each workflow run. GitHub says it can only access resources within the workflow's repository.
GitHub App installation token. A token your workflow generates from a GitHub App you registered. You choose the app's permissions at registration, and which repositories it can reach when you install it. GitHub's documented flow uses the actions/create-github-app-token action, with the client ID stored as a configuration variable and the private key stored as a secret.
Personal access token (PAT). A credential belonging to a user account.
Comparison
| Question | GITHUB_TOKEN | GitHub App token | PAT |
|---|---|---|---|
| Reaches other repos or the org | No | Yes, where installed | Yes, as the user |
| Tied to a person | No | No | Yes |
| You manage a long-lived secret | No | A private key | The token itself |
| Permissions set | In the workflow | At app registration and install | At creation |
Steps
- Start with GITHUB_TOKEN. GitHub recommends setting the default to read-only for repository contents, then granting extra permissions per job.
- Need another repo? Register a GitHub App, give it only the needed permissions, and install it on only the needed repositories.
- Generate the token inside the job with the app token action, and pass it through the environment.
- Use a PAT only as a fallback, with the narrowest scope and expiry available. If the person leaves, the workflow breaks, which is a sign it should have been an app.
- Rotate the app private key on a schedule, and remove apps nobody uses.
Common mistakes
- Using a PAT with broad access because a workflow needed to open a pull request in another repository.
- Granting write permissions at the top of a workflow, so every job inherits them.
- Storing the app private key as a repository secret in a repository that untrusted contributors can influence. Keep it in an environment with reviewers where you can.
Quick check
Can a workflow secret hold a PAT safely?
It can hold one, but the PAT still acts as the user and usually lives longer than the job. Prefer an app token or the built-in token.
Is a GitHub App always better than a PAT?
For automation, usually. It is not tied to a person and has narrower reach, but you still have a private key to protect.
Safeguard can enforce policies and gates on pull requests and scan dependencies, whichever credential your workflows use. Try the free scan.
Sources
- GitHub Docs: Making authenticated API requests with a GitHub App in a workflow
- GitHub Docs: Secure use reference
Last reviewed: 19 October 2026.
