TL;DR: Unosecur says GitHub has become an enterprise IAM blind spot because tokens, service accounts, shadow admins, SSO bypasses, and privilege drift now sit inside the software supply chain, not just the IAM console. That shifts governance from periodic review to continuous identity visibility across code, pipelines, and repositories.
At a glance
What this is: Unosecur’s announcement argues that GitHub identity sprawl is now an enterprise IAM problem because users, bots, tokens, and secrets can drift outside policy inside repositories and developer workflows.
Why it matters: IAM, IGA, and PAM teams need to treat code platforms as identity control surfaces because access drift and hidden credentials can create production risk outside the traditional console.
👉 Read Unosecur's announcement on GitHub identity blind spots and native integration
Context
GitHub identity blind spots emerge when the place where code is written, reviewed, and merged also becomes the place where credentials, tokens, and privileged access accumulate. In that model, the governance problem is not limited to the IAM console because developer workflows can create shadow access paths that sit outside normal review cycles.
For IAM and identity-security programmes, the practical issue is visibility across repositories, bots, secrets, and service accounts, not just user accounts. Once those identities live in code platforms, entitlement review, offboarding, and privilege monitoring have to follow the workflow where access is actually created and used.
Key questions
Q: What breaks when GitHub identities are outside the IAM programme?
A: IAM loses sight of the identities that actually create production access. Orphaned tokens, service accounts, and shadow admins can persist in repositories even when the central directory looks clean, so governance must extend to code platforms to avoid a false sense of control.
Q: Why do repository tokens and service accounts increase enterprise risk?
A: They create effective access that can outlive the business need that justified it. When tokens and service accounts live in code workflows, privilege drift and offboarding failures can expose production systems even if human accounts are already managed.
Q: How can security teams tell whether GitHub identity governance is working?
A: They should see repository identities, secrets, and privileged access reconciled against policy in near real time, with fewer orphaned accounts, fewer SSO bypasses, and faster remediation of drift. If those signals still appear in code platforms, governance is incomplete.
Q: What is the difference between developer workflow visibility and IAM dashboard visibility?
A: IAM dashboards show governed entitlements as they are intended to exist, while developer workflow visibility shows how access is actually created, stored, and used inside repositories. Teams need both views because a clean directory does not prove clean repository access.
How it works in practice
Why GitHub becomes an identity control surface
GitHub is not just a source-code system when access tokens, service accounts, bot identities, and secrets are created or stored there. That makes it an identity control surface where policy enforcement, authentication signals, and privileged access can diverge from the central IAM record. The hard part is that repository activity changes faster than traditional certification cycles, so identity state in GitHub can drift before a governance team notices.
Practical implication: Treat GitHub as part of the identity estate, not as a separate developer tool.
What access sprawl looks like in repositories
Access sprawl in GitHub shows up as orphaned accounts, shadow admins, non-MFA logins, SSO bypasses, and privilege drift against corporate policy. These are not isolated hygiene problems. Together they create a second access graph alongside the formal IAM programme, which means a user can appear governed in one system while retaining effective power in another.
Practical implication: Map repository-level privileges and secrets to the same ownership model used for IAM and PAM.
Why agentless visibility matters for GitHub governance
Agentless integration matters because the control objective is to observe identity behaviour without altering developer workflows or build pipelines. Read-only connectivity can surface users, bots, tokens, and secrets quickly, which is useful when the main risk is hidden identity exposure rather than a missing security agent. The architecture is about reducing blind spots and correlating repository signals with cloud-native identity events.
Practical implication: Prioritise visibility-first controls that can inventory GitHub identities before enforcing tighter policy.
NHI Mgmt Group analysis
GitHub now functions as an identity lifecycle system, not just a development platform. Tokens, service accounts, and secrets created in repositories are part of the identity estate whether or not the IAM team models them that way. The governance consequence is that offboarding, privilege review, and entitlement monitoring must extend into developer workflows or they will miss the identities that matter most.
Repository sprawl creates a parallel privilege plane. When shadow admin accounts, SSO bypasses, and orphaned tokens exist outside the main console, the organisation is effectively operating two access models at once. That weakens least-privilege enforcement because the policy system and the execution system no longer describe the same reality.
Continuous visibility is the named concept that matters here. The article’s central problem is not GitHub itself but the gap between policy intent and where identity state is actually created and consumed. Once code platforms become production pathways, practitioners need a continuous identity view that spans repositories, cloud consoles, and service access.
Identity security is moving to the point of creation. The useful governance shift is away from periodic reconciliation after access has already spread. For IAM, IGA, and PAM teams, the operational question is whether they can detect identity drift at the moment it appears in repositories and pipelines, before it becomes standing access.
Unified governance is now a cross-environment requirement. If cloud identities, developer identities, and repository identities are handled in separate silos, the organisation will keep inheriting blind spots at every handoff. The practitioner conclusion is simple: governance has to follow the workflow, not just the directory.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Identity Convergence Guide
What this signals
Continuous identity visibility: GitHub changes the control point from post-hoc review to live observation of where credentials and privileged access are created. IAM teams that still treat repositories as outside the identity estate will keep missing the access paths most likely to reach production.
The practical shift is toward converged governance across human identities, non-human identities, and developer workflows. If repository activity is not correlated with cloud and identity signals, privilege drift will keep hiding in plain sight.
For practitioners
- Inventory GitHub identities as part of the enterprise identity estate Capture users, bots, tokens, secrets, and privileged repository accounts in the same ownership model used for workforce and machine identities.
- Reconcile repository access against corporate policy Check for orphaned accounts, shadow admins, non-MFA logins, SSO bypasses, and privilege drift across active repositories.
- Correlate GitHub findings with cloud identity signals Use a unified view so repository-level access anomalies can be investigated alongside cloud-native identity events and entitlement changes.
- Extend offboarding into code platforms Remove lingering tokens, service accounts, and elevated repository permissions when people, bots, or integrations no longer need access.
Key takeaways
- GitHub repositories now function as identity infrastructure when tokens, bots, secrets, and service accounts can create production access.
- The visibility gap is real, and Unosecur frames it as a mismatch between IAM records and the way access is actually created inside code workflows.
- Security teams should bring repository identities into the same governance, offboarding, and privilege-monitoring processes they already use for the broader identity estate.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | GitHub repositories are a common place for tokens and secrets to drift into unmanaged exposure. |
| NHI-05 — Overprivileged NHI | Shadow admins and privilege drift are the central governance concerns in the announcement. | |
| NHI-09 — NHI Reuse | The article describes identities and credentials following code workflows beyond their original governance context. | |
| Recommendation — Inventory repository secrets continuously and revoke any exposed credentials as soon as they are discovered. Review repository identities for excess privilege and align them to least-privilege ownership. Track reused tokens and service accounts across repositories, pipelines, and cloud platforms. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is entitlement drift across GitHub and the wider identity estate. |
| Recommendation — Apply entitlement governance to GitHub identities and reconcile them with enterprise access policy. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The announcement is fundamentally about credentials in code environments enabling broader access paths. |
| Recommendation — Map repository secrets and token exposure to credential access and lateral movement scenarios. | ||
Key terms
- Repository Identity: An identity that can read, write, trigger, or authenticate through a code repository or its connected automation. It may be human, bot, token, or service account. The key governance issue is not where it lives, but whether its permissions are owned, reviewed, and revoked on time.
- Privilege Drift: Privilege drift is the gradual gap between the permissions an identity was meant to have and the permissions it actually retains. In AI agent environments, drift grows quickly because roles are reused, tasks change, and lifecycle reviews often lag behind deployment velocity.
- Shadow admin: A shadow admin is an account or role with elevated privileges that exists outside normal governance, monitoring, or approval workflows. These accounts often appear through cloud sprawl, delegated access, or temporary exceptions, and they create hidden pathways for misuse, accidental overreach, or compromise.
- Unified Identity Fabric: A unified identity fabric is a control model that connects identity data, policy, and response across different identity types in one operating view. It does not remove the need for separate lifecycle rules, but it can reduce blind spots if ownership, inventory, and remediation are consistent.
What's in the full announcement
Unosecur's full announcement covers the operational detail this post intentionally leaves for the source:
- How the native GitHub integration inventories users, bots, tokens, and secrets inside repositories
- The specific identity signals it flags, including orphaned accounts, non-MFA logins, SSO bypasses, and privilege drift
- How read-only OAuth deployment is positioned to avoid disrupting build pipelines and developer productivity
- What early deployments claim about mean time to remediate identity threats across GitHub and cloud environments
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 June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org