Productivity · News
GitHub Apps Can Now Replace Enterprise PATs
Enterprise installations for GitHub Apps are generally available, with new permissions for policies, rulesets, 2FA, verified domains, IP allowlists and access restrictions. Most of the reasons to keep a classic PAT for enterprise admin work just went away.
Alex Rivera · Oct 23, 2026 · 8 min read
On this page
GitHub made enterprise installations for GitHub Apps generally available on October 23. The release adds App permissions for enterprise policies, rulesets, two-factor requirements, verified domains, IP allowlists, and access restrictions.
That matters because enterprise admin automation has been one of the last places where classic personal access tokens were hard to avoid. Now the token can belong to an App instead of a person.
Image: GitHub Changelog, Enterprise installations for GitHub Apps generally available, October 23, 2026.
What the new permissions cover
Governance: Apps can read and write enterprise organization and repository policies. That covers private-repo forking, default repository permissions, visibility changes, repository creation and deletion, issue deletion, collaborator invitations, deploy keys, and protected branch updates. A separate read permission exposes push-rule and repository-policy bypass requests.
Rulesets: a write permission manages enterprise rulesets through the enterprise rules REST APIs and the RepositoryRuleset GraphQL object.
Security: Apps can read and update enterprise 2FA requirements and disallowed authentication methods, verify domains for enterprises and organizations, manage IP allowlist entries, and enable or disable enterprise access restrictions. The IP allowlist permission also toggles enforcement, trust of GitHub Apps, and user-level enforcement for Enterprise Managed Users.
Administration: an Enterprise settings permission reads enterprise data and updates the profile. GitHub notes the read side is required before the policies permission works. Two gaps in existing permissions also closed: Enterprise people now reaches outside collaborators and can add the App's actor to an org, and Enterprise billing can update the Marketplace member purchasing setting.
Why this beats a classic PAT
A classic PAT acts as the person who created it, with that person's access. When they leave or change roles, the automation breaks or quietly keeps too much power. A GitHub App has its own identity, is granted permissions one by one, and authenticates with short-lived installation tokens.
It fits a pattern. Two days earlier, GitHub put expiring, auto-refreshing OAuth tokens for the gh CLI into public preview. The direction is clear: fewer long-lived credentials, tied to fewer people.
What to do this week
Inventory the classic PATs your enterprise automation uses: policy-as-code, ruleset sync, allowlist updates, compliance reports. For each, create an enterprise-installed App with only the permissions that job needs.
Treat the IP allowlist and access restriction permissions as break-glass. An App that can toggle allowlist enforcement can lock people out or open the door. Scope it to one App, store its private key in your secrets manager, and alert on its use. If you run GitHub Enterprise Server, these changes arrive in GHES 3.24.
Sources
https://github.blog/changelog/2026-10-23-enterprise-installations-for-github-apps-generally-available/
https://github.blog/changelog/2026-10-21-github-cli-opt-in-to-expiring-auto-refreshing-oauth-tokens/