GitHub Org Access Review
The blast radius of a compromised GitHub identity is set long before the compromise — by how many owners you have, whether SSO and 2FA are enforced, how tightly tokens and third-party apps are governed, and whether access ends when people leave. Fill the short worksheet, work through the controls, and get a weighted score, an owner-count advisory, the prioritised gaps and an export. Controls tagged LiteLLM each limit how far an identity compromise can spread. Nothing is uploaded.
Fill the short worksheet and mark each access control Yes / Partial / No. Controls tagged LiteLLM each limit how far an org-identity compromise can spread. Everything is scored in your browser — no org data is read or uploaded.
Worksheet
Owners & privileged roles
Fewer owners, each strongly authenticated, reviewed regularly.
- Org owners kept to a minimal, named setLiteLLMcritical
Every owner is a standing org-takeover risk if compromised. Keep the count low and know exactly who they are and why.
- Every owner uses phishing-resistant 2FA (hardware key)LiteLLMhigh
Owners are the highest-value accounts; a phishable factor on an owner is the whole org's weakest link.
- Owner / admin access reviewed on a schedulehigh
Privileged access accumulates. A recurring review removes owners who no longer need it before it is abused.
- Break-glass owner account documented and monitoredmedium
An emergency owner account should exist deliberately, be tightly controlled, and alert loudly whenever it is used.
Authentication & SSO
Tie org access to your identity provider and strong factors.
- SAML SSO enforced for the organisationLiteLLMhigh
Enforced SSO ties org access to your IdP, so disabling someone centrally cuts their access and sessions are governed by IdP policy.
- 2FA required org-wide (enforced, not encouraged)high
Requiring 2FA for every member removes password-only accounts as an entry point.
- PATs and SSH keys authorized against SSOLiteLLMhigh
With SSO, personal access tokens and SSH keys must be explicitly authorized to access org resources — unauthorized ones are blocked.
Tokens & third-party access
Prune standing tokens and the apps acting on your behalf.
- Dormant PAT / token review (revoke unused)LiteLLMhigh
A token nobody uses is pure risk. Regularly find and revoke PATs, deploy keys and app tokens that have gone idle.
- Fine-grained PAT approval policy; restrict classic PATsmedium
Classic PATs are account-wide and coarse. An org policy can require approval for fine-grained tokens and restrict or ban classic ones.
- Third-party OAuth app access restricted (allowlist)LiteLLMhigh
Without restriction, any member can authorize an external OAuth app against org data. An allowlist keeps the set of apps acting on your behalf known and small.
- Installed GitHub Apps and their permissions reviewedmedium
Installed Apps hold scoped tokens continuously. Review which are installed, on which repos, with which permissions.
Lifecycle & offboarding
Make access end when the relationship does — automatically.
- SCIM automated deprovisioning on IdP removalhigh
SCIM removes a person's org access automatically when they are deprovisioned in the IdP, closing the offboarding gap that manual processes miss.
- Outside collaborators reviewedmedium
Outside collaborators sit outside SSO/SCIM and are easy to forget. Review who has repo access from outside the org.
- Audit log streaming enabledmedium
Streaming the org audit log to your SIEM means access changes and token events are retained and alertable, not just visible for a window in the UI.
Prioritised gaps (14)
- 1.criticalLiteLLMNot assessed
Org owners kept to a minimal, named set
Fix: Reduce owners to the smallest workable number of named people; downgrade the rest to the least role that covers their job.
- 2.highLiteLLMNot assessed
Every owner uses phishing-resistant 2FA (hardware key)
Fix: Require WebAuthn/FIDO2 for all owners and remove weaker factors from those accounts.
- 3.highNot assessed
Owner / admin access reviewed on a schedule
Fix: Run a documented owner/admin access review at least quarterly and record the decisions.
- 4.highLiteLLMNot assessed
SAML SSO enforced for the organisation
Fix: Enforce SAML SSO org-wide and remove members who cannot authenticate through the IdP.
- 5.highNot assessed
2FA required org-wide (enforced, not encouraged)
Fix: Turn on "Require two-factor authentication" for the organisation and resolve any members it would remove.
- 6.highLiteLLMNot assessed
PATs and SSH keys authorized against SSO
Fix: Require SSO credential authorization so every PAT/SSH key touching org data is explicitly approved, and revoke stale authorizations.
- 7.highLiteLLMNot assessed
Dormant PAT / token review (revoke unused)
Fix: Review token activity, revoke anything dormant, and set expiries so tokens age out automatically.
- 8.highLiteLLMNot assessed
Third-party OAuth app access restricted (allowlist)
Fix: Turn on OAuth app access restrictions and approve only the apps you have reviewed.
- 9.highNot assessed
SCIM automated deprovisioning on IdP removal
Fix: Enable SCIM so IdP deprovisioning revokes GitHub access and sessions automatically.
- 10.mediumNot assessed
Break-glass owner account documented and monitored
Fix: Define a break-glass owner, store its credential securely, and alert on any use.
Scored entirely in your browser — nothing is read or uploaded. Control themes follow GitHub's organisation security documentation (SSO, 2FA, credential authorization, OAuth-app restrictions, SCIM, audit log streaming). Educational — not affiliated with GitHub.
What this review is
- A GitHub organisation access review: a short worksheet (owner count, member count) plus a scored checklist of the owner/admin, authentication, token and lifecycle controls that decide how far one compromised identity can reach.
- Fourteen controls across four areas — owners & privileged roles, authentication & SSO, tokens & third-party access, and lifecycle & offboarding — each with a severity and a concrete fix.
- The worksheet flags an over-large owner set, since every org owner is a full org-takeover risk if their credential is stolen.
- Controls tagged "LiteLLM" each limit how far an org-identity compromise can spread: minimal owners, enforced SSO, credential authorization, dormant-token review and OAuth-app restrictions.
- Mark each Yes / Partial / No for a weighted 0–100 score, prioritised gaps and an exportable report. 100% client-side — no org data read or uploaded.
Why this matters
The October 2026 LiteLLM GitHub-identity supply-chain compromise, as publicly reported, pivoted through an org-owner identity. Owner is the role that can change security settings, add and remove members, and reach every repository — so a single stolen owner credential is close to game over. The number of owners you keep, and how strongly each is protected, is a decision you make in advance about how bad a bad day can get.
A tight access posture shrinks that radius without stopping a single credential from leaking. Fewer, hardware-key-protected owners means fewer takeover-grade accounts to steal. Enforced SSO and credential authorization mean a stray personal access token cannot quietly act on the org, and give you a central kill switch. Pruning dormant tokens and unreviewed OAuth apps removes reach an attacker would otherwise inherit for free, and SCIM deprovisioning closes the offboarding gap that manual processes miss. Access review is not one-and-done — it is a recurring habit, which is why this tool exports a report you can re-run and compare. This is an educational self-assessment referencing a real, reported incident for context; PlayCISO is not affiliated with LiteLLM or GitHub.
Frequently asked questions
How many org owners is too many?
There is no single number, but each owner is a standing org-takeover risk: an owner credential can change security settings, add or remove members, and reach every repository. The worksheet flags owner counts above five and a high owner-to-member ratio, because the practical answer is "the fewest people who genuinely need it, reviewed on a schedule." Most organisations can operate with a small handful of named owners and give everyone else the least role that covers their work.
Why does enforced SSO and credential authorization matter so much?
Enforcing SAML SSO ties org access to your identity provider, so when someone is disabled centrally their GitHub access and sessions are governed by that. Credential authorization goes further: with SSO, every personal access token and SSH key must be explicitly authorized to touch org resources, and you can revoke that authorization. Together they shrink the set of credentials that can reach your org and give you a central kill switch — which is exactly what you want when an identity is compromised.
What should a dormant-token review look for?
Personal access tokens, deploy keys and app tokens that have not been used recently, tokens with no expiry, and tokens with far broader scope than their use requires. Each idle token is reach an attacker inherits for free if it leaks. Revoke what is unused, set expiries so tokens age out on their own, and prefer fine-grained tokens or GitHub Apps over broad classic PATs.
How does this relate to the LiteLLM incident?
The October 2026 LiteLLM compromise, as publicly reported, pivoted through an org-owner identity. A tight access posture limits that blast radius: fewer owners means fewer takeover-grade accounts to steal; enforced SSO and credential authorization mean a stray token cannot quietly act on the org; dormant-token and OAuth-app review removes standing reach before it is abused. None of these stop a credential from leaking, but they decide whether one leaked identity is a contained problem or an organisation-wide one. This tool references a real, reported incident for context and is not affiliated with LiteLLM or GitHub.
Does any of my input leave the browser?
No. The worksheet and checklist are scored entirely client-side. Nothing is read from GitHub and nothing is uploaded; the only output is the report you choose to copy or download.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.