GitHub API key best practices

GitHub tokens with broad scopes are high-value targets - a leaked token can give attackers write access to your entire organization's repositories.

Why GitHub tokens are high-risk

GitHub personal access tokens (PATs) are the third most leaked credential type according to GitGuardian 2026. Unlike API keys that drain billing accounts, leaked GitHub tokens with repo scope can read private repositories, push malicious commits, and launch supply chain attacks.

High-risk scopes to protect

  • repo (full repository access)
  • admin:org
  • delete_repo
  • workflow (GitHub Actions)

Recommended: use fine-grained tokens

GitHub's fine-grained personal access tokens (available since 2022) let you restrict a token to specific repositories and permission sets. Always prefer these over classic PATs for automated workflows.

Scope to specific repositories only - not all repositories
Grant only the minimum permissions required (read-only for CI is usually sufficient)
Set an expiration date - 90 days or less
Use separate tokens for different applications or workflows

Using KeyVault Edge for GitHub tokens

For server-side GitHub API automation (CI scripts, internal tools), you can proxy GitHub API calls through KeyVault Edge to bind the token to your server's origin.

.env
GITHUB_TOKEN=kve_hb_...your_sanitized_tokenGITHUB_API_BASE=https://github.keyvaultedge.com
Usage with Octokit
import { Octokit } from "@octokit/rest"; const octokit = new Octokit({  auth: process.env.GITHUB_TOKEN,  baseUrl: process.env.GITHUB_API_BASE ?? "https://api.github.com",});

GitHub Actions: use repository secrets

For GitHub Actions workflows, use the built-in GITHUB_TOKEN where possible - it is automatically scoped to the current repository and expires when the job finishes.

When you need broader access, store a fine-grained PAT in a repository or organization secret and reference it via ${{ secrets.MY_TOKEN }}. Never hardcode tokens in workflow YAML files.