Common warning signs include dormant admin accounts, unused group memberships, tokens without expiration dates, and workflow settings that exceed the intended baseline. Another signal is when role assignments no longer match how people actually work in repositories. Those patterns suggest access has accumulated faster than governance, which increases the chance of unintended exposure.
Why GitHub Least-Privilege Drift Matters
GitHub access control drift is rarely announced by a single high-risk change. It usually accumulates through exceptions: old admins who no longer need repository-wide powers, service accounts that keep broad scope after a project ends, and workflows that quietly inherit more permission than the job requires. That matters because GitHub is not just a code host; it is also where secrets, releases, deployment hooks, and automation privileges converge.
When permissions widen without review, the organisation loses the ability to explain who can read code, alter workflows, or reach release paths. That is exactly how low-friction collaboration becomes long-lived exposure. Recent NHIMG research on secrets exposure shows why this is more than a theoretical concern: the State of Secrets Sprawl 2025 found that 4.6% of public GitHub repositories contain at least one hardcoded secret. In practice, teams usually discover this drift only after an audit, a misuse event, or an unexpected workflow change has already widened the blast radius.
How Least-Privilege Drift Shows Up in Practice
The clearest signal is a mismatch between current work and current access. If a contributor only touches one repository but still holds org-wide rights, or if a bot can create releases even after its task was narrowed, the access model is no longer describing reality. That is where GitHub drift starts: entitlements outlive the reason they were granted.
Security teams should look for these mechanics:
- Admin or maintainer roles that persist after team changes, project handoffs, or re-orgs.
- Personal access tokens or fine-grained tokens that never expire or are not reviewed on a schedule.
- Repository, team, and org memberships that were added for temporary work and never removed.
- GitHub Actions permissions that allow broader write, secrets, or environment access than the workflow needs.
- Branch protection, secret access, and deployment approvals that differ from the intended baseline across similar repos.
The control problem is not only “too many users.” It is also too much authority in automation. A workflow that can read secrets, push artifacts, and trigger downstream jobs may be doing exactly what it was once designed to do, while no longer matching the least-privilege intent. For that reason, GitHub review should compare effective access against actual job function, not just against role names.
NHIMG’s Shai Hulud npm malware campaign and the Salesloft OAuth token breach both underscore the same lesson: when token scope and repository access drift upward, attackers do not need novel technique, only time and leftover privilege. Current guidance suggests mapping GitHub permissions to the smallest real task boundary and reviewing that mapping after every repo, team, or workflow change. These controls tend to break down in fast-moving engineering orgs that use shared automation across many repositories because inherited permissions become hard to attribute and harder to revoke.
Common Edge Cases That Hide the Drift
Tighter GitHub access control often increases operational overhead, requiring organisations to balance developer speed against review discipline. That tradeoff is real, especially in environments where release engineering, security automation, and platform operations share the same repositories.
Some cases are easy to misread. A dormant admin account may be a break-glass role, not a failure. A broad team membership may be legitimate if the repository spans multiple product lines. A long-lived token may exist because a legacy integration has not yet been modernised. The key question is whether the exception is documented, time-bounded, and actively reviewed.
There is no universal standard for this yet, but best practice is evolving toward proof of need at runtime rather than blanket trust in standing roles. For GitHub, that means periodic entitlement review, expiration by default for tokens, and workflow permissions set explicitly instead of inherited indirectly. It also means treating repository sprawl as an access problem, not just an organisational one.
Where teams often get tripped up is cross-functional automation. Security approves a baseline, platform teams clone it for speed, and repositories diverge until no one can tell which permissions were intentional. That is why least privilege drift often appears first in exceptions, then in automation, and only later in human roles. The real warning sign is not merely excess access, but access that no longer has a clear owner or business justification.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Least-privilege drift often comes from stale NHI entitlements and over-scoped tokens. |
| NIST CSF 2.0 | PR.AC-4 | This control addresses access management and privilege limitation across systems. |
| NIST SP 800-63 | AAL2 | Token and privileged access governance depends on strong identity assurance and session control. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification instead of assuming repo access remains valid. | |
| NIST AI RMF | GOVERN | Governance is needed to keep automated GitHub access aligned with policy and accountability. |
Inventory GitHub non-human identities and remove any standing access not tied to an active task.
Related resources from NHI Mgmt Group
- What are the signs that legacy access controls are failing in a hybrid IT environment?
- What are the signs that application access token controls are failing?
- Who is accountable when temporary third-party access is granted without proper privilege controls?
- What are the signs that privileged access controls are failing in a distributed IT environment?
