The main failure is privilege escalation inside a trusted integration. A read-only app can effectively act with write or admin rights, which breaks the permission boundary that organizations rely on. That can expose repositories, leak secrets and credentials, or alter code and settings. Security teams should treat installed app permissions as an access-control control, not just a convenience setting.
How over-privileged installation tokens break the trust boundary
A github app installation token is supposed to be a bounded delegation of the app’s approved permissions. If the token can mint with more privilege than the installation granted, the app no longer behaves like a constrained integration. It becomes an escalation path: the platform has preserved authentication, but it has failed at authorization enforcement.
That matters because the whole security model depends on the token’s effective rights matching the installation’s consent. Once those rights drift upward, repository access, branch protection, release operations, and secret-bearing workflows can all be reached through a channel that was meant to be limited.
What this means for repository, secret, and workflow exposure
The immediate break is not just “extra access,” it is privilege amplification inside a trusted boundary. A read-only integration that can write, administer, or trigger privileged actions can alter code, change settings, or harvest data from places that operators assumed were protected by the app’s original permission grant.
That also changes blast radius. A compromised third-party app, a malicious maintainer, or a flawed token service can use the mismatch to move from narrow integration access into broader repository control, and that can expose secrets sprawl, automation credentials, and deployment pathways. It is the same class of failure seen in real-world token abuse cases such as GitHub Dependabot token abuse and the 52 NHI breach cases where stolen or overpowered credentials were turned into repository and supply-chain impact.
Why teams should treat this as access-control design, not just app hygiene
This is a control-plane problem, not only an application-risk problem. If installed app permissions are not enforced precisely at token mint time, then approval, review, and least-privilege assumptions become unreliable. That weakens governance over third-party integrations and makes permission reviews look stronger on paper than they are in practice.
The same issue shows up when third-party access is allowed to outgrow the original contract. Real compromise examples, including token theft and third-party integration abuse, show that delegated access must be scoped, monitored, and revocable at the same granularity as any other privileged access path. For broader identity context, NHIs in GitHub and SaaS integrations are often where that boundary is first tested, and overprivilege and secret exposure are the failure modes that make the break operationally serious.
Risk and Threat Considerations
This failure creates a direct privilege-escalation path for anyone who can influence the app, the token-minting flow, or the installation itself. Even if the app was granted only limited rights, the attacker benefits because the platform has already accepted the integration as trusted.
Failure mechanism: The installation token is minted with permissions that exceed the installation grant, so authorization decisions at token issuance do not match the consented scope.
Impact: The app can read, write, or administer repositories and related workflows beyond the expected boundary, which can expose code, secrets, release pipelines, and downstream supply-chain trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Token minting above grant scope is overprivilege in a third-party NHI. |
| NHI-03 — Vulnerable Third-Party NHI | The break occurs in a third-party integration whose trust is being misused. | |
| NHI-01 — Improper Offboarding | If privileges are exceeded, revocation and removal controls become critical to containment. | |
| Recommendation — Enforce least privilege so installation tokens cannot exceed the granted permissions. Review third-party app permissions and restrict integrations to the minimum required scope. Revoke or disable the app immediately when permission enforcement cannot be trusted. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The issue is a direct least-privilege failure in token authorization. |
| IA-5 — Authenticator Management | Installation tokens are identity-bearing material whose issuance and lifecycle must be controlled. | |
| AC-3 — Access Enforcement | The platform must enforce the approved permission boundary at token issuance and use. | |
| Recommendation — Limit issued token privileges to the minimum permissions required for the app's function. Manage token scope, rotation, and revocation so issued credentials cannot outlive their intended access. Enforce the granted permission set at every access decision, including token minting. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | A token that gains extra operations can invoke functions beyond the approved level. |
| API2 — Broken Authentication | If token issuance or trust is misbound, the app can present credentials with unintended power. | |
| Recommendation — Verify function-level authorization so installed apps cannot call higher-privilege actions. Bind token issuance to the correct app identity and reject tokens that do not match the grant. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | This is an IAM boundary failure between approved and effective access. |
| GV.RM-01 — Risk Management Strategy | Organizations need a formal way to classify and monitor third-party app privilege drift. | |
| Recommendation — Validate that installation tokens remain within the access boundaries approved for the app. Treat delegated app privilege as a managed risk and review it on a defined schedule. | ||
Practitioner Guidance
What to verify: Confirm that the effective token scopes, repository access, and organization grants exactly match the installation contract, not just the app manifest. Test for mismatches at mint time and after app updates, because scope drift can appear without a visible consent change.
Decision rule: If a third-party app can obtain a token that is broader than the installation approval, treat it as an authorization defect and not a harmless implementation quirk. Prioritise revocation, scope correction, and blast-radius review before assuming the integration is safe to keep enabled.
Practitioner takeaway: The security question is not whether the app is “trusted,” but whether every issued token remains strictly bounded by the permissions that were actually granted.
Related resources from NHI Mgmt Group
- What breaks when an app relies on refreshable third-party tokens without lifecycle controls?
- What breaks when organisations do not review third-party app permissions?
- What breaks when a third-party OAuth app is compromised?
- What breaks when a mobile app contains embedded third-party endpoints that get compromised?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
