What actually shipped
The change lets teams replace classic personal access tokens with GitHub Apps for more enterprise and organization automation. GitHub groups the new permissions into three areas:
- Governance: enterprise-level repository policies and rulesets, plus read access to delegated bypass requests.
- Security: two-factor authentication requirements, domain verification, IP allowlists and enterprise access restrictions.
- Administration: enterprise profile updates, member privileges and repository access settings.
GitHub also says two gaps at the organization level were closed. The updates are slated for GHES 3.24, which is GitHub Enterprise Server. The changelog gives no release date for that version.
The permission map
GitHub lists the following. "Read/write" and "write" are the permission levels as GitHub labels them. They do not mean that every API in a category is open to apps.
| Permission | Level | What apps can do |
|---|---|---|
| Enterprise organization and repository policies | Read/write | Read policy fields on EnterpriseOwnerInfo. Update private-repository forking, default repository permissions, visibility changes, repository creation and deletion, issue deletion, collaborator invitations, deploy keys, protected-branch updates, and the dependency insights, organization projects and repository projects settings. |
| Enterprise bypass requests | Read | Read push-rule and repository-policy bypass requests. |
| Enterprise settings | Read/write | Read enterprise data through EnterpriseOwnerInfo, including server installations and organization invitations, and update the enterprise profile. Read is required to reach the policy data. |
| Enterprise two-factor authentication | Read/write | Read two-factor fields. Update two-factor requirements and disallowed authentication methods. |
| Enterprise and organization verifiable domains | Write | Access VerifiableDomain objects. |
| Enterprise and organization IP allowlist | Read/write | Create, update and delete IpAllowListEntry items. Toggle enforcement, trust of GitHub Apps, and user-level enforcement for Enterprise Managed Users. |
| Enterprise access restrictions | Write | Enable or disable the restrictions. |
| Enterprise repository rulesets | Write | Manage rulesets through the enterprise rules REST APIs and RepositoryRuleset in GraphQL. |
Two existing permissions also gained coverage:
- Enterprise people (read/write): apps can read
EnterpriseRepositoryInfo, including repository details throughEnterpriseOwnerInfo.outsideCollaborators. They can also add themselves to an organization as an owner or member. - Enterprise billing (write): apps can update the member purchasing setting for the Marketplace.
The billing item is narrow. It should not be read as broad billing API coverage for apps.
Why admins should care
PATs belong to people. When the person leaves, changes roles or loses access, the automation can break. A classic PAT is also usually broader than the job requires. GitHub's own automation guide describes app tokens as temporary, scoped to specific accounts and permissions, and associated with the app's identity rather than a user account. That helps with audit trails, and it limits the damage if a credential leaks.
Here is a plausible example. A platform team might enforce IP allowlist entries, flip two-factor requirements, or keep enterprise rulesets in sync with a policy-as-code repository. These jobs often run on an owner's PAT today. The new permissions let an app do them under its own identity. This is my illustration of the use case, not a scenario GitHub describes.
The limits that matter
This is not a universal PAT replacement. GitHub's enterprise-installation documentation is clear about the boundaries:
- Only enterprise owners can install. App managers cannot install apps at the enterprise level.
- Enterprise installs get enterprise permissions only. An app can request other permissions, but only the enterprise ones are granted at install time.
- No automatic organization or repository access. To reach organization or repository resources, the app must also be installed in each relevant organization. The organization installations API is the exception.
- No enterprise-level webhooks. Enterprise installations cannot receive webhook events for enterprise-level activity, so event-driven designs need another route.
- Coverage is still partial. GitHub says not every enterprise API supports these apps.
- Rate limits are per installation. An app installed on an enterprise and two organizations needs three installation tokens. Each gets its own rate-limit budget.
- Third-party restrictions. You cannot install a private app owned outside your enterprise. Apps requesting the "Enterprise organization installations" permission can only be installed on the enterprise that owns them. Earlier GitHub changelog posts explain this by calling that permission set extremely powerful. It can manage app installations across every organization in an enterprise.
One caution on timing. GitHub's documentation page I reviewed still labels enterprise-installed apps as public preview, even though the changelog announces general availability. Documentation often lags launches, but treat the docs' limitation list as the practical reference until it is updated.
A pattern for multi-organization automation
GitHub's guide shows how to split the work across two enterprise-owned apps:
- An installer app gets the enterprise permission to install apps in organizations.
- It authenticates and obtains an enterprise-scoped installation token.
- It uses that token to install a second, automation app in a specific organization.
- The automation app then authenticates and gets an organization-scoped token.
- It uses that token for the actual task. The guide's example creates a repository.
The guide's prerequisites are being an enterprise owner and an owner of an enterprise-owned organization. You also need the GitHub CLI, OpenSSL for JWT generation, and a Unix-style shell. The guide suggests uninstalling the demo apps afterward, which revokes their tokens. It adds that security-conscious enterprises might install and uninstall an app each time automation runs, to limit exposure if the private key leaks. This is an illustration, not a requirement to use two apps.
Migration checklist
- Inventory your PAT-backed scripts. Match each API call against the permission table above. Anything not listed is not confirmed as supported.
- Request the minimum permissions. Choose permissions in the GitHub App settings. For policy work, remember that reading policies requires the enterprise settings read permission.
- Plan the organization installs. If a script touches organization or repository resources, the app needs installing there too.
- Check your GHES version. Self-hosted teams should wait for GHES 3.24 before relying on these permissions.
- Protect the private key. An app that can alter IP allowlists or two-factor requirements is a high-value target.
Bottom line
This is a solid step for enterprise automation rather than a flashy one. The new permissions cover sensitive areas such as two-factor requirements, IP allowlists, rulesets and domain verification. The documented limits (owner-only installs, no enterprise webhooks, separate organization installs, partial API coverage) mean migration needs care. Pilot one workflow first.