A GitHub Installation is an installed instance of a GitHub App on an organisation or account. It defines where the app can act and what repository-level permissions and events it can access, with an installation token used for scoped API access.
What a GitHub installation actually represents
A GitHub Installation is the organisation or account level instance of a GitHub App. That installation is the trust boundary that determines where the app may operate, which repositories it can touch, and which events can trigger its actions. The installation token is the practical mechanism that turns that scoped grant into API access.
Why installations matter for access scope
Unlike a user login, an installation is not about broad human access. It is a bounded permission grant for an app, and that boundary is what prevents a GitHub App from acting everywhere by default. In practice, the installation is where repository visibility, event subscription, and app permissions are anchored, so the security question is always, “what exactly did this app receive in this organisation or account?”
That scope is why installation review belongs in auditing GitHub Apps and OAuth apps in an organisation, because the app inventory, installed apps, and granted repository access tell you what external code can do inside your tenant.
How installation tokens change the security model
The installation token is usually short-lived and scoped to the installation’s grant, which is a major improvement over standing credentials that can be reused indefinitely. That makes the token a delegated access artifact rather than a standing secret, but it still deserves the same careful treatment as any other bearer credential: if it leaks, the app can act as the installation until the token expires or the installation is changed.
This is why the difference between a GitHub App and its installation is operationally important. The app is the integration identity, while the installation is the specific authorisation context. If you miss that distinction, you may overestimate what the app can do, or underestimate what a compromised installation token can reach.
GitHub’s own security guidance on app scope, workflow permissions, and token handling is best understood alongside GitHub and GitHub Actions security guidance, because repository automation often combines app installations, workflow permissions, and secret exposure in the same environment.
Common failure modes and operational consequences
The main failure modes are overbroad repository permissions, forgotten installations, and unexpected access to repositories that were never intended to be in scope. A second class of failure appears when organisations lose track of which app installed where, especially after repository transfers, team changes, or a vendor integration that outlives its original business need.
If an installation is compromised, the impact is usually not “full GitHub takeover” but a more targeted abuse path: repository reads, writes, workflow triggering, release tampering, or data extraction from the repositories and events the installation can reach. That makes installation hygiene important for both confidentiality and supply-chain integrity.
How practitioners should review a GitHub installation
Practitioners should treat each installation as a separately reviewable grant, not just as a line item in an app catalog. The practical checks are whether the app still has a business owner, whether its repository permissions are still justified, and whether the installation is still needed in every organisation or account where it exists.
When the answer is “yes, it is needed,” the next question is whether the permissions are narrower than the app’s theoretical maximum. When the answer is “no,” the installation should be removed rather than left dormant, because dormant access is still reachable access. For a deeper operational lens on that review pattern, the same logic appears in GitHub Apps and OAuth app audit practices.
Authoritative control mappings for scoped access, authentication, and auditability are well aligned with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organisations need to govern access, credentials, and audit evidence for app-mediated access.
Risk and Threat Considerations
GitHub installations create a narrow but real attack surface because they often hold enough permission to read source code, modify repositories, or trigger automated workflows. The risk grows when the installation is overprivileged, poorly inventoried, or left active after the business need has ended.
Failure mechanism: An attacker who obtains or abuses the installation token can act within the installation’s granted scope, which may be enough to exfiltrate code, tamper with releases, or pivot into CI/CD workflows.
Impact: The result can be source compromise, workflow abuse, supply-chain tampering, or persistence through trusted automation until the installation is revoked or narrowed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Installation grants are access grants that need lifecycle ownership and review. |
| IA-5 — Authenticator Management | Installation tokens are scoped bearer credentials that require controlled lifecycle handling. | |
| AU-2 — Event Logging | Installation actions and permission changes should be logged for review and response. | |
| Recommendation — Review and remove unused installation grants as managed access paths. Protect and rotate installation tokens as managed credentials. Log installation grants, permission changes, and revocations for auditability. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Installation tokens are the auth mechanism for API access to GitHub resources. |
| Recommendation — Validate that installation token handling prevents unauthorized API access. | ||
Practitioner Guidance
Why practitioners should care: The installation is the control point for what the app can actually do, so it is the right place to decide whether access is justified, minimal, and still owned. Do not treat the app name alone as proof of safety; the installation scope is the real security boundary.
Practitioner takeaway: Review installed GitHub Apps as scoped third-party access grants, and remove or narrow any installation that no longer has a clear owner or current business purpose.
Related resources from NHI Mgmt Group
- What breaks when a third-party GitHub App can mint installation tokens with more permissions than were originally granted?
- GitHub App Installation Token
- How should security teams reduce risk from compromised GitHub Actions workflows?
- How should security teams govern GitHub access for developers and automation?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org