What Is a PAT Token and How Do You Keep It Secure?

A PAT token, short for personal access token, is a long random string that authenticates you to a service in place of a password, and treating one carelessly is the same as handing out your credentials. GitHub, GitLab, Azure DevOps, and dozens of SaaS APIs issue them so that scripts, CI jobs, and command-line tools can act on your behalf without a browser login. That convenience is also the risk: a leaked PAT token grants the same access you have, silently, until someone notices.

What a PAT token actually is

When you log into a web app, you authenticate with a username, a password, and usually a second factor. Automated clients can't complete that flow, so services mint a token you paste into a config file or an environment variable. The token is opaque to you but meaningful to the server, which maps it back to your account and the permissions you granted when you created it.

GitHub uses two shapes. Classic tokens start with a ghp_ prefix and carry coarse scopes like repo or admin:org. Fine-grained tokens, which GitHub now recommends, start with github_pat_ and let you pick specific repositories and read/write permissions per resource. The fine-grained model matters because it lets you follow least privilege instead of granting a token blanket access to everything you own.

Scopes: grant the minimum

The single most important decision when creating a PAT token is which scopes to attach. A token that only needs to read a private repository should get read-only content access to that one repository, not the repo scope that also lets it push code, manage webhooks, and delete branches.

Ask two questions before you click create:

1. What is the narrowest set of resources this token needs to touch?
2. Does it need write access, or will read suffice?

If a CI job clones a repo and runs tests, it usually needs read on that repo and nothing else. Over-scoping is how a token leaked from one pipeline turns into a foothold across an entire organization.

Expiry and rotation

A token that never expires is a liability that outlives the laptop, the contractor, and the project it was created for. Set an expiry when you create a PAT token, even if it means renewing it periodically. Ninety days is a reasonable default for interactive use; shorter for anything high-privilege.

Rotation is the discipline of replacing tokens on a schedule rather than waiting for a breach. Build the renewal into your process: store the token in a secrets manager, reference it from there, and swap the stored value when it rotates so nothing downstream has to change. If you ever suspect exposure, revoke first and ask questions later, since revocation is instant and free.

How PAT tokens leak

Most token exposure is mundane. The common paths:

• Committed to git. A developer hardcodes a token in a config file and pushes it. Public repositories are scanned by bots within seconds of a push.
• Baked into container images. A Dockerfile that copies a .env with a token ships that secret to anyone who pulls the image.
• Logged. Verbose CI logs or crash dumps print environment variables, and those logs are often world-readable inside a company.
• Shared in chat. Pasting a token into Slack or a ticket to unblock a teammate leaves it searchable forever.

Once a secret is in git history, deleting the file does not remove it. The value lives in every clone and every fork until history is rewritten and the token is revoked. Revoke it; rewriting history alone is not enough.

Storing tokens the right way

Never put a PAT token in source code. Instead:

• Use your platform's secret store. GitHub Actions has encrypted repository and organization secrets; GitLab has CI/CD variables; cloud providers have Secrets Manager or Key Vault equivalents.
• On a developer machine, use the OS credential helper. Git can hand token storage to the macOS Keychain, Windows Credential Manager, or libsecret on Linux via git config --global credential.helper.
• For local scripts, read from an environment variable that you export from a file excluded by .gitignore, and make sure that file never gets committed.

A quick check before every commit: search your staged diff for anything that looks like a token prefix. Tools like gitleaks or git-secrets automate this as a pre-commit hook and catch the mistake before it leaves your machine.

Detecting exposure across dependencies and pipelines

Your own commits are only part of the picture. Tokens also leak through third-party actions, build plugins, and dependencies that read your environment. Secret scanning that runs in the pipeline, not just at commit time, catches values that slip into build artifacts or logs. Platform-side scanning helps too: GitHub push protection blocks known token formats before they land, and an SCA workflow can flag when a dependency has network permissions that would let it exfiltrate whatever secrets are in scope. If you want to understand the broader dependency risk picture, our software supply chain security guide walks through where secrets fit.

FAQ

Is a PAT token the same as an API key?

They overlap. Both are bearer credentials you send with a request, and both should be scoped and rotated. The difference is mostly conceptual: a PAT is tied to a user account and inherits that user's identity, while an API key is often tied to an application or project. Treat both with the same care.

What should I do if I accidentally commit a PAT token?

Revoke it immediately in the service's settings, then create a replacement. Revocation is what actually protects you. Removing the file or rewriting git history is good hygiene but secondary, because any bot that scraped the value already has it.

Should PAT tokens expire?

Yes. Set the shortest expiry that your workflow tolerates and rotate before it lapses. A non-expiring token is a standing risk with no offsetting benefit beyond avoiding a renewal step you can automate anyway.

How is a fine-grained token better than a classic one?

A fine-grained PAT lets you restrict access to specific repositories and specify exact permissions per resource, so a compromised token exposes only what it was scoped to. Classic tokens grant broad scopes across everything the account can reach, which makes any leak far more damaging.