First-hand · verified against the real thing
Personal access tokens: using them without leaking them
In one line: Least-scope tokens, where they can and cannot appear, and the rotation habit — written after months of daily build use.
A GitHub personal access token in a build pipeline is a standing temptation to do the lazy thing: paste it into a script, commit, move on. Don't. Here is the discipline that works day-to-day.
Scope it to the minimum
A token that only pushes to one repository needs exactly one scope: contents read/write on that repo. Fine-grained tokens (now the default in GitHub's settings) let you select the single repository and the single permission. If your token's description says "for everything", it is wrong.
Where a token may appear
- CI secrets / environment variables: yes. Render, Actions, and friends inject them at build time.
- A chat message to your own agent or notes: tolerable only if you plan rotation — and "planning" means a date on the calendar, not intentions.
- A committed file, a URL, a screenshot: never. Committed tokens live forever in history; GitHub's secret scanning will revoke some automatically, and attackers find the rest first.
The rotation habit
Rotate on a schedule you would be embarrassed to break: 90 days for personal tokens is a good default, immediately after any suspected exposure, and whenever a collaborator leaves. Rotation costs five minutes if your pipeline reads the token from one secret; it costs an evening if the token is pasted in six places.
The tell you're doing it right
Grep your repository for the token prefix right now (ghp_ for classic tokens). The correct number of results is zero — including in history, which you can check with git log -S ghp_. If history is dirty and the repo is public, the token is burned: revoke first, refactor second.
Next