GitHub Adds Least-Privilege Repository Creation and App Installation Permissions

On October 13, 2026, GitHub announced a substantial set of updates in the GitHub Changelog designed to close several of those exact governance gaps. The release introduces two narrower fine-grained repository permissions, relaxes installation bottlenecks for repository administrators working with already-approved organization apps, brings the offline_access scope to GitHub Apps for smoother token-expiration migrations, expands API visibility for internal app auditing, and reorganizes the app credential user interface ahead of planned workload federation features.

For DevOps leads, software developers, and enterprise IT administrators overseeing source control security, this bundle represents a practical step forward in enforcing least-privilege access without grinding daily engineering workflows to a halt.

Decoupling Repository Creation from Full Administrative Control​

In any mature engineering organization, automating repository provisioning is a bread-and-butter workflow. Whether teams are spinning up microservice templates, generating sandbox environments, or forking codebases via internal developer portals, automation needs the ability to create repositories.

Previously, however, GitHub’s permission model treated repository creation as an all-or-nothing administrative affair. For a GitHub App or fine-grained PAT to create a repository, it had to be granted the repository_administration:write permission. The catch? That exact same permission also grants the ability to perform destructive, high-risk administrative actions—most notably deleting repositories or transferring them elsewhere. Security-conscious administrators were regularly boxed into a corner: they either had to reject useful provisioning apps, ban PATs carrying that scope, or hold their noses and accept a glaring over-privilege risk.

GitHub has now split this capability out by introducing two fine-grained repository permissions available to both GitHub Apps and fine-grained PATs:

• repository_creation:write: Grants the caller the narrow ability to create a repository within the account where the permission is granted, without conferring broader administrative powers like repository deletion or transfer.
• installation_repositories:write: Allows the caller to add or remove a specific repository from a GitHub App installation within the organization.

When a user or an app uses repository_creation:write to spin up a new repository—whether in an organization, from a template, for the current user, via a fork, or through the GraphQL API—the creator is automatically granted access to the newly minted repository.

From a governance standpoint, this is not a free-for-all. GitHub notes that an app requesting repository_creation:write still requires an organization administrator to install it in the first place. Furthermore, as documented in GitHub Docs on choosing permissions for a GitHub App, when you modify the permissions of an existing app to swap out broad administration rights for narrower ones, the owner of each account where the app is installed will be prompted to approve the updated permissions before they take effect.

Section Summary: By separating repository_creation:write from repository_administration:write, GitHub allows provisioning tools and tokens to spin up new repositories without automatically receiving the authority to delete or transfer existing ones.

Automating App Access Without an Admin's Classic PAT​

The second permission, installation_repositories:write, solves a quieter but equally frustrating problem in enterprise automation: controlling which repositories an installed GitHub App can actually reach.

Historically, the organization-level REST APIs used to add a repository to an app installation—or remove one—only supported classic PATs carrying the coarse-grained repo scope. If an enterprise wanted to build automated workflows to grant an internal security scanner or CI/CD app access to newly selected repositories, an administrator often had to wire up a classic PAT with sweeping access across the organization's codebases.

With this update, the "Add a repository to an installation" and corresponding removal APIs now support both GitHub Apps and fine-grained PATs via the repository-level installation_repositories:write permission. Holding this permission on a repository allows the caller to attach or detach that repository from any installation in the organization.

GitHub still enforces strict guardrails around human callers: if a user is making the API call rather than an automated app, that user must also be an organization owner or an administrator on the target repository. According to GitHub Docs, requests made with a user access token are always constrained by the intersection of both the app's permissions and the authorizing user's own permissions, whereas installation access tokens depend solely on the permissions granted to the app itself.

Section Summary: Supporting installation_repositories:write on the installation repository management APIs lets platform teams retire over-privileged admin classic PATs in favor of scoped automation.

Cutting Red Tape for Repository Administrators​

If you have ever managed a single project inside a massive GitHub organization, you likely know the frustration of trying to attach an already-vetted tool to your repository. Until now, if a GitHub App requested any organization-level permission, GitHub completely blocked repository administrators from installing that app on their repositories—even if an organization owner had already reviewed, approved, and installed the app at the organization level. Every single repository addition required bothering an organization owner.

GitHub has relaxed this restriction for apps that are already installed in the organization. Because an organization owner has already approved the app's organization-level access, allowing a repository administrator to edit that existing installation and add their own repository does not escalate the app’s organization-level privileges or grant the repository admin any extra reach.

With the arrival of the new repository creation scope, GitHub defines three sensitive permission sets that require organization owner approval for initial installation:

1. All organization-level permissions
2. Repository administration
3. Repository creation

Once an organization owner has approved an app carrying these permissions, individual repository administrators can self-serve and add their repositories to the existing installation. For strictly locked-down environments that prefer the old bottleneck, organization owners can still block this behavior by enabling the "Restricting GitHub App Installation to Organization Owners" setting documented in GitHub's administrative controls.

Section Summary: Repository administrators can now attach their repositories to apps that organization owners have already installed and approved, reducing administrative ticket churn while preserving owner opt-out controls.

Gradual Token Expiration Rollouts with offline_access​

Short-lived, rotating user access tokens are the default—and strongly recommended—security posture for GitHub Apps. However, during earlier development cycles or legacy migrations, many app builders opted out of token expiration for convenience. Once an app has a large active user base relying on non-expiring tokens, flipping the switch back to expiring tokens becomes an operational nightmare: turning it on globally breaks existing client integrations all at once.

To solve this migration deadlock, GitHub Apps now support the offline_access scope during authentication, mirroring how OAuth apps handle refresh flows. Here is how the mechanics work in practice:

• When an app requests offline_access during a specific authentication flow, GitHub returns both an expiring user access token and a refresh token.
• This behavior applies strictly to that specific authentication session and does not alter future sessions where the parameter is omitted.
• The scope parameter remains otherwise unused for GitHub Apps; actual API permissions continue to be defined statically on the app registration page rather than dynamically requested at login.

This allows developers to test and roll out token expiration incrementally in updated client builds while legacy clients continue functioning until they are phased out.

Section Summary: The offline_access parameter gives GitHub App maintainers a per-session way to request expiring user tokens and refresh tokens, removing the risk of a sudden, breaking cutover for existing users.

Cross-App Discovery for Enterprise Auditing and UI Cleanup​

As organizations replace sprawling collections of classic PATs with dozens of internal GitHub Apps, a new administrative headache emerges: shadow IT and app sprawl. Previously, the "Get an app" API only allowed a GitHub App to fetch metadata about public apps. If an enterprise security team built an internal auditing app to inventory all private and internal apps across their organizations, the API simply wouldn't let it read their details.

GitHub has expanded the "Get an app" API so that apps can inspect private and internal apps whenever they share an ownership relationship. The newly permitted access patterns cover four tiers:

Alongside these API changes, GitHub has tidied up the developer settings interface. GitHub App credentials—such as client secrets and private key pairs—have been moved out of the main inline configuration page and into a dedicated Credentials tab. Beyond making key rotation easier to locate, GitHub explicitly noted that this UI restructuring sets aside space for upcoming workload federation credentials, signaling that native secretless authentication patterns for GitHub Apps are on the roadmap.

GitHub Enterprise Server (GHES) Availability​

While these capabilities are rolling out directly to GitHub.com, enterprise administrators running self-hosted environments need to pay close attention to version boundaries. GitHub has split the on-premises rollout across two upcoming releases:

• GHES 3.23: Will include support for the offline_access scope on GitHub Apps.
• GHES 3.24: Will receive the remaining improvements, including the repository_creation:write and installation_repositories:write permissions, relaxed repository administrator installation rules, expanded "Get an app" API visibility, and the dedicated Credentials UI tab.

Practical Next Steps for Administrators and Developers​

If you manage GitHub organizations or maintain internal integrations, consider taking three immediate actions:

1. Audit repository_administration:write grants: Identify any internal GitHub Apps or fine-grained PATs that only hold administrative permissions to create repositories, and downgrade them to repository_creation:write.
2. Retire installation-management classic PATs: Replace any automation scripts using classic repo-scoped PATs to attach repositories to app installations with fine-grained tokens or apps scoped strictly to installation_repositories:write.
3. Review Organization App Restrictions: Decide whether your security posture benefits from letting repository administrators attach already-approved organization apps to their codebases, or if you need to enforce the owner-only installation lock in your organization settings.