TL;DR: GitHub IGA tools often stop at the identity provider, leaving outside collaborators, personal access tokens, and GitHub Actions workflows outside continuous governance, according to Oleria Security. The result is repository-level access that can bypass SSO, accumulate scope, and evade review unless teams govern GitHub as a living identity surface, not a directory-only problem.
At a glance
What this is: This is an analysis of GitHub identity governance gaps, showing that repository access, tokens, and workflows create a control surface that directory-only IGA cannot fully certify.
Why it matters: It matters because IAM and PAM teams need evidence-based control over developer access, contractor access, and non-human repository permissions, not just IdP membership.
Context
GitHub identity governance fails when teams treat the identity provider as the boundary of control. Repository access, outside collaborators, personal access tokens, SSH keys, and workflow permissions all create a separate access plane inside the development platform, and that plane can outlive the directory record that originally approved it.
The practical issue is not whether access exists, but whether it is continuously attributable, scoped, and reviewable. When GitHub becomes a code execution surface as well as a collaboration surface, governance has to track people, tokens, and automation together rather than assuming a single SSO control point is enough.
Key questions
Q: What breaks when GitHub access reviews stop at the identity provider?
A: You lose sight of the effective repository entitlement. Outside collaborators, inherited team permissions, personal access tokens, and workflow rights can still grant real access even when directory records look clean, so certification becomes incomplete and stale access survives longer than the review cycle. Teams need repository evidence, not just IdP membership, to validate access.
Q: Why do personal access tokens create more governance risk than standard SSO access?
A: Because they can outlast the interactive session and bypass the controls tied to login events. A token can keep working after a user changes role, leaves a project, or stops needing access, which turns a momentary approval into a standing credential problem. That is why token scope and expiration matter as much as the account itself.
Q: How should security teams govern GitHub Actions in high-trust repositories?
A: Treat GitHub Actions as privileged automation, not background glue. Restrict event triggers, review command interpolation, separate build and release permissions, and limit which tokens are exposed to each workflow. If a workflow can write code, secrets, or artefacts, it needs the same review discipline as a privileged account.
Q: How do teams know whether GitHub access is actually being used?
A: Compare current repository permissions with audit activity over time. Access that has not been used for weeks or months is a strong signal that the entitlement is stale, over-scoped, or no longer tied to business need. The best test is not whether the access was granted correctly, but whether it still has an active purpose.
Technical breakdown
Why IdP-centric governance misses repository entitlements
Identity governance and administration tools are usually built around provisioning states in the identity provider, but GitHub permissions are expressed inside the platform. Repository roles, team inheritance, outside collaborators, and app permissions can all diverge from the directory record that originally authenticated the user. That creates a split between who the organisation thinks has access and who can actually read, write, or execute in a repository. The problem is structural: repository access is enforced at the platform layer, while most governance evidence still lives at the IdP layer. See the IGA Buyer's Guide.
Practical implication: certify GitHub access from repository evidence, not from directory membership alone.
How personal access tokens and Actions workflows bypass human-centric controls
Personal access tokens and GitHub Actions tokens extend authority into automation and developer workflows, often outside the moment of interactive sign-in. If a token is long-lived, over-scoped, or never reviewed, it becomes a standing credential that can keep functioning after the user account changes. Workflows add another layer because execution rights can persist independently of the human who configured them. That means the real security question is not who logged in, but which identities and workflows can still act on behalf of the organisation after authentication has ended. Read Guide to the Secret Sprawl Challenge.
Practical implication: govern repository tokens and workflow permissions as non-human identities with their own lifecycle.
What continuous GitHub identity graphs change for governance
A continuous identity graph links members, outside collaborators, tokens, keys, apps, and audit events into one view of effective access. That matters because GitHub risk is not static. Contractors leave, scopes drift, and workflow permissions age into privilege that no longer matches current work. Continuous correlation between entitlement data and audit activity gives security teams a way to separate active access from stale access and to see which controls are actually enforced at the repository level.
Practical implication: use audit activity plus entitlement mapping to find access that no longer has operational justification.
Threat narrative
Attacker objective: The objective is to retain or extend repository-level access beyond the organisation's intended review and approval boundaries.
- Entry occurs when repository access is granted through outside collaboration, personal access tokens, or GitHub App permissions rather than through the identity provider alone.
- Credential access persists when long-lived tokens or workflow permissions remain active after the original business need has ended, giving the actor continued use of the repository surface.
- Escalation happens when over-scoped tokens, write-capable apps, or non-read-only workflow tokens expand what the identity can do inside the code environment.
- Impact is repository misuse, code access beyond intended scope, or automation acting with privileges that are no longer justified by current governance.
Breaches seen in the wild
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Repository governance is now a control-plane problem, not a directory problem. GitHub access decisions can be true in the identity provider and still false in the repository. That split matters because contractor access, team inheritance, and app permissions all operate below the directory layer, where traditional IGA checks do not see the effective entitlement state. Practitioners should treat repository authorization as a first-class governance domain, not as an extension of SSO.
Personal access tokens create a standing-credential model that undermines periodic review. If a token can outlive the session, the project, or the user role that justified it, then certification becomes a lagging signal. The governance gap is not just token inventory. It is the assumption that repository authority will still be visible and reviewable when a human approver comes back to look at it.
GitHub Actions and related automation turn repository access into non-human identity governance. Once workflows can read, write, or publish on behalf of the organisation, the subject of control is no longer only the developer. That shifts the problem into NHI lifecycle, privilege scope, and offboarding. Key NHI security challenges are present here because the hidden failure mode is unmanaged execution rights that continue after the human owner changes.
Continuous access certification only works if the evidence is operational, not declarative. Comparing repository roles against audit activity exposes the difference between access that exists on paper and access that is actually used. That is the right control model for GitHub because the risk is accumulation, not just initial assignment. Security teams should expect the highest-value findings to come from stale collaborators, stale admins, and workflow permissions that no longer match current use.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Repository governance has to move from point-in-time approval to continuous entitlement verification. GitHub permissions, tokens, and workflows change faster than most access review cycles. If the operating model still assumes directory membership is the source of truth, then the programme will miss the most important control question, which is who can still act inside the repository right now.
GitHub is a useful proxy for the broader non-human identity problem in engineering organisations. The same pattern appears wherever developer platforms mix people, automation, and externally granted access. Teams that solve repository entitlement drift are also building the control patterns they will need for broader workload identity and agent governance later.
For practitioners
- Audit repository-level effective access Compare members, teams, outside collaborators, and app permissions against what the identity provider says should exist, then resolve mismatches at the repository layer.
- Inventory long-lived developer tokens Find personal access tokens and SSH keys with missing or long expiration dates, then classify them by scope, owner, and last observed activity.
- Review workflow and app permissions Identify GitHub Actions workflows, deploy keys, and installed GitHub Apps that hold write or admin rights, and downscope anything that does not need those rights. See the CI/CD Pipeline Identity Security Guide.
- Certify access against actual usage Use audit log activity to find repository access that has not been used for 30, 60, or 90 days, then remove it or require re-approval.
- Separate human and non-human governance Assign token, workflow, and app permissions their own lifecycle and offboarding checks instead of folding them into human account reviews.
Key takeaways
- GitHub governance fails when teams certify only the identity provider and ignore the repository-level access plane.
- Tokens, collaborators, and workflows can persist after the original business need has ended, creating stale authority.
- The strongest control move is continuous entitlement verification against actual repository usage and audit evidence.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Key Challenges and Risks · Guide to the Secret Sprawl Challenge · CI/CD Pipeline Identity Security Guide · IGA Buyer's Guide
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 MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Outside collaborators and contractors can retain repository access after work ends. |
| NHI-02 — Secret Leakage | PATs, SSH keys, and workflow secrets create exposed credential paths inside GitHub. | |
| NHI-05 — Overprivileged NHI | GitHub Apps and tokens can carry write or admin rights beyond operational need. | |
| Recommendation — Revoke repository access immediately when the business relationship ends and verify no workflow permissions remain. Inventory and rotate exposed repository secrets and tokens before they become persistent access paths. Downscope GitHub App and token permissions to the minimum repository rights required for the task. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Repository permissions must be continuously governed as effective entitlements, not just IdP records. |
| Recommendation — Continuously validate GitHub entitlements against actual repository access and remove mismatches. | ||
| CIS Controls v8 | CIS-5 — Account Management | GitHub collaborators, admins, and automation identities all need lifecycle governance. |
| Recommendation — Apply account management discipline to GitHub users, collaborators, tokens, and apps. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Long-lived tokens and workflow permissions can support credential abuse and movement across repositories. |
| Recommendation — Map GitHub token abuse to credential access and lateral movement tactics in detection and response. | ||
Key terms
- Repository Effective Access: The permissions a user, token, app, or workflow can actually exercise inside a repository, regardless of what the directory says. In GitHub environments, effective access is the only state that matters for governance because team inheritance, outside collaborators, and automation can all expand privilege beyond the original approval.
- Personal Access Token (PAT): A personal access token is a reusable credential that authenticates a user or service to an API without a password. In practice, it inherits the permissions of the owning identity, which makes it a high-value non-human identity when it is exposed, copied, or left valid after the original task is complete.
- Workflow Permissions: Workflow permissions are the access rights that GitHub Actions and related automation receive when they run. They determine what a workflow can read, update, approve, or deploy. Tight control matters because overbroad workflow permissions can let automated jobs access secrets, alter code paths, or interfere with CI/CD operations.
- Continuous access certification: Continuous access certification is the practice of validating whether active permissions are still justified using current entitlement data rather than periodic snapshots. It is especially useful when access changes quickly, because it ties review outcomes to live governance state instead of stale reports.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org