What is a personal access token (PAT)?

A personal access token (PAT) is a long random string that a service issues to one user account so that scripts, command-line tools and integrations can act as that user without the user's password, usually with permissions and an expiry the user picks.

How they work

Git hosts, package registries and many SaaS APIs offer them. GitHub describes PATs as "an alternative to using passwords for authentication to GitHub" from the API or command line, and warns: "Treat your access tokens like passwords" (GitHub Docs). The token inherits the identity of its owner. Whatever it does is logged as that person.

GitHub offers two kinds, and the difference shows why scoping matters:

• Fine-grained tokens are limited to resources owned by one user or organization, can be narrowed to specific repositories, and carry specific permissions.
• Classic tokens can "access every repository that you can access". GitHub calls them "less secure" and recommends fine-grained tokens "whenever possible".

Why PATs cause trouble at offboarding

A PAT is personal by name but often not by use:

• Automation runs on them. A deploy script, a CI job or a bot uses a developer's token because it was the quickest way to get going. When the developer leaves and their account is removed, the automation breaks. When the account isn't removed, the token keeps working for someone who no longer works for you.
• They live outside your systems. Tokens sit in ~/.npmrc, ~/.netrc, shell history and CLI config files on the person's own laptop.
• They last. Expiry is optional on many services. GitHub "highly recommend[s]" setting one, and removes tokens unused for a year; a token used weekly by a forgotten job never ages out.

A token like that is a textbook orphaned credential.

Good practice

• Set an expiry on every PAT, and the narrowest scope the task needs.
• Never run shared automation on a person's token. Use a bot account, an app installation or a service account the team owns.
• Where the platform allows it, let administrators see and approve tokens. On GitHub, organization owners can require approval for fine-grained tokens and restrict classic ones.
• When someone leaves, revoke their tokens at each service and check what broke.

How Crunu fits

Crunu can't see or revoke tokens at GitHub, npm or any other provider; that happens in each provider's settings. What Crunu can do:

• Hold the token in one place. Each member has a personal project with an environment called my keys for files like ~/.npmrc. crunu pull can write such a file with mode 0600 on a new laptop.
• Keep shared tokens out of personal hands. A token used by CI belongs in a team environment, with access granted to the pipeline's service token rather than copied into a developer's dotfiles.
• List what to replace. When someone leaves, the reissue checklist lists the values they received that are still in use, including tokens, without showing them.

The full offboarding order, including tokens and keys people tend to forget, is in what to rotate when a developer leaves.

Sources

• GitHub Docs: Managing your personal access tokens, checked October 30, 2026.