GitHub first-party sessions create a standing access risk for IAM

At a glance

What this is: The article explains how GitHub first-party sessions, OAuth authorizations, and access tokens create standing access risk when they remain active after compromise or role change.

Why it matters: IAM, PAM, and NHI teams need to treat these credentials as live access paths, because token revocation, offboarding, and detection only work if they happen before misuse.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Exaforce's analysis of GitHub first-party sessions and token revocation

Context

GitHub first-party sessions are a form of standing access: once a user or app authenticates, the resulting bearer credential can continue to operate until it is revoked. That matters for GitHub session governance, OAuth authorisations, and personal access tokens because the access path often outlives the moment that created it.

The security gap is not authentication alone, but lifecycle control. If a token leaks, a device is lost, or an employee leaves, the organisation needs to be able to identify, revoke, and replace the credential quickly enough that the session never becomes an attacker-controlled persistence mechanism.

For identity programmes, this is a classic NHI problem with human entry points. The credential may originate from a person, but once issued it behaves like a non-human identity with persistent authority unless lifecycle and revocation controls are enforced.

Key questions

Q: How should security teams govern GitHub non-human identities?

A: Security teams should govern GitHub non-human identities as a single entitlement surface, not as separate repository settings. That means inventorying machine users, tokens, keys, apps, and secrets together, assigning ownership, and enforcing expiry and recertification so access can be retired when the workflow changes.

Q: Why do GitHub tokens remain risky after MFA is enabled?

A: Because MFA protects the login event, not the ongoing use of a token already issued. Once the bearer credential exists, whoever holds it can act with its scopes until it is revoked or expires. That is why stolen, cached, or consented tokens remain dangerous even in strong authentication environments.

Q: What breaks when GitHub token revocation is delayed?

A: The attacker keeps using the valid credential window for as long as it remains active. Delay lets the compromise turn into repository access, commit manipulation, or further lateral movement through connected tooling. In practice, delayed revocation turns a recoverable incident into a persistence problem.

Q: Who is accountable for revoking GitHub app authorisations after compromise?

A: The identity or platform team should own the control, but accountability must be shared with the application owner and incident response lead. If authorisations are not revocable within the containment process, the organisation has delegated too much trust to a session that no longer has a valid business purpose.

Technical breakdown

Why GitHub sessions behave like bearer credentials

GitHub sessions, OAuth grants, and tokens are bearer credentials, which means possession is sufficient for use. There is no separate user challenge at request time, so the API treats the token holder as the authorised principal until the token is revoked or expires. That model is convenient for automation, but it also means the security boundary shifts from authentication to token custody. If the secret is copied, the access is copied with it. The practical risk is not just compromise, but persistence after compromise.

Practical implication: inventory every GitHub bearer credential and treat each one as live access that needs lifecycle ownership.

How first-party app flows widen the credential surface

GitHub Apps and OAuth Apps create multiple token forms, including user-to-server tokens, installation tokens, and user authorisations. Each has its own scope, lifetime, and revocation path, which makes the environment harder to govern than a single login session. The article’s core point is that first-party or familiar-looking flows can still deliver attacker-usable access if users approve them or if the resulting tokens are stored insecurely on endpoints. The presence of an official workflow does not remove the identity risk.

Practical implication: classify GitHub app grants and session types separately so revocation and monitoring are matched to the right credential path.

Why revocation is the control that matters most

Revocation is the fastest way to invalidate a stolen or stale credential because it ends the bearer relationship immediately. Expiration helps reduce exposure window, but revocation is what cuts off access after detection, offboarding, or suspected phishing. In lifecycle terms, it is the control that converts a standing token from an active path into an inert artefact. Without reliable revocation, even strong detection only tells you that an attacker may already be acting inside the valid session window.

Practical implication: build revocation into incident response, offboarding, and suspicious-credential workflows instead of treating it as an exceptional manual step.

Threat narrative

Attacker objective: The attacker wants durable account or repository access that survives initial authentication and can be used without needing the victim’s password or second factor.

1. Entry occurs when an attacker obtains a GitHub bearer credential through OAuth consent phishing, device code phishing, AiTM phishing, or endpoint token theft.
2. Escalation occurs when the stolen session or token is reused against GitHub APIs with the scopes and permissions already attached to it.
3. Impact occurs when the attacker clones private repositories, pushes malicious commits, opens pull requests, or persists until the token is revoked.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

GitHub token exposure is not a point-in-time event, it is a standing access problem. Once a bearer credential exists, the attacker does not need to defeat authentication again. The control question becomes whether the organisation can revoke, rotate, and audit that access before it is used. For IAM and NHI teams, the practical lesson is that lifecycle governance is the real boundary, not login success.

Bearer credential custody is the named risk concept here. GitHub sessions and tokens shift identity security from proving who authenticated to controlling who can keep using the credential after authentication. That is why leaked tokens, stored CLI credentials, and stale OAuth grants remain dangerous even when MFA is in place. Practitioners should treat custody of the token as the decisive security variable.

GitHub app grants expose the overlap between human IAM and NHI governance. A person authorises the app, but the resulting token behaves like an NHI with persistent authority. That means offboarding, recertification, and exception handling must follow the credential, not just the user account. The implication is that identity teams need shared lifecycle controls across humans and the non-human credentials they spawn.

Revocation is the control that makes detection actionable. The article is right to emphasise revoking tokens after compromise, because detection without shutdown leaves attackers inside the valid-use window. In governance terms, access review is too slow for a live bearer token unless it is paired with automated invalidation. Practitioners should therefore align alerting, incident response, and credential revocation as one workflow.

First-party branding does not reduce identity risk. Users trust familiar GitHub flows, but the access model remains the same: if a token is issued, it can be abused. That makes phishing-resistant authentication, scoped authorisation, and endpoint storage controls necessary, but not sufficient, because the core issue is the durability of granted access. Security programmes must evaluate the token, not the logo.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• For broader control design, the OWASP Non-Human Identity Top 10 maps token exposure, overprivilege, and rotation failures to concrete governance gaps.

What this signals

GitHub session governance is converging with NHI lifecycle management because the credential is the durable object, not the user login. That means organisations should expect more pressure to prove who owns a token, when it was issued, and how quickly it can be revoked when something looks wrong.

Bearer credential custody: this is the control concept practitioners should sharpen now. As teams adopt more automation around source control and developer tooling, they need lifecycle processes that can invalidate a credential before an attacker uses it, not after the next quarterly review.

The broader signal is that identity programmes need to unify offboarding, secret handling, and incident containment. If a GitHub token lives on a laptop, in a CLI cache, or behind an OAuth grant, the practical question is whether the organisation can end that access in minutes, not days.

For practitioners

• Inventory all GitHub bearer credentials Map OAuth grants, GitHub App authorisations, personal access tokens, and CLI-stored credentials to an owner, scope, and revocation path. Prioritise credentials that can reach private repositories or organization-level resources.
• Automate emergency revocation workflows Use detection alerts to trigger immediate token invalidation for suspected phishing, lost devices, employee exits, or leaked secrets. Make revocation part of the same incident workflow as containment and triage.
• Separate app grant review from user access review Review GitHub OAuth and app authorisations independently from human account recertification, because the credential may remain active after the user account looks clean. Tie each grant to a current business justification.
• Harden token storage on developer endpoints Move CLI tokens out of plaintext storage where possible and verify that local secret stores are actually in use. Check laptops, build hosts, and shared admin systems for cached GitHub credentials that can be reused offline.

Key takeaways

• GitHub sessions and tokens create standing access that survives the authentication moment and must be governed like live credentials.
• Detection alone is insufficient when bearer tokens remain valid, because the attacker can keep using them until revocation occurs.
• Identity teams need one lifecycle model for users, app grants, and developer credentials so revocation becomes immediate rather than exceptional.

Key terms

• Bearer Credential: A bearer credential is a secret that grants access to whoever possesses it, without requiring proof of the original user at every request. In SaaS and cloud environments, OAuth tokens, session cookies, and similar artifacts behave this way, which makes theft and replay a direct access path.
• Token Revocation: Token revocation is the ability to invalidate a credential before its natural expiry when it is exposed, misused, or no longer needed. For JWTs and other NHI credentials, revocation closes the gap between detection and continued access, which is essential when a stolen token can otherwise remain usable.
• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.

What's in the full article

Exaforce's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step revocation paths for GitHub OAuth grants, GitHub App authorisations, and personal access tokens.
• Endpoint storage locations for GitHub CLI credentials on Windows, Linux, and macOS.
• GitHub API calls used to list and revoke organisation credential authorisations.
• Detection event patterns that help distinguish ordinary login activity from suspicious token abuse.

👉 Exaforce's full post covers token storage paths, revocation endpoints, and detection details.

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 identity security programme, it is worth exploring.