What is the difference between repository access controls and third-party app access in GitHub security?

How repository permissions differ from app permissions in GitHub

Repository access controls govern what a user, team, or automation can do inside a specific repo. Third-party app access governs what an external integration can do after you grant it access to the organization or repositories. The difference is not just who clicks “allow”, it is which trust boundary you are extending: direct repository authority versus delegated application authority.

That distinction matters because the control point, audit trail, and revocation path are different. A repo permission change affects an account or team relationship; an app grant affects a separate software principal that may touch multiple repositories, metadata, or workflows depending on the scope it was issued.

What each control actually limits

Repository access controls are the familiar read, write, maintain, or admin decisions that determine whether a principal can view code, merge changes, manage settings, or administer the repository. In practice, they are the first line of blast-radius reduction for code access, branch protection, and day-to-day collaboration. They are also the control most teams review when a person joins, moves, or leaves a project.

Third-party app access is broader in shape and narrower in purpose. A GitHub App, OAuth app, or other external integration is not a teammate, but it can still act on behalf of the organization within the scopes it received. That can include reading repositories, posting statuses, opening pull requests, or reaching connected services. The real question is not whether the app is “trusted” in general, but whether the granted scope matches the minimum task it must perform.

GitHub security problems often arise when teams confuse these layers. A repo permission review may look clean while an over-scoped integration still has a path to the same code or related systems. For that reason, mature access governance treats repository grants and app grants as separate inventories, separate approvals, and separate review cycles.

Why the trust boundary changes the risk

Repository permissions constrain people and teams, so the main risk is excessive human or team authority inside the codebase. Third-party app permissions constrain delegated software access, so the main risk is that a compromised or overprivileged integration can bypass normal user expectations and operate at machine speed across many repositories or linked services.

That difference is material when you evaluate blast radius. A human account usually produces a smaller and more traceable change pattern. A third-party app can automate bulk reads, writes, or status changes and may persist until its token, installation, or connected authorization is removed. If the app is compromised, the attack path often looks like trusted automation rather than obvious account misuse, which makes review and detection harder.

IAM and IGA Basics is useful background here because the same access-governance principles apply to both people and software principals. GitHub repositories are the asset, but the governance question is still who or what should have which entitlement, for how long, and under what review process.

Third-Party, B2B and Contractor Access Guide also maps well to this distinction because app access behaves like delegated third-party authority, not ordinary internal role assignment. If you would require sponsorship, expiry, and periodic review for a contractor, the same discipline belongs on external integrations.

How to manage both without mixing them up

Start by separating inventories. One list should cover repository membership, team grants, and admin rights. A second list should cover installed apps, OAuth grants, webhooks, tokens, and any external automation that can reach GitHub or connected systems. If those inventories are merged, review quality usually drops because teams cannot tell whether they are approving a person, a team, or a software integration.

Then apply different approval logic. Repository access should be driven by role, project need, and least privilege. Third-party app access should be driven by scope, data exposure, token lifetime, publisher trust, and the ability to disable the integration quickly if something looks wrong. If the app needs broad repository visibility to function, that should trigger stronger justification and tighter monitoring, not informal acceptance.

Authorisation Models Guide is relevant because the same permission question can be modelled differently for people and integrations. RBAC may work for repo membership, while app permissions often need a more explicit scope-based or policy-based view to avoid granting more than the integration actually requires.

GitHub OAuth token breach 2022 shows why third-party app access deserves separate scrutiny: a stolen OAuth token can be enough to reach private repositories even when ordinary user access looks controlled. That is a delegation problem, not a repository-permission problem.

Practitioner Guidance

What to verify: Confirm whether each access path is a direct repository grant or a delegated app grant. If the answer is “app”, verify the scopes, token lifetime, install owner, and revocation process before approving it.

Decision rule: If the access is needed for collaboration, keep it in repository permissions. If the access is needed for automation, isolate it as an app grant and review it like a third-party dependency, not like a user role.

Common mistake: Teams often tighten repository membership while leaving broad app scopes untouched. That creates a false sense of control because the more powerful path is often the integration, not the human account.

Practitioner takeaway: Treat repository permissions as direct code access and third-party app access as delegated operational authority, then govern them with different reviews, different evidence, and different revocation expectations.

Related resources from NHI Mgmt Group

• What is the difference between repository security controls and third-party integration risk in developer platforms?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between third-party risk management and access control in supply chain security?
• What is the difference between repository-level GitHub security controls and organisation-wide governance for code security?