GitHub has given platform teams a practical way to remove two stubbornly broad privileges from repository automation. New fine-grained permissions let GitHub Apps and fine-grained personal access tokens create repositories without receiving general repository administration rights, and manage which repositories an app installation can reach without falling back to the classic repo scope. The change looks small in a permission table. In a production developer platform, it can materially reduce the blast radius of the credentials behind repository factories, onboarding workflows, and app-access controllers.
The central lesson is straightforward: platform teams should treat this release as a reason to redraw their GitHub automation boundaries, not merely swap one permission string for another. The safest design separates repository creation, app installation management, and day-to-day repository operations into distinct identities. GitHub now supplies more of the primitives needed to make that separation operationally realistic.
Why repository automation was overprivileged
A typical internal developer platform accepts a service request, applies a repository template, configures branch rules and environments, installs approved integrations, and hands the finished repository to a team. Historically, the credential that created the repository often needed repository_administration:write. That grant covers far more than creation: GitHub notes that it also permits sensitive administrative operations such as repository deletion and transfer.
That mismatch forced an uncomfortable choice. A platform group could keep a broadly privileged credential so its self-service path remained fast, narrow the permission and reintroduce manual owner steps, or avoid the automation entirely. The security problem was not necessarily careless engineering. The authorization model bundled the intended action with dangerous adjacent actions.
GitHub’s new repository_creation:write permission breaks that bundle. An app or fine-grained PAT can create a repository in the account where the grant applies without also receiving general repository administration access. An organization administrator must still install an app that uses the permission, so the new capability narrows runtime authority without bypassing organizational approval.
The second addition, installation_repositories:write, targets another common platform workflow. It permits a caller with access to a repository to add or remove that repository from an app installation. GitHub’s add/remove installation-repository APIs now accept GitHub Apps and fine-grained PATs using this permission; previously those APIs depended on the coarse classic repo scope. For a user token, the caller must also be an organization owner or an administrator on the repository involved.
The design opportunity is identity separation
Simply adding both new permissions to an existing all-purpose platform app would leave much of the risk concentrated in one place. A better migration asks which component truly needs each capability and gives it only that authority.
Repository factory
The service that provisions new repositories needs creation rights, a constrained set of template or content permissions, and whatever organization metadata it must read. It should not automatically inherit the right to delete, transfer, or reconfigure every repository it creates. If later setup requires broader administration, delegate that work to a separate short-lived workflow or explicitly scoped app installation.
Installation access controller
A controller that attaches approved tools—such as CI, security scanning, or deployment apps—to selected repositories needs installation_repositories:write on those repositories. It does not need the classic repo scope across the organization. Keeping this identity separate makes its job auditable: its meaningful actions are changes to the repository set of an already approved installation.
Repository operations
Automation that opens pull requests, updates files, or reports checks should continue to use its own GitHub App installation tokens and narrowly selected permissions. Repository creation is not a prerequisite for routine operations. Separating the identities also prevents an incident in a day-to-day bot from automatically becoming an incident in the repository provisioning plane.
This architecture follows GitHub Apps’ existing strengths. Apps can act independently of a user, can be installed on selected repositories, include webhooks, and request specific permissions. Installation access tokens give server-to-server automation a natural boundary. The new permissions fill gaps that previously pushed teams back toward a powerful user credential.
A migration playbook for platform teams
1. Inventory credentials by action, not by owner
Start with API activity and workflow behavior. List every credential that can create repositories, change app installation membership, administer repositories, or use a classic PAT with repo. Record where it runs, who can modify that workload, which repositories it can reach, how it is rotated, and what breaks if it is revoked.
Do not stop at a spreadsheet of token names. Map each credential to concrete API operations. A token labeled “platform automation” may be used by repository creation, branch-protection setup, and emergency maintenance. Those are different trust domains even if one team owns all three.
2. Split workflows before changing grants
Decouple provisioning phases so each can fail and retry independently. Repository creation should return a stable repository identifier, after which configuration and app enrollment can run as separate jobs. This prevents a single worker from needing the union of every downstream permission and creates clean audit points for each phase.
Make idempotency explicit. A retry should detect that the repository already exists, verify that it matches the request, and continue without attempting a duplicate creation. Installation management should compare the intended and actual repository set before issuing add or remove operations. Narrow permissions reduce possible damage, but idempotency limits mistakes inside the allowed boundary.
3. Prefer GitHub Apps for durable automation
Fine-grained PATs can use the new permissions, which is useful for controlled transitions and user-mediated operations. For long-running platform services, a GitHub App is generally the cleaner target because the automation can act as itself rather than impersonating a service-account user. Installation boundaries, app-specific audit identity, and short-lived installation tokens are better foundations for a shared internal platform.
Keep a PAT only where a user context is actually part of the authorization decision or where an endpoint still lacks appropriate app authentication. Document that exception, set an owner and expiration date, and plan its removal rather than allowing “temporary” compatibility credentials to become permanent infrastructure.
4. Roll out with dual-path observation
Create a test app or test installation with the proposed minimal grants. Run representative requests in a non-production organization or a controlled repository group. Capture denied API calls and determine whether each denial exposes a missing legitimate action or an accidental dependency on excess privilege.
In production, migrate a small repository cohort first. Monitor creation failures, installation changes, token issuance, unexpected permission errors, and manual owner interventions. Keep the old path available for a short, explicitly bounded rollback window, but do not let both credentials remain indefinitely. A successful canary ends with revocation of the broader grant.
5. Add policy around delegation
GitHub now allows repository administrators to add their repositories to an app that an organization owner has already installed and approved, even when the app requests organization-level access. GitHub’s reasoning is that the organization-level access has already been approved; adding another repository does not expand that class of access. Organizations that do not want repository administrators to make this choice can restrict GitHub App installation management to organization owners.
Platform teams should make that governance decision deliberately. A developer-friendly model can publish a catalog of approved apps and let repository administrators opt their repositories in. A tightly regulated organization may keep installation membership behind a central controller. Either model can use the new permission, but the policy owner, approval record, and audit alert should be explicit.
Token migration needs its own plan
The same GitHub update adds offline_access support for GitHub Apps. App developers that disabled user access token expiration can use it to reintroduce short-lived, rotating tokens gradually. When requested, the scope supplies a refresh token alongside the expiring access token for that authorization; it does not change every future session or replace the app’s statically configured permissions.
This is useful, but it addresses a different credential path from installation access tokens. Platform teams should distinguish user-to-server flows, where an app acts with both its permissions and a user’s authority, from server-to-server flows, where an app acts as an installation. Mixing the two in migration plans can produce false confidence. A repository factory running unattended should not require a durable user access token merely because the product also has an interactive control panel.
For apps with non-expiring user tokens, stage the change by cohort, measure refresh failures, and make client behavior observable before enforcing expiration everywhere. Encrypt refresh tokens at rest, limit which service can redeem them, and treat reuse or unexpected geography as a security signal. The goal is not only shorter token lifetime; it is reliable rotation without silent fallback to permanent credentials.
Controls that should accompany least privilege
Permission narrowing is one layer. A production platform should pair it with controls that make compromise harder and detection faster:
- Separate app registrations: use distinct identities for creation, installation management, and routine repository bots.
- Repository allowlists: constrain installations to the repositories or cohorts the automation actually serves.
- Protected deployment environments: require review for changes to the workloads that mint app tokens or alter app membership.
- Structured audit events: alert on unusual bursts of repository creation, app removal, or cross-team enrollment.
- Credential rotation drills: prove that keys and tokens can be revoked without stopping the entire developer platform.
- Break-glass isolation: keep emergency administration outside the normal automation identity and log every use.
Also review permission drift. A platform app may accumulate grants as teams add features, even if every individual request appears reasonable. Periodic reconstruction from observed API calls is more reliable than asking whether every old checkbox still “might be needed.”
Tradeoffs and watch items
More identities create more registrations, ownership records, dashboards, and on-call runbooks. They can also expose hidden coupling in mature automation. That operational cost is real, but it buys smaller incident boundaries and clearer evidence about which component performed an action. Standardized app templates, common token libraries, and centralized audit pipelines can keep the complexity manageable.
Compatibility also varies by deployment. GitHub says the broader app-management improvements are planned for GitHub Enterprise Server 3.24, while offline_access support is included in 3.23. Enterprise Server teams should verify their version and API behavior before removing old credentials. GitHub’s redesigned credentials tab also reserves space for planned workload federation credentials, but planned federation should not be treated as an available control until GitHub ships and documents it.
The immediate action is narrower and available now on GitHub.com: find automation whose assigned authority exceeds its job, split the workflow where necessary, and replace broad repository administration or classic repo access with the two new grants. The release does not eliminate every privileged step in repository onboarding. It does remove two common excuses for putting the keys to the organization behind a convenience endpoint.
