GitHub Actions permissions: use least privilege

Every workflow declares a restrictive top-level permissions block. Jobs that only build or test keep contents: read; a job that comments, publishes, or updates a status receives only that named write scope. Job-level permissions replace the workflow defaults, so each elevated job also re-declares any read scopes it still needs.12

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: npm test

  comment:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - run: gh pr comment "${{ github.event.pull_request.number }}" --body "Tests passed"
        env:
          GH_TOKEN: ${{ github.token }}

Every action and install script in every job receives a token with write access it does not need, widening the damage if any executed code is compromised.

permissions: write-all

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: npm install
      - run: npm test

Least privilege limits blast radius, but a write scope still belongs only in a job whose trigger and inputs are trusted. If an outsider can influence the run, separate the privileged operation from the untrusted build. See secure pull_request_target for that boundary. The ci-secure skill checks both broad permissions and write tokens on untrusted triggers.

GitHub creates a repository-scoped token for every job, and actions can access it through the github.token context even when it is not passed explicitly. A restrictive permissions block turns a compromised build step from a repository writer into a read-only process unless that specific job genuinely needs more.

Hand this prompt to your coding agent (Claude Code, Cursor, and the like) to audit and fix this practice in your own repo.

Audit every workflow under .github/workflows for missing or broad GITHUB_TOKEN permissions. Add a top-level `permissions: { contents: read }` default where appropriate, replace `write-all` and workflow-wide write scopes with the minimum named permissions, and grant write access only in the job that performs the matching operation. Remember that a job-level permissions block replaces workflow defaults, so re-declare required read scopes. Do not put write access in a job an outsider can trigger or influence; split that workflow instead. Preserve behavior, show the diff, and open a PR rather than applying it blindly.

Ground these changes in the upstream docs before you edit: https://docs.github.com/en/actions/reference/security/secure-use, https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#permissions. If you cannot fetch them, say so rather than guessing, and cite what you used in the PR description.

If you do not know why a run is slow yet, start with the diagnostic guide. Let an agent find which of these applies: /ci-speedup. If your workflows are already optimized but still slow, see our guide to fast GitHub Actions and GitHub Actions runner alternatives. Building containers in CI? The Docker workflow guide covers layer caching end to end. Want to see how your configuration measures up before changing anything? CI Score grades workflow config against a pass/fail rubric of these practices. It is not a speed measurement.

• GitHub Actions too slow
• Fast GitHub Actions
• GitHub Actions alternatives
• GitHub Actions pricing
• Self-hosted GitHub Actions runners
• Docker CI on GitHub Actions
• Install the free /ci-score skill to improve your GitHub Actions setup