If you like handing out master keys and hoping for the best then ignore this guide and enjoy chaos. If you prefer automation that does not accidentally become a global admin disaster then read on. This short guide explains how to create and use GitHub personal access tokens also known as PATs with fine grained permissions for CI workflows CLI scripts and API calls while keeping security sane.

Why fine grained tokens matter

Treat tokens like tiny kingdom keys. A full access token is basically a universal key that will let your automation do whatever it wants. Fine grained tokens let you pick exactly which repositories and which permissions are allowed. That means you can run CI workflows and CLI automation without handing over the crown jewels.

Where to create a fine grained PAT

Open GitHub and go to Settings then Developer settings then Personal access tokens then Fine grained tokens. Pick the right account or organization first. This is not the time to guess.

Quick creation checklist

• Give the token a clear descriptive name so future you does not curse past you
• Set an expiration date that matches the use case and your attention span
• Grant repository level access only for the repos you need
• Choose minimal permission scopes required for the task and nothing more
• Click Generate and copy the token immediately because GitHub will show it only once

Using the token in Git and the API

For HTTPS git operations use the PAT in place of your password when prompted. That works for clone fetch pull and push operations. For API calls add an Authorization header with the value Bearer followed by your token when making requests. If you use the GitHub CLI you can pipe the token into the login command like this

echo "YOUR_TOKEN_HERE" | gh auth login --with-token

This keeps the token out of your interactive prompts and lets scripts authenticate cleanly. For curl just set an Authorization header with Bearer and the token when you call the API.

Storing tokens for CI and workflows

Never hard code tokens in scripts. Add the PAT to your repository secrets or to your CI provider secret store. In GitHub Actions create a repo secret and reference it in the workflow using the secrets context such as $. That keeps the value out of logs and reduces accidental exposure.

Examples of good secret hygiene

• Use repository or organization secrets instead of environment files
• Limit scope so a leaked secret has a tiny blast radius
• Rotate keys periodically and revoke tokens that are no longer used
• Test with a narrow permission set before expanding access

Rotation revocation and least privilege

Set an expiration date and put token rotation on your calendar. If a token stops being used revoke it right away. Follow least privilege practices so automation keeps working but cannot escalate into a security incident. You can automate rotation workflows in CI if you like living dangerously with safety nets.

Troubleshooting tips

• If an API call fails check that the PAT has the required permission scope for the endpoint
• If git operations are rejected confirm you used the token as the password for HTTPS and that the token has repo access
• For organization level tokens ensure you selected the right account context when creating the token

Fine grained PATs give you control power and dignity all at once. Follow these practices for authentication security in CLI CI and workflows and your automation will behave like an obedient robot instead of a mischievous gremlin.