GitHub Narrows App Permissions to Pull Teams Off Classic PATs

GitHub is giving DevOps teams more ways to limit an automation job to only the access it needs.

A batch of GitHub Apps updates released Oct. 13 adds narrower permissions, relaxes a long-standing install restriction for repository administrators, and makes it easier to move users to expiring tokens. GitHub says the goal is to help developers move off classic personal access tokens (PATs), manage apps more easily, and request fewer sensitive permissions.

That’s a real problem. Classic PATs are still everywhere. They’re easy to create, they often don’t expire, and their scopes are broad. A token with the repo scope can reach every repository its owner can. That’s a lot of exposure for a script that only needs to create a new repo once a week.

GitHub Apps were built to fix that. Installation tokens are short-lived, and permissions are set per resource. But a few gaps kept pushing teams back to PATs. These updates close several of them.

Creating Repos Without Admin Rights

Until now, an app or PAT needed repository_administration:write to create a repository. That permission also allows deleting and transferring repos. So administrators faced a bad choice. They could reject the app, ban PATs with that permission, or accept the risk.

The new repository_creation:write permission does one thing: it lets the caller create repositories. The app or user that creates the repo gets access to it automatically. An organization administrator still has to install the app.

GitHub also added installation_repositories:write. It lets the caller add or remove a repository from any app installation in the organization. The APIs behind this used to support only the coarse repo scope. Now they work with GitHub Apps and fine-grained PATs. If the caller is a user, they also need to be an org owner or a repository admin.

Both permissions are available to GitHub Apps and fine-grained PATs. For platform teams, that means they can build automation that controls which apps see which repositories without relying on an administrator’s broad PAT.

Less Friction for Repository Admins

Historically, repository admins blocked any app requesting organization-level access from being installed on a repository. No exceptions.

GitHub has relaxed that rule. If an org owner has already approved and installed the app in the organization, repository admins can now add their own repositories to that installation. The logic is simple. The app already has org-level access, so adding another repo doesn’t expand that access or give the repository admin new privileges.

Three permission sets still require org owner approval: all organization-level permissions, repository administration, and repository creation. Organizations that want to limit app installs to owners can still lock that down.

A Gradual Path to Expiring Tokens

GitHub Apps issue short-lived, rotating user tokens by default. But some developers turned expiration off for convenience. Turning it back on has meant switching every user at once, which breaks existing clients.

GitHub Apps now support the offline_access scope, like OAuth apps. When an app requests it, the app gets a refresh token along with the expiring access token. The change applies only to that authentication and doesn’t affect future sessions. This lets teams test and roll out expiring tokens in stages instead of all at once.

Permissions are still set when you register the app. The scope parameter otherwise stays unused for GitHub Apps.

Better Visibility for Auditors

Apps can now use the Get an app API to pull details about private and internal apps, as long as they share some ownership. GitHub allows four patterns:

• Public apps: Any app can fetch the details, as before.
• Same organization: Apps with the same owner can see each other, regardless of visibility.
• Same enterprise: Another app in the enterprise can fetch an internal app’s details, even across organizations.
• Enterprise to organization: An enterprise-owned app can see apps owned by organizations in that enterprise.

That gives security and platform teams a way to automate app inventory and audits. It beats clicking through settings pages one app at a time.

A Home for Credentials

Client secrets and private keys now live on a dedicated Credentials tab instead of being mixed in with an app’s other settings. They’re easier to find, and the tab leaves room for workload federation credentials, which GitHub plans to add. GitHub didn’t share a timeline in this update.

For GitHub Enterprise Server customers, offline_access support lands in GHES 3.23. The rest of the improvements arrive in GHES 3.24.

Why It Matters Now

None of these changes is dramatic on its own. But together they remove excuses. The usual reason a team keeps a broad PAT around is that the narrower option didn’t exist or broke something. That’s less true today.

It also matters more than it did a few years ago. Automation now includes AI coding agents that open branches, create repos and push changes.

“An AI coding agent inherits whatever access its token carries, so token scope is now an agent governance decision,” said Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group. “A classic PAT on an agent hands machine-speed automation the full reach of the person who created it.”

Whoever builds and deploys an agent owns what it does. Scoping its access tightly is part of that job.

And classic PATs aren’t going away on their own. “Classic PATs remain supported, and GitHub hasn’t set a date to retire them,” Ashley said. “Until it does, enterprises should treat any classic PAT running an agent as an open security finding.”

A few practical steps are worth taking now. Look for apps and PATs that hold repository_administration:write only to create repositories, and swap in repository_creation:write. Replace admin PATs used to manage app installations with installation_repositories:write. If you disabled token expiration on an app, use offline_access to turn it back on in stages. And use the expanded Get an app API to build a real inventory of what’s running in your organization.

Least privilege only works when it’s practical. GitHub just made it a bit more practical.