Limit GITHUB_TOKEN permissions even when an action is not explicitly passed the token

Omitting a token input does not prove an action lacks access to the workflow’s token context.

Source facts

GitHub states that an action can access GITHUB_TOKEN through the github.token context even when a workflow does not explicitly pass it as an input. The permissions key can limit token permissions for the entire workflow or individual jobs. GitHub recommends granting only the access required. Its examples assign specific capabilities to the job that needs them.

Source: GitHub — Use GITHUB_TOKEN for authentication in workflows.

Applicability

This concerns the built-in workflow token. Personal access tokens, GitHub App tokens, environment secrets and external credentials have separate permission and lifecycle decisions.

DSE recommendation

DSE recommends listing each job’s required GitHub operations before assigning token permissions. Give an ordinary build a different permission set from a job that writes issues, packages or repository contents. Review every third-party action against the effective token capabilities, including implicit context access. Keep a documented reason for every write permission and review it when a workflow gains a new step or starts processing untrusted input. Include implicit context access in the workflow review checklist. Ask the job owner to justify each write capability against a specific required operation, and repeat that review when a third-party action or an untrusted-input path is added to the job.

Verification

Proposed verification: use a harmless test workflow to exercise an intended operation and an operation outside the approved permission set. Inspect the effective job configuration and resulting responses. Retain permission names and outcomes without exposing the token. Confirm a denied action is explained before increasing privileges to make the workflow pass.

Official reference

GitHub — Use GITHUB_TOKEN for authentication in workflows. Reviewed October 20, 2026.