How should security teams govern GitHub Apps and personal access tokens across multiple organisations?

Why This Matters for Security Teams

GitHub Apps and personal access tokens are not just convenience features, they are distributed identities that can outlive the people, repos, and orgs that created them. In multi-organisation environments, the risk is rarely one obvious compromise. It is usually accumulated over-permissioning, forgotten installs, and tokens that continue to work long after the original use case has changed. That makes them a classic non-human identity governance problem, not merely a source control hygiene issue.

Security teams need to treat every App installation and PAT as an inventory item with an owner, scope, expiration, and business purpose. Without that, access reviews become subjective, and the same credential can be trusted differently by different organisations. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward asset visibility, access governance, and continuous monitoring as foundational controls.

NHIMG research shows the scale of the problem is not theoretical: in The State of Non-Human Identity Security, 85% of organisations reported they lack full visibility into third-party vendors connected via OAuth apps. In practice, many security teams discover token sprawl only after an integration has already been used outside its intended boundary.

How It Works in Practice

Effective governance starts with building a cross-organisation registry that normalises the identity of each GitHub App and PAT, then maps it to the orgs, repositories, and workflows where it is authorised. That registry should capture who owns the credential, what it can do, when it was issued, when it was last used, and whether its permissions match the minimum necessary access. For GitHub Apps, review both the installation context and the granted repository set. For PATs, distinguish between classic tokens and fine-grained tokens, because the revocation and scope model differs materially.

From there, apply policy at the level of use, not just issuance. A PAT that is valid across multiple organisations should be flagged if it is being used in a repo it was never approved for. A GitHub App should be re-evaluated when a new repository is added or when a workflow begins calling broader APIs than before. This is where continuous monitoring matters more than quarterly reviews. The Guide to the Secret Sprawl Challenge is a useful reminder that hidden credentials often persist because no one owns the cleanup path.

• Require a named business owner for every App and PAT.
• Set explicit scope baselines for each organisation, repository type, and workflow.
• Revoke or rotate credentials automatically when the owner changes or use stops.
• Log token use centrally so cross-org access is auditable.
• Prefer GitHub Apps over PATs where automation can support it, because Apps are easier to scope and control.

Control design should also reflect credential blast radius. A PAT used for one org should not silently inherit trust in another simply because both are under the same enterprise umbrella. These controls tend to break down when multiple organisations share automation accounts, because ownership and approval records no longer line up with actual runtime use.

Common Variations and Edge Cases

Tighter token governance often increases operational overhead, requiring organisations to balance developer velocity against auditability and revocation discipline. That tradeoff is most visible in shared platform teams, external contractors, and merger environments where one person may legitimately need access across several orgs. Best practice is evolving here, and there is no universal standard for how much cross-org reuse should be allowed without separate approval.

One common edge case is the GitHub App that is intentionally installed across many organisations. In that situation, the security question is not whether the App exists, but whether each installation is separately justified, minimally scoped, and independently monitored. Another edge case is service accounts that still rely on PATs because a legacy integration has not been migrated. Those credentials should be placed on a shorter review cycle and tracked as exceptions with an explicit expiry date.

Two recent NHIMG case studies help illustrate why this matters: Salesloft OAuth token breach and GitHub Dependabot Breach. Both show how trusted integrations can become exposure paths when scope and lifecycle controls lag behind operational reality. The practical rule is simple: if the credential can act in more than one organisation, it needs more than one line of approval history.

Related resources from NHI Mgmt Group

• How should security teams govern open finance access across multiple organisations?
• How should security teams monitor personal access tokens across inventory and audit logs in GitHub environments?
• How should security teams delegate access governance across large engineering organisations without creating cross-team risk?
• How should security teams reduce identity risk when access is spread across multiple systems and policies are applied inconsistently?