How do you set a read-only default GITHUB_TOKEN for GitHub Actions workflows?

Why a read-only default for GITHUB_TOKEN changes the blast radius

GitHub Actions is most resilient when the default token starts with the minimum access a workflow needs, rather than assuming every job should be able to write. That shifts access from implicit to explicit, so write actions become deliberate design choices instead of inherited behaviour. It also makes review simpler because any job that needs broader scope stands out immediately.

For GitHub Actions security, the default token setting is part of the workflow trust boundary. GitHub and GitHub Actions Security Guide covers the surrounding controls that matter here, including token scope, action pinning and workflow injection. A read-only default limits what a compromised step can do if an attacker lands through an untrusted action, a malicious pull request path or a poisoned script.

That matters because GitHub Actions commonly mixes trusted and untrusted inputs in the same automation chain. If the default token can write, a single injected step can alter releases, tamper with repository contents or widen access for later stages. If the default is read-only, the attacker has to overcome an additional control before they can make persistent changes.

Reading the repository settings and workflow YAML together is important because the effective permission model is the combination of both. A repository-wide default can be narrowed further inside a workflow, but a permissive workflow can only be trusted if every write capability is intentional and isolated to the exact job that needs it.

Where read-only defaults fit in workflow design

The practical pattern is to let most jobs inherit read-only access and then grant narrower permissions only to the few jobs that truly need them. Build, test and lint jobs usually do not need write access. Release, tagging, package publishing and deployment jobs often do, but those should be explicit exceptions with a clear purpose and a narrower scope than the rest of the pipeline.

This is also where action choice and execution context matter. The secure default is not only about the token itself, but about how much authority a workflow step can exercise if it is compromised. CI/CD Pipeline Identity Security Guide is the broader reference point for treating token permissions, untrusted builds and publishing steps as separate trust decisions. In practice, that means keeping write access out of the ordinary path and concentrating it where human review and tighter controls are already expected.

For release engineering, the main decision is whether the job needs repository writes, package publishing rights or deployment credentials. Those are different authorities, and they should not all arrive through the same token by default. A read-only baseline makes it easier to separate them and verify each permission grant on its own merits.

The same logic applies to reusable workflows and composite actions. If a child workflow inherits broader permissions than it needs, the default setting no longer reflects the actual blast radius. The safer pattern is to grant the smallest permission set needed at the narrowest scope where the action is used.

How to verify the setting without breaking delivery

The goal is not simply to flip a setting, but to confirm that ordinary CI still works and that only the intended privileged paths can write. That means checking repository-level defaults, workflow-level permission blocks and any job-specific overrides together. If a deployment or release job suddenly fails, the fix should be to grant only the missing permission, not to restore broad write access everywhere.

Testing should focus on the workflows that most often depend on write privileges: release publishing, environment deployment, issue or pull request automation and any job that creates tags or artifacts. If those jobs still work after you restrict the default, you have evidence that the permissions are correctly scoped rather than accidentally inherited.

It is also worth checking how third-party actions behave under the tighter default. Some actions assume they can write comments, create releases or update metadata. When those assumptions surface, they reveal where the workflow was depending on overbroad access rather than an explicit design choice.

When the repository is part of a larger organisation, use the same review on inherited settings, reusable workflows and shared templates. One permissive template can undo careful local hardening, so the permission model must be validated at the point where the workflow actually runs.

Risk and Threat Considerations

Read-only defaults reduce the damage an attacker can do if they gain execution inside a workflow, but they do not remove the underlying compromise path. A malicious action, poisoned pull request or injected step can still read data, observe secrets that are already exposed to the job and attempt to pivot into other trusted systems.

Failure mechanism: The control fails when a workflow inherits more privilege than it needs, or when a later job silently restores write access and becomes the attacker’s persistence point. That gives an injected step the ability to modify code, alter releases or plant changes that survive beyond the initial compromise.

Impact: The practical impact is reduced blast radius, slower attacker progression and better containment of compromised automation. It also makes privilege review more auditable because every write-capable workflow becomes a deliberate exception rather than the default posture.

Practitioner Guidance

What to verify: Confirm the repository default, each workflow permission block and each job override, then test the specific jobs that should still write. If a job needs write access, scope it to the smallest permission set that satisfies that job alone.

Common mistake: Teams often harden the default token and then reintroduce broad write access through a reusable workflow, an inherited template or a convenience fix for a failing release job. That restores the original exposure while making it harder to notice.

Decision rule: If the job publishes, deploys or mutates repository state, grant only the exact permission needed for that step and keep every other job read-only. If the job only builds or validates code, it should not be able to write at all.

Practitioner takeaway: The real control is not “read-only everywhere”, it is “write access only where the workflow proves it needs it, and nowhere else.”

Related resources from NHI Mgmt Group

• What should organisations do first when they inherit GitHub Actions workflows with unreviewed run steps and default token permissions?
• Why do default GitHub Action token permissions create security risk in CI/CD workflows?
• How should security teams reduce risk from compromised GitHub Actions workflows?
• What breaks when GitHub Actions workflows run untrusted pull requests with write access?