GitHub App least privilege for SaaS repo creation and access

A SaaS product may need to create a customer repository during onboarding, or add an existing repository to an already installed GitHub App. Those are legitimate product workflows, but asking a customer for a broad organization personal access token can make the integration difficult to approve and hard to constrain.

GitHub announced two fine-grained permissions for both GitHub Apps and fine-grained personal access tokens: repository_creation:write for creating a repository in the account where the app or token has access, and installation_repositories:write for adding or removing repositories from an installation. GitHub says repository creation no longer needs the broader repository_administration:write, which can also allow deletion and transfer. The announcement is the GitHub App least-privilege update.

For a SaaS builder, the practical change is to match each operation to the smallest permission and approval path it needs. Separate “make a new repo” from “manage which repos an installation can access.” Then explain the remaining organization approval requirements plainly. Narrower permissions reduce unnecessary access; they do not remove GitHub’s installation or organization controls.

Start with the customer actionCopy Anchor Link

Write down the operation in customer language before selecting permissions. “Connect GitHub” is too broad to guide a request. Ask whether the user wants to create a new repository, attach an existing repository to an installed app, or both.

For repository creation, the app needs the new repository_creation:write permission. GitHub also makes the new permission available to fine-grained personal access tokens, though a SaaS integration should use the credential model appropriate to its product and customer workflow. GitHub’s announcement says this permission can create a repository in an account where the app or token is granted access. It also explains that the new permission avoids requesting repository_administration:write just to create a repository. That distinction matters: a create-only workflow should not imply that your product needs permissions to delete or transfer repositories.

For an existing repository, use installation_repositories:write only when your workflow adds or removes repositories from an app installation. GitHub says those APIs previously required the broader repo scope for personal access tokens; the fine-grained permission now narrows that request for supported callers. This controls the set of repositories the installation can access; it is not a substitute for the separate permission to create a repository.

Some products need both operations. Request both only if the customer-facing workflow actually offers both. A user who only connects an existing repository should not be pushed through a request for repository creation.

Keep the permission request understandableCopy Anchor Link

Permission review is part of onboarding. Tell the customer what the app will do, when it will do it, and which repositories are in scope. If you need repository creation, say that clearly. If you need to update an installation’s repository selection, explain that separately.

The new permission names make a narrower request possible, but they do not make approval automatic. GitHub notes that organization-level permissions, repository-administration permissions, and repository-creation permissions require organization-owner approval. Plan for that approval in the product flow. Do not describe a repository administrator as able to approve every request, or imply that a customer can avoid an organization owner when GitHub requires one.

Also keep app installation distinct from selecting repositories. An organization must install the GitHub App before it can operate through that installation. The announcement says that when an app is already installed at the organization level, repository administrators can add it to a repository without a new organization-owner approval. That is useful for the existing-installation path, but it does not eliminate the initial organization-level installation decision.

Build two explicit workflowsCopy Anchor Link

A reliable integration can present two choices instead of one vague “connect” button.

One repository is created after the organization-owner approval checkpoint. Conceptual illustration; no product UI is shown.

Create a repository. Explain the name and purpose that will be used, request the relevant repository-creation permission, and tell the user if an organization owner must approve it. After GitHub returns the created repository, show its name and link and let the user continue setup. Keep the operation idempotent: if the browser retries after a timeout, check whether the intended repository was created before trying to create another one.

Add an existing repository. First establish that the app is installed for the organization. Then let an authorized user choose the specific repository and use the installation-repository permission to add it to the installation. Confirm the selected repository in the UI. Avoid presenting access to every organization repository as the default when the customer is choosing one.

One selected repository is added to an already installed app; the other repositories remain outside its scope.

If the same product supports both, make the choice visible before the permission screen. A user should understand why the app asks for a permission, and what happens if their organization requires an owner to approve it.

Design for approval and failureCopy Anchor Link

Permission scoping does not replace operational safeguards. Use a clear audit trail for who initiated the action, the customer account, the repository, the requested operation, and the outcome. Keep enough context to diagnose a denied request or a retry without storing credentials in logs.

Handle approval states as normal product states. If an organization owner needs to approve a permission, explain what the user can do next and preserve their setup progress. If the app is installed but a selected repository is not part of its installation, guide the user to the repository-access step rather than returning a generic failure.

Test at least four cases before launch: a personal account that can grant the requested access; an organization where an owner must approve; an app already installed with a repository that is not yet selected; and a repeated request after a network timeout. Verify that the product asks only for the permission needed by each path and that it does not silently broaden access after a denial.

For related GitHub integration risk, see our guide to protecting repositories from leaked keys. Keep those concerns distinct: secret scanning protects credentials committed to source; least-privilege app permissions control what your integration can do.

Check the boundary before launchCopy Anchor Link

Review the permission list against product actions whenever you add a GitHub workflow. A useful review question is: if this permission were denied, which exact button or automated step would stop working? If the answer is “nothing,” remove the permission from the request. If several unrelated features depend on it, split those features into separate customer choices where possible.

For repository creation, verify that the app creates only the repository the customer asked for and records the resulting repository identity. For installation repository changes, verify that adding one repository does not expand access to all repositories. Test the denied and partially approved states, not only the successful path. Make the requested permissions visible in your setup copy so a customer can compare them with the workflow they initiated.

This review also helps support teams answer “why does the app need this?” with a concrete explanation. Tie each permission to a named action, show the relevant approval status, and avoid implying that a successful app installation means every repository is already accessible.

What this means for a small SaaSCopy Anchor Link

The improvement is most useful when your product automates customer setup or provisions a repository as part of a project workflow. A narrow create permission can make that request easier to explain than a broad administration permission. A separate installation-repository permission can support a deliberate “choose the repositories” step.

Neither permission means your app has access without a customer granting it, nor does it bypass organization-owner approval where GitHub requires approval. Keep the product copy precise, request only the operations you ship, and provide an escape route when the customer cannot approve the request themselves.

The SaaS Dashboard kit can serve as an optional UI and authentication starting point for a custom review flow. It does not include a GitHub App integration; the permission request, GitHub API work, and approval handling remain implementation work for your team.

SourcesCopy Anchor Link

• GitHub Changelog: GitHub App improvements for least privilege and management (October 13, 2026)