GitHub Personal Access Token Audit: Close Out a Student Project Without Copying Secrets

A GitHub personal access token audit asks what can still reach a repository after the assignment ends. Start with owners, scope, expiry and dependencies. Do not put token values, passwords or private keys into a spreadsheet. Our original teaching pack contains six fictional cases, a blank metadata inventory and a closeout checklist.

The timely research is enterprise evidence, rather than a measurement of students. BlueFlag Security’s 3 November 2026 announcement reports that 99% of observed access tokens had no expiry, 84% could write code and 47% were unused for more than 90 days without revocation. Those properties can overlap. They do not describe 99% of student tokens or GitHub as a whole.

Checked: 7 November 2026. This is a read-only planning exercise. We did not inspect anyone’s credentials, test access to private repositories or change a security setting.

What the enterprise figures actually measure

The original BlueFlag announcement provides the reported figures. Its public methodology page describes anonymized production metadata from a subset of enterprise customers. Engineering teams range from hundreds to thousands of developers, and the coverage spans tens of thousands of identities and active tokens.

However, the public pages do not disclose the exact organization count, token denominator or observation dates. The full report requires a form; we did not submit it or claim to inspect the gated material. These limits prevent a national student estimate or an independently reproduced prevalence calculation.

Treat the chart as a reason to ask about access lifecycle. It cannot tell you which credential is compromised or which one is safe to remove. In particular, a dormant integration may still be needed for an infrequent task.

The enterprise report also states that the average developer had not used 61% of granted permissions. That uses a different denominator: permissions, rather than developers or tokens.

A project has more access routes than its member list

The same announcement reports eight non-human repository-access identities per human developer. This is a ratio from the enterprise data. It is not an actual sample of nine people and bots, nor a claim that each learner owns eight credentials.

For a course project, a practical review can consider people, personal tokens, installed apps and deploy keys. CI tools and services may use those routes, so the categories are not mutually exclusive. An inventory of repository members alone can miss another connection.

The GitHub deploy-key documentation explains that a deploy key attaches to a repository. It can remain active after the person who created it leaves. Consequently, removing a collaborator does not prove that every deployment path has closed.

Build a GitHub personal access token audit with metadata

Use the blank CSV to record a label, credential type, responsible owner, repository scope and permissions. Then add expiry, last-use evidence, dependent service, proposed decision, review date and an evidence reference.

A label such as course-notes-reader is enough for this teaching exercise. The secret value never belongs in the ledger. Even metadata can reveal internal project structure, so keep a real inventory in an appropriate private location and share only what a reviewer needs.

Distinguish “not established” from “never used.” If the available page does not establish a last-use date, preserve that uncertainty. Similarly, “no dependency documented” is a prompt to investigate, rather than proof that no consumer exists.

For example, an old project might have a deployment service that runs only when a portfolio page changes. A quiet month would not establish that the connection is disposable. Ask the named maintainer what still relies on it before choosing a change.

Separate observation from an authorised change

The official token-management guide recommends expiry and minimal repository access and permissions. It also explains fine-grained tokens, their limitations and alternatives. Therefore, the next step depends on the task; replacing every credential with a new token is not an audit goal.

Our worksheet records a proposed decision. The resource owner must choose and authorise any later change. That may involve narrowing access, planning a replacement, retiring an unneeded integration or documenting a temporary deferral. Afterward, verify the expected service behaviour and update the record.

This article does not ask you to test another person’s access or copy their credential. If you encounter a real exposed secret, use the platform’s current incident guidance through the appropriate owner. Do not put it into our downloadable exercise.

Six fictional records: different questions, not one delete rule

Every record below is invented for learning. No organization, token or private repository was audited. The original exercise’s contribution is the distinction between an observation, missing evidence and the next authorised decision.

• F01, recorded expiry: verify the current state and document it. A date in the ledger does not inventory every other route into the repository.
• F02, dormant service identity: investigate the consumer. More than 90 days without recorded use is not sufficient evidence that removal is harmless.
• F03, unknown app owner: find the responsible maintainer. An unknown owner does not give the reviewer permission to revoke access.
• F04, read task with write permission: confirm whether narrower access supports the intended workflow. Plan an authorised change and verify the replacement.
• F05, scoped read access: retain only if the need is confirmed, with a review date. A tidy row is not a guarantee that the account is secure.
• F06, portfolio deploy key: check the deployment dependency and owner before a transition. Closing the classroom team does not necessarily retire the key.

These cases deliberately cover different decisions. Counting them would only count the exercise we designed; it would not estimate the frequency of problems in student projects.

Expiry is useful, but the time thresholds differ

The GitHub expiry and revocation reference describes automatic revocation at expiry and after a year without use for relevant personal or OAuth tokens. That is different from BlueFlag’s greater-than-90-day dormancy observation.

Do not convert the vendor’s 90-day measure into a claim about GitHub’s automatic policy. Likewise, a credential with no configured expiry is not necessarily valid forever. Revocation, changes in resource access and platform rules can affect its use.

Keep the policy reference and its check date beside the inventory. As rules change, a future reader can distinguish a historical observation from the platform’s current behaviour.

Download the metadata-only review pack

• Enterprise source figures and denominator notes (CSV).
• Blank 20-row metadata inventory (CSV).
• Six fictional closeout cases with reasons (CSV).
• Read-only project closeout checklist (CSV).

For an instructor, the exercise can begin with the six fictional rows. Ask learners to name the missing evidence before suggesting an action. Then compare their explanation with the answer guide. No live account or credential is necessary.

This GitHub personal access token audit addresses access lifecycle. It complements our pnpm alert-coverage guide, which examines a different issue: whether dependency security alerts cover the installed package workflow. Passing one review does not establish the other.

What this review can and cannot establish

A completed ledger can show which access routes were considered, who owns the decision and what evidence remains missing. It cannot prove that a repository is secure, discover every credential automatically or certify incident readiness.

The charts reproduce scoped enterprise findings; the worksheet and fictional cases are original educational tools. We did not conduct a student survey or a live security assessment. Consequently, there is no student prevalence estimate, compromised-token rate or measured improvement claim.

Use a GitHub personal access token audit to make the project’s remaining access understandable. Record the evidence, confirm dependencies and leave consequential changes to an authorised owner. That creates a clearer closeout record than either copying secrets into a spreadsheet or deleting unfamiliar access without context.