GitHub Apps can now be installed at the enterprise level, and the feature is generally available. The change introduces a set of new permissions that let apps manage enterprise policies, two‑factor authentication, IP allowlists, and other admin settings, and it fills several gaps that previously required classic PATs.
New Governance and Security Permissions
The GA release adds explicit scopes for enterprise‑wide controls:
- Repository policies and rulesets: Apps can read and write policy fields via
EnterpriseOwnerInfo, and manage rulesets through the enterprise rules REST API and theRepositoryRulesetGraphQL type. - Bypass requests: Read access to push‑rule and repository‑policy bypass requests.
- Two‑factor authentication: Read/write access to two‑factor fields, allowing apps to enforce requirements and block disallowed methods.
- Verifiable domains: Write access to
VerifiableDomainobjects for enterprises or organizations. - IP allowlist: Full CRUD on
IpAllowListEntry, plus toggles for enforcement, trust of GitHub Apps, and user‑level enforcement for Managed Users. - Access restrictions: Write permission to enable or disable enterprise‑wide access restrictions.
Expanded API Coverage for Automation
Beyond the new scopes, GitHub has back‑filled several existing permissions, removing previous API gaps:
- Enterprise people: Read/write access to
EnterpriseRepositoryInfoand the ability to add the installing user to an organization as owner or member. - Enterprise billing: Write permission to update the member purchasing setting for the Marketplace.
All of these endpoints are reachable via REST and GraphQL, and the changes are slated for GHES version 3.24.
Operational Considerations for Migration
Teams that currently rely on classic personal access tokens (PATs) for enterprise automation should evaluate the new app scopes as a replacement path. When configuring a GitHub App, select only the permissions required for a given workflow to follow the principle of least privilege. Because the new scopes expose high‑impact controls (e.g., two‑factor enforcement, IP allowlist changes), audit logs and approval processes become more critical.
From an implementation standpoint, the migration steps are:
- Identify existing PAT‑based automation that touches enterprise settings.
- Create or update a GitHub App, enabling the specific new permissions needed.
- Replace the PAT in CI/CD pipelines, bots, or custom scripts with the app's JWT or installation token.
- Validate that the app can perform the required actions in a staging environment before production rollout.
Because the new permissions are scoped at the enterprise level, the installation process must be performed by an enterprise admin. The app will then inherit the granted scopes across all organizations under that enterprise.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Enterprise GitHub Apps now give engineers a native, auditable mechanism to automate governance, security, and admin tasks that previously required PATs or manual intervention. The immediate benefit is tighter control over who can change critical settings, and the ability to embed those controls in existing CI/CD or AI‑driven workflows. Practitioners should audit current token usage, prototype the new app permissions in a test enterprise, and plan a phased migration aligned with the GHES 3.24 rollout schedule.