GitHub Token Scope Analyzer
Not all GitHub credentials are equal. Pick a token type — classic PAT, fine-grained PAT, OAuth app, GitHub App installation, Actions GITHUB_TOKEN or gh CLI OAuth — toggle its scopes, and see the blast radius if it leaks, whether 2FA stands in the way (it does not — the second factor guards the login, not the token), and the least-privilege alternative. You never enter a real token; it all runs in your browser.
Never paste a real token anywhere, including here — this tool never asks for one. Pick a token type and toggle its scopes to see the blast radius if it leaks, whether 2FA/step-up stands in the way, and the least-privilege alternative. Runs entirely in your browser.
Classic personal access token (PAT)
A user-owned token with coarse, account-wide scopes. A scope like repo applies to EVERY repo the user can reach, not one.
A classic PAT authenticates API calls directly. GitHub's interactive "sudo mode" / 2FA step-up protects sensitive actions in the WEB UI session — it does not apply to token-based API calls. A stolen classic PAT performs its scoped actions with no second factor in the way.
Account-wide. Scopes are not repo-scoped, so even "just" repo reaches all of the user's private repositories. Not expirable by default historically — set an expiry.
Select the scopes this token carries to see exactly what an attacker could do with it.
Prefer a fine-grained PAT scoped to specific repositories with only the exact permissions needed, or a GitHub App. If you must use a classic PAT, set the shortest practical expiry and never grant admin:org or delete_repo unless genuinely required.
No token is entered or transmitted — this is a static explainer built from GitHub's own scope and permission documentation. Educational — not affiliated with GitHub.
What this tool does
- Pick a GitHub token type — classic PAT, fine-grained PAT, OAuth app, GitHub App installation, Actions GITHUB_TOKEN, or gh CLI OAuth — and toggle its scopes to see exactly what an attacker could do if the token leaked.
- Every scope carries a risk rating and a plain-English blast-radius note, drawn from GitHub's own scope and permission documentation.
- Spells out whether 2FA / interactive "sudo mode" step-up stands between a stolen token and a sensitive action — for every token type the answer is "no", because the second factor guards the login session, not token-based API calls.
- Calls out the LiteLLM lesson directly: a gh CLI OAuth token is NOT subject to re-authentication, so a stolen one can perform org-owner actions with no prompt and no second factor.
- No token is ever entered or transmitted. The whole thing runs in your browser as a static explainer with a copyable summary.
Why this matters
The October 2026 LiteLLM GitHub-identity supply-chain compromise turned on a credential, not a clever exploit. As publicly reported, a leaked key led to an org-owner gh CLI OAuth token. Because that token is not subject to the interactive 2FA / sudo step-up the web UI enforces, the attacker could act with the owner's full authority — exfiltrating CI secrets, publishing a release built from a fork source, deleting run records and force-pushing to cover the tracks — all without a single second-factor prompt.
The lesson is that the dangerous property of a token is not how it was created but how much it can do and how little stops it. A broad, long-lived credential on a developer's machine is a standing org takeover waiting to happen. Narrow the scope (a fine-grained PAT or a GitHub App over a classic PAT or a gh CLI token), shorten the lifetime, and keep owner-level access off everyday workstations — because once the token is stolen, 2FA has nothing left to protect. This is an educational explainer that references a real, reported incident for context; PlayCISO is not affiliated with LiteLLM or GitHub.
Frequently asked questions
Does 2FA protect a stolen token?
No. Two-factor authentication and GitHub's interactive "sudo mode" protect the login session in the web UI — they re-prompt a human before sensitive actions in the browser. A token (PAT, OAuth, installation, GITHUB_TOKEN or gh CLI) authenticates API calls directly and never triggers that step-up. Once an attacker holds a valid token, the second factor is already behind them. This is why token hygiene and least privilege matter more than 2FA for automation credentials.
Why is the gh CLI OAuth token singled out?
Because it is broad and unprotected by step-up at the same time. gh auth login mints an OAuth token with wide scopes (repo, read:org, workflow, gist and more) and stores it on the developer's machine. It is not subject to the sudo / 2FA re-auth that the web UI enforces on sensitive actions, so an attacker who steals it can perform administrative operations — up to org-owner actions if that user is an owner — with no prompt. In the October 2026 LiteLLM compromise, as publicly reported, an org-owner gh CLI token was exactly the pivot that enabled CI secret exfiltration and the release/cover-up steps.
What is the difference between a classic and a fine-grained PAT?
A classic PAT's scopes are account-wide: the repo scope grants read/write to every private repository the user can reach, not one. A fine-grained PAT is restricted to selected repositories (or an org) with per-resource read/write permissions, so a leak exposes only those repositories and permissions. Fine-grained tokens, or a GitHub App, are the least-privilege choice for most automation.
Which token type should automation use?
For server-to-server automation, a GitHub App installation token is usually best: it is short-lived (about an hour), scoped to the repositories the App is installed on, and limited to the permissions the App declares. The App's private key becomes the real secret to protect. Inside a workflow, set the GITHUB_TOKEN to least privilege (contents: read) rather than leaving a write-all default.
Is any token I pick sent to GitHub or to you?
No. You never enter a real token — you select a type and toggle scopes. The tool is a static explainer that runs entirely in your browser and makes no network calls.
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.