# GitHub’s New App Permissions Narrow the Platform Engineering Blast Radius

- Link: https://thestackobserver.com/githubs-new-app-permissions-narrow-the-platform-engineering-blast-radius/
- Published: 2026-10-14T12:55:02-04:00
- Author: Stackxx

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.

## Sources

 * [GitHub Changelog: GitHub App improvements for least privilege and management](https://github.blog/changelog/2026-10-13-github-app-improvements-for-least-privilege-and-management/)
 * [GitHub Docs: About creating GitHub Apps](https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps)